summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* net/mlx5e: IPSec, Expose IPsec HW stat only for supporting HWRaed Salem2020-04-204-86/+58
| | | | | | | | | | The current HW counters are supported only by Innova, split the ipsec stats group into two groups, one for HW and one for SW. And expose the HW counters to ethtool only if Innova HW is used for IPsec offload. Signed-off-by: Raed Salem <raeds@mellanox.com> Reviewed-by: Huy Nguyen <huyn@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
* net/mlx5: Refactor mlx5_accel_esp_create_hw_context parameter listRaed Salem2020-04-204-28/+37
| | | | | | | | | | | | | | | | | | | Currently the FPGA IPsec is the only hw implementation of the IPsec acceleration api, and so the mlx5_accel_esp_create_hw_context was wrongly made to suit this HW api, among other in its parameter list and some of its parameter endianness. This implementation might not be suitable for different HW. Refactor by group and pass all function arguments of mlx5_accel_esp_create_hw_context in common mlx5_accel_esp_xfrm_attrs struct field of mlx5_accel_esp_xfrm struct and correct the endianness according to the HW being called. Signed-off-by: Raed Salem <raeds@mellanox.com> Reviewed-by: Boris Pismenny <borisp@mellanox.com> Reviewed-by: Huy Nguyen <huyn@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
* net/mlx5e: en_accel, Add missing net/geneve.h includeRaed Salem2020-04-201-0/+2
| | | | | | | | | | | | | | | The cited commit relies on include <net/geneve.h> being included implicitly prior to include "en_accel/en_accel.h". This mandates that all files that needs to include en_accel.h to redantantly include net/geneve.h. Include net/geneve.h explicitly at "en_accel/en_accel.h" to avoid undesired constrain as above. Fixes: e3cfc7e6b7bd ("net/mlx5e: TX, Add geneve tunnel stateless offload support") Signed-off-by: Raed Salem <raeds@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
* net/mlx5: Use the correct IPsec capability function for FPGA opsRaed Salem2020-04-203-4/+18
| | | | | | | | | | | | | | | | | | | | Currently the IPsec acceleration capability function is also used at IPsec fpga capable device code. This could cause a future bug as the acceleration layer is agnostic to the device implementing its API. Fix by using the IPsec FPGA capability function instead of acceleration layer capability function in case of FPGA IPsec only related operations. Downstream patches will add support for Connect-X IPsec, this can avoid a future bug. Signed-off-by: Raed Salem <raeds@mellanox.com> Reviewed-by: Boris Pismenny <borisp@mellanox.com> Reviewed-by: Huy Nguyen <huyn@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
* selftests: pmtu: implement IPIP, SIT and ip6tnl PMTU discovery testsLourdes Pedrajas2020-04-201-0/+122
| | | | | | | | | | | | | Add PMTU discovery tests for these encapsulations: - IPIP - SIT, mode ip6ip - ip6tnl, modes ip6ip6 and ipip6 Signed-off-by: Lourdes Pedrajas <lu@pplo.net> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: mscc: use mdiobus_get_phy()Michael Walle2020-04-201-4/+3
| | | | | | | | | Don't use internal knowledge of the mdio bus core, instead use mdiobus_get_phy() which does the same thing. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'mlxsw-Two-small-changes'David S. Miller2020-04-202-3/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ido Schimmel says: ==================== mlxsw: Two small changes Patch #1 increases the scale of supported IPv6 nexthops groups when each group has one nexthop and all are using the same nexthop device, but with a different gateway IP. Patch #2 adjusts a register definition in accordance with recent firmware changes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mlxsw: reg: Increase register field length to 13 bitsIdo Schimmel2020-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Infrastructure Entry Delete Register (IEDR) is used to delete entries stored in the KVD linear database. Currently, it is only possible to delete entries of size up to 2048. Future firmware versions will support deletion of entries of size up to 4096. Increase the size of the field so that the driver will be able to perform such deletions in the future, when required. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * mlxsw: spectrum_router: Re-increase scale of IPv6 nexthop groupsIdo Schimmel2020-04-201-2/+6
|/ | | | | | | | | | | | | | | | | | | | | | | As explained in commit fc25996e6f46 ("mlxsw: spectrum_router: Increase scale of IPv6 nexthop groups"), each nexthop group is hashed by XOR-ing the interface indexes of all the member nexthop devices. To avoid many different nexthop groups ending up using the same key, the above commit started hashing the interface indexes themselves before they are XOR-ed. However, in cases in which there are many nexthop groups that all use the same nexthop device and only differ in the gateway IP, we can still end up in a situation in which all the groups are using the same key. This eventually leads to -EBUSY error from rhashtable during insertion. Improve the situation by also making the gateway IP part of the key. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Alex Veber <alexve@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Alex Veber <alexve@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: Propagate error from bus->resetFlorian Fainelli2020-04-201-3/+6
| | | | | | | | | If a bus->reset() call for the mii_bus structure returns an error (e.g.: -EPROE_DEFER) we should propagate it accordingly. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'net-phy-realtek-move-PHY-resume-delay-from-MAC-to-PHY-driver'David S. Miller2020-04-202-4/+13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Heiner Kallweit says: ==================== net: phy: realtek: move PHY resume delay from MAC to PHY driver Internal PHY's from RTL8168h up may not be instantly ready after calling genphy_resume(). So far r8169 network driver adds the needed delay, but better handle this in the PHY driver. The network driver may miss other places where the PHY is resumed. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove PHY resume delay that is handled in the PHY driver nowHeiner Kallweit2020-04-201-2/+0
| | | | | | | | | | | | | | | | | | The Realtek PHY driver takes care of adding the needed delay now, therefore we can remove the delay here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: phy: realtek: add delay to resume path of certain internal PHY'sHeiner Kallweit2020-04-201-2/+13
|/ | | | | | | | | | | Internal PHY's from RTL8168h up may not be instantly ready after calling genphy_resume(). So far r8169 network driver adds the needed delay, but better handle this in the PHY driver. The network driver may miss other places where the PHY is resumed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: hns: use true,false for bool variablesJason Yan2020-04-201-2/+2
| | | | | | | | | | | | | Fix the following coccicheck warning: drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:700:2-8: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:702:2-8: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ptp: idt82p33: Make two variables staticYueHaibing2020-04-201-2/+2
| | | | | | | | | | | | Fix sparse warnings: drivers/ptp/ptp_idt82p33.c:26:5: warning: symbol 'sync_tod_timeout' was not declared. Should it be static? drivers/ptp/ptp_idt82p33.c:31:5: warning: symbol 'phase_snap_threshold' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ptp_kvm: Make kvm_ptp_lock staticYueHaibing2020-04-201-1/+1
| | | | | | | | | | | | Fix sparse warning: drivers/ptp/ptp_kvm.c:25:1: warning: symbol 'kvm_ptp_lock' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: sja1105: enable internal pull-down for RX_DV/CRS_DV/RX_CTL and RX_ERVladimir Oltean2020-04-203-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | Some boards do not have the RX_ER MII signal connected. Normally in such situation, those pins would be grounded, but then again, some boards left it electrically floating. When sending traffic to those switch ports, one can see that the N_SOFERR statistics counter is incrementing once per each packet. The user manual states for this counter that it may count the number of frames "that have the MII error input being asserted prior to or up to the SOF delimiter byte". So the switch MAC is sampling an electrically floating signal, and preventing proper traffic reception because of that. As a workaround, enable the internal weak pull-downs on the input pads for the MII control signals. This way, a floating signal would be internally tied to ground. The logic levels of signals which _are_ externally driven should not be bothered by this 40-50 KOhm internal resistor. So it is not an issue to enable the internal pull-down unconditionally, irrespective of PHY interface type (MII, RMII, RGMII, SGMII) and of board layout. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'r8169-series-with-improvements'David S. Miller2020-04-191-24/+51
|\ | | | | | | | | | | | | | | | | | | | | | | Heiner Kallweit says: ==================== r8169: series with improvements Again a series with few improvements. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: add workaround for RTL8168evl TSO hw issuesHeiner Kallweit2020-04-191-0/+34
| | | | | | | | | | | | | | | | | | Add workaround for hw issues with TSO on RTL8168evl. This workaround is based on information I got from Realtek, and *should* allow to safely enable TSO on this chip version. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: improve rtl8169_tso_csum_v2Heiner Kallweit2020-04-191-10/+5
| | | | | | | | | | | | | | Simplify the code and avoid the overhead of calling vlan_get_protocol(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: use rtl8169_set_features in rtl8169_init_oneHeiner Kallweit2020-04-191-4/+3
| | | | | | | | | | | | | | | | At that place in rtl_init_one() we can safely use rtl8169_set_features() to configure the chip according to the default features. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: preserve VLAN setting on RTL8125 in rtl_init_rxcfgHeiner Kallweit2020-04-191-2/+5
| | | | | | | | | | | | | | | | | | So far we set RX_VLAN_8125 unconditionally, even if NETIF_F_HW_VLAN_CTAG_RX may not be set. Don't touch these bits, and let only rtl8169_set_features() control them. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: remove NETIF_F_HIGHDMA from vlan_featuresHeiner Kallweit2020-04-191-2/+1
| | | | | | | | | | | | | | | | NETIF_F_HIGHDMA is added to vlan_features by register_netdev(), therefore we can omit this here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: move setting OCP base to generic init codeHeiner Kallweit2020-04-191-6/+3
|/ | | | | | | | Move setting the ocp_base to rtl_init_one(). Where supported the value is always the same, and if not supported it doesn't hurt. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* enetc: permit configuration of rx-vlan-filter with ethtoolVladimir Oltean2020-04-191-28/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each ENETC station interface (SI) has a VLAN filter list and a port flag (PSIPVMR) by which it can be put in "VLAN promiscuous" mode, which enables the reception of VLAN-tagged traffic even if it is not in the VLAN filtering list. Currently the handling of this setting works like this: the port starts off as VLAN promiscuous, then it switches to enabling VLAN filtering as soon as the first VLAN is installed in its filter via .ndo_vlan_rx_add_vid. In practice that does not work out very well, because more often than not, the first VLAN to be installed is out of the control of the user: the 8021q module, if loaded, adds its rule for 802.1p (VID 0) traffic upon bringing the interface up. What the user is currently seeing in ethtool is this: ethtool -k eno2 rx-vlan-filter: on [fixed] which doesn't match the intention of the code, but the practical reality of having the 8021q module install its VID which has the side-effect of turning on VLAN filtering in this driver. All in all, a slightly confusing experience. So instead of letting this driver switch the VLAN filtering state by itself, just wire it up with the rx-vlan-filter feature from ethtool, and let it be user-configurable just through that knob, except for one case, see below. In promiscuous mode, it is more intuitive that all traffic is received, including VLAN tagged traffic. It appears that it is necessary to set the flag in PSIPVMR for that to be the case, so VLAN promiscuous mode is also temporarily enabled. On exit from promiscuous mode, the setting made by ethtool is restored. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mscc: ocelot: deal with problematic MAC_ETYPE VCAP IS2 rulesVladimir Oltean2020-04-193-4/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, the VCAP IS2 will produce a single match for each frame, on the most specific classification. Example: a ping packet (ICMP over IPv4 over Ethernet) sent from an IP address of 10.0.0.1 and a MAC address of 96:18:82:00:04:01 will match this rule: tc filter add dev swp0 ingress protocol ipv4 \ flower skip_sw src_ip 10.0.0.1 action drop but not this one: tc filter add dev swp0 ingress \ flower skip_sw src_mac 96:18:82:00:04:01 action drop Currently the driver does not really warn the user in any way about this, and the behavior is rather strange anyway. The current patch is a workaround to force matches on MAC_ETYPE keys (DMAC and SMAC) for all packets irrespective of higher layer protocol. The setting is made at the port level. Of course this breaks all other non-src_mac and non-dst_mac matches, so rule exclusivity checks have been added to the driver, in order to never have rules of both types on any ingress port. The bits that discard higher-level protocol information are set only once a MAC_ETYPE rule is added to a filter block, and only for the ports that are bound to that filter block. Then all further non-MAC_ETYPE rules added to that filter block should be denied by the ports bound to it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '1GbE' of ↵David S. Miller2020-04-199-222/+605
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2020-04-17 This series contains updates to e1000e and igc only. Sasha adds partial generic segmentation offload (GSO partial) support to the igc driver. Also added support for translating taprio schedules into i225 cycles in igc. Did clean up of dead code or unused defines in the igc driver. Refactored the code to avoid forward declarations where possible. Enables the NETIF_F_HW_TC flag for igc by default. Vinicius adds support for ETF offloading using the similar approach that taprio offload used. Kees Cook fixes a clang warning in the e1000e driver by moving the declared variable either into the switch case that uses the variable or lift them up into the main function body, to help the compiler. Andre fixed some register overwriting when dumping registers via ethtool for igc driver. Also fixed support for ethtool Network Flow Classification (NFC) queue redirection by adding the missing code needed to enable the queue selection feature from Receive Address High (RAH) register. Cleans up code to remove the code bits designed to support tc-flower filters, since this client part does not support it. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * igc: Fix default MAC address filter overrideAndre Guedes2020-04-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bug when the user adds the first MAC address filter via ethtool NFC mechanism. When the first MAC address filter is added, it overwrites the default MAC address filter configured at RAL[0] and RAH[0]. As consequence, frames addressed to the interface MAC address are not sent to host anymore. This patch fixes the bug by calling igc_set_default_mac_filter() during adapter init so the position 0 of adapter->mac_table[] is assigned to the default MAC address. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Remove dead code related to flower filterAndre Guedes2020-04-172-4/+0
| | | | | | | | | | | | | | | | | | IGC driver has no support for tc-flower filters so this patch removes some leftover code, probably copied from IGB driver by mistake. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Fix NFC queue redirection supportAndre Guedes2020-04-172-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for ethtool Network Flow Classification (NFC) queue redirection based on destination MAC address is currently broken in IGC. For instance, if we add the following rule, matching frames aren't enqueued on the expected rx queue. $ ethtool -N IFNAME flow-type ether dst 3c:fd:fe:9e:7f:71 queue 2 The issue here is due to the fact that igc_rar_set_index() is missing code to enable the queue selection feature from Receive Address High (RAH) register. This patch adds the missing code and fixes the issue. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Acked-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Remove copper fiber switch controlSasha Neftin2020-04-172-11/+0
| | | | | | | | | | | | | | | | | | | | i225 device support copper mode only PHY signal detect indication for copper fiber switch not applicable to i225 part Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Enable NETIF_F_HW_TC flagSasha Neftin2020-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This assignment of the feature NETIF_F_HW_TC occurs prior to the initial setup of the local hw_features variable. This ensures that NETIF_F_HW_TC are marked as user changeable, and also enables it by default when the driver loads. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Fix double definitionSasha Neftin2020-04-171-3/+1
| | | | | | | | | | | | | | | | | | IGC_START_ITR has beed defined twice This patch come to fix it Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Fix overwrites when dumping registersAndre Guedes2020-04-171-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes some register overwriting when dumping registers via ethtool. We have a total of 16 RAL registers, starting at offset 139. So RAH offset should be 139 + 16 = 155, not 145. As result some RAL registers are overwritten. Likewise, RAH registers are also overwritten by TDBAL, TDBAH, TDLEN, and TDH registers. To fix this bug while preserving the ABI, this patch re-writes RAL and RAH registers at the end of 'regs_buff' and bumps regs->version. It also removes some pointless comments in the middle of igc_set_regs(). Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Remove forward declarationSasha Neftin2020-04-171-197/+194
| | | | | | | | | | | | | | | | | | | | Move igc_adapter and igc_ring structures up to avoid forward declaration It is not necessary to forward declare these structures Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Remove unused CTRL_EXT_LINK_MODE_MASKSasha Neftin2020-04-171-3/+0
| | | | | | | | | | | | | | | | | | We support only copper mode Not applicable for i225 parts Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Remove unused MDIC_DEST maskSasha Neftin2020-04-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | Formally Destination bit should be kept reserved to support legacy drivers and ignore on write/read operation Not applicable for i225 parts Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * e1000: Distribute switch variables for initializationKees Cook2020-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’: drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable] 3143 | unsigned int pull_size; | ^~~~~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Add support for ETF offloadingVinicius Costa Gomes2020-04-173-4/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for ETF offloading for the i225 controller. For i225, the LaunchTime feature is almost a subset of the Qbv feature. The main change from the i210 is that the launchtime of each packet is specified as an offset applied to the BASET register. BASET is automatically incremented each cycle. For i225, the approach chosen is to re-use most of the setup used for taprio offloading. With a few changes: - The more or less obvious one is that when ETF is enabled, we should set add the expected launchtime to the (advanced) transmit descriptor; - The less obvious, is that when taprio offloading is not enabled, we add a dummy schedule (all queues are open all the time, with a cycle time of 1 second). Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Reviewed-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Add support for taprio offloadingVinicius Costa Gomes2020-04-177-1/+294
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for translating taprio schedules into i225 cycles. This will allow schedules to run in the hardware, making the schedules enforcement more precise and saving CPU time. Right now, the only simple schedules are allowed, complex schedules are rejected. "simple" in this context are schedules that each HW queue is opened and closed only once in each cycle. Changing schedules is still not supported as well. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Reviewed-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * igc: Add GSO partial supportSasha Neftin2020-04-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Partial generic segmentation offload is a hybrid between TSO and GSO. What is effectively does is take advantage of certain traits of TCP and tunnels so that instead of having to rewrite the packet headers for each segment only in the inner-most transport header and possible the outer-most network header need to be updated. This allows devices that do not support tunnel offload or tunnels offloads with checksum to still make use of segmentation. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | net: phy: broadcom: Add support for BCM53125 internal PHYsFlorian Fainelli2020-04-192-0/+15
| | | | | | | | | | | | | | | | | | BCM53125 has internal Gigabit PHYs which support interrupts as well as statistics, make it possible to configure both of those features with a PHY driver entry. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: phy: mdio-bcm-iproc: Do not show kernel pointerFlorian Fainelli2020-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | Displaying the virtual address at which the MDIO base register address has been mapped is not useful and is not visible with pointer hashing in place, replace the message with something indicating successful registration instead. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: per-port interrupts are optionalFlorian Fainelli2020-04-191-1/+1
| | | | | | | | | | | | | | | | Make use of platform_get_irq_byname_optional() to avoid printing messages on the kernel console that interrupts cannot be found. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: phy: at803x: add support for AR8032 PHYDavid Bauer2020-04-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | This adds support for the Qualcomm Atheros AR8032 Fast Ethernet PHY. It shares many similarities with the already supported AR8030 PHY but additionally supports MII connection to the MAC. Signed-off-by: David Bauer <mail@david-bauer.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'for-upstream' of ↵David S. Miller2020-04-1723-152/+830
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-04-17 Here's the first bluetooth-next pull request for the 5.8 kernel: - Added debugfs option to control MITM flag usage during pairing - Added new BT_MODE socket option - Added support for Qualcom QCA6390 device - Added support for Realtek RTL8761B device - Added support for mSBC audio codec over USB endpoints - Added framework for Microsoft HCI vendor extensions - Added new Read Security Information management command - Fixes/cleanup to link layer privacy related code - Various other smaller cleanups & fixes ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * Bluetooth: Enhanced Connection Complete event belongs to LL PrivacyMarcel Holtmann2020-04-161-8/+0
| | | | | | | | | | | | | | | | The Enhanced Connection Complete event is use in conjunction with LL Privacy and not Extended Advertising. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Clear HCI_LL_RPA_RESOLUTION flag on resetMarcel Holtmann2020-04-151-0/+1
| | | | | | | | | | | | | | | | | | When the controller is being reset or power cycled, then the flag HCI_LL_RPA_RESOLUTION which indicates if controller based address resolution is active needs to be also reset. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Enable LE Enhanced Connection Complete event.Marcel Holtmann2020-04-152-0/+9
| | | | | | | | | | | | | | | | | | In case LL Privacy is supported by the controller, it is also a good idea to use the LE Enhanced Connection Complete event for getting all information about the new connection and its addresses. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Use extra variable to make code more readableMarcel Holtmann2020-04-151-1/+3
| | | | | | | | | | | | | | | | | | When starting active scanning for discovery the whitelist is not needed to be used. So the filter_policy is 0x00. To make the core more readable use a variable name instead of just setting 0 as paramter. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 10:37:44 +0100