- 20 Apr, 2020 14 commits
-
-
Raed Salem authored
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>
-
Lourdes Pedrajas authored
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>
-
Michael Walle authored
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 authored
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: -
Ido Schimmel authored
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:
-
Ido Schimmel authored
As explained in commit fc25996e ("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:
Alex Veber <alexve@mellanox.com> Reviewed-by:
-
Florian Fainelli authored
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:
-
David S. Miller authored
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: -
Heiner Kallweit authored
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:
-
Heiner Kallweit authored
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:
-
Jason Yan authored
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:
-
YueHaibing authored
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:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
YueHaibing authored
Fix sparse warning: drivers/ptp/ptp_kvm.c:25:1: warning: symbol 'kvm_ptp_lock' was not declared. Should it be static? Reported-by:
-
Vladimir Oltean authored
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:
-
- 19 Apr, 2020 7 commits
-
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: series with improvements Again a series with few improvements. ==================== Signed-off-by: -
Heiner Kallweit authored
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 authored
Simplify the code and avoid the overhead of calling vlan_get_protocol(). Signed-off-by:
-
Heiner Kallweit authored
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 authored
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 authored
NETIF_F_HIGHDMA is added to vlan_features by register_netdev(), therefore we can omit this here. Signed-off-by:
-
Heiner Kallweit authored
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:
-
- 18 Apr, 2020 7 commits
-
-
Vladimir Oltean authored
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:
Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
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:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
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: -
Florian Fainelli authored
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 authored
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 authored
Make use of platform_get_irq_byname_optional() to avoid printing messages on the kernel console that interrupts cannot be found. Signed-off-by:
-
David Bauer authored
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:
-
- 17 Apr, 2020 12 commits
-
-
David S. Miller authored
Merge branch 'for-upstream' of 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:
-
Andre Guedes authored
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>
-
Andre Guedes authored
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 authored
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:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
-
Sasha Neftin authored
i225 device support copper mode only PHY signal detect indication for copper fiber switch not applicable to i225 part Signed-off-by:
-
Sasha Neftin authored
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 authored
IGC_START_ITR has beed defined twice This patch come to fix it Signed-off-by:
-
Andre Guedes authored
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:
-
Sasha Neftin authored
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 authored
We support only copper mode Not applicable for i225 parts Signed-off-by:
-
Sasha Neftin authored
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:
-
Kees Cook authored
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=44916Signed-off-by:Kees Cook <keescook@chromium.org> Tested-by:
-
