summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-07-26net: ethernet: mtk_eth_soc: convert clock bitmap to u64Daniel Golle
The to-be-added MT7988 SoC adds many new clocks which need to be controlled by the Ethernet driver, which will result in their total number exceeding 32. Prepare by converting clock bitmaps into 64-bit types. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/6960a39bb0078cf84d7642a9558e6a91c6cc9df3.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: ethernet: mtk_eth_soc: convert caps in mtk_soc_data struct to u64Lorenzo Bianconi
This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/9499ac3670b2fc5b444404b84e8a4a169beabbf2.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: ethernet: mtk_eth_soc: add NETSYS_V3 version supportLorenzo Bianconi
Introduce NETSYS_V3 chipset version support. This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/0db2260910755d76fa48e303b9f9bdf4e5a82340.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: ethernet: mtk_eth_soc: rely on MTK_MAX_DEVS and remove MTK_MAC_COUNTLorenzo Bianconi
Get rid of MTK_MAC_COUNT since it is a duplicated of MTK_MAX_DEVS. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/1856f4266f2fc80677807b1bad867659e7b00c65.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: ethernet: mtk_eth_soc: increase MAX_DEVS to 3Lorenzo Bianconi
This is a preliminary patch to add MT7988 SoC support since it runs 3 macs instead of 2. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/3563e5fab367e7d79a7f1296fabaa5c20f202d7a.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: ethernet: mtk_eth_soc: add version in mtk_soc_dataLorenzo Bianconi
Introduce version field in mtk_soc_data data structure in order to make mtk_eth driver easier to maintain for chipset configuration codebase. Get rid of MTK_NETSYS_V2 bit in chip capabilities. This is a preliminary patch to introduce support for MT7988 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/e52fae302ca135436e5cdd26d38d87be2da63055.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26dt-bindings: net: mediatek,net: add mt7988-eth bindingDaniel Golle
Introduce DT bindings for the MT7988 SoC to mediatek,net.yaml. The MT7988 SoC got 3 Ethernet MACs operating at a maximum of 10 Gigabit/sec supported by 2 packet processor engines for offloading tasks. The first MAC is hard-wired to a built-in switch which exposes four 1000Base-T PHYs as user ports. It also comes with built-in 2500Base-T PHY which can be used with the 2nd GMAC. The 2nd and 3rd GMAC can be connected to external PHYs or provide SFP(+) cages attached via SGMII, 1000Base-X, 2500Base-X, USXGMII, 5GBase-KR or 10GBase-KR. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/3c83d2c0d629dac064ec4396132538c52e77a57f.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26dt-bindings: net: mediatek,net: add missing mediatek,mt7621-ethDaniel Golle
Document the Ethernet controller found in the MediaTek MT7621 MIPS SoC family which is supported by the mtk_eth_soc driver. Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/ec4371c4b5a331c5217b5f13a0c9e6c444838e14.1690246066.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: phy/pcs: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230724211905.805665-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: dsa: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230724211859.805481-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26Merge branch 'mlxsw-speed-up-transceiver-module-eeprom-dump'Jakub Kicinski
Petr Machata says: ==================== mlxsw: Speed up transceiver module EEPROM dump Ido Schimmel writes: Old firmware versions could only read up to 48 bytes from a transceiver module's EEPROM in one go. Newer versions can read up to 128 bytes, resulting in fewer transactions. Query support for the new capability during driver initialization and if supported, read up to 128 bytes in one go. This is going to be especially useful for upcoming transceiver module firmware flashing support. Before: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 3 devlink:devlink_hwmsg After: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 1 devlink:devlink_hwmsg Patches #1-#4 are preparations / cleanups. Patch #5 adds support for the new read size. ==================== Link: https://lore.kernel.org/r/cover.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26mlxsw: core_env: Read transceiver module EEPROM in 128 bytes chunksIdo Schimmel
Old firmware versions could only read up to 48 bytes from a transceiver module's EEPROM in one go. Newer versions can read up to 128 bytes, resulting in fewer transactions. Query support for the new capability during driver initialization and if supported, read up to 128 bytes in one go. This is going to be especially useful for upcoming transceiver module firmware flashing support. Before: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 3 devlink:devlink_hwmsg After: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 1 devlink:devlink_hwmsg Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/99d1618e8cd5acefb2f795dfde1a5b41caa07dcb.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26mlxsw: reg: Increase Management Cable Info Access Register lengthIdo Schimmel
The layout of the register always supported 128 bytes payloads, but the driver defined the register with a shorter length because it uses a maximum payload size of 48 bytes. Increase the register's length in preparation for using 128 bytes payloads. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/ba5c0f631e2cfd61bd21218d0cbfe03fbfe521f9.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26mlxsw: reg: Remove unused function argumentIdo Schimmel
The 'lock' argument is always set to the default value of '0'. Remove it from the arguments list. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/fb5dd22830622ceeda1c2d6431c27fccd0687aca.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26mlxsw: reg: Add Management Capabilities Mask RegisterAmit Cohen
MCAM register reports the device supported management features. Querying this register exposes if features are supported with the current firmware version in the current ASIC. Then, the driver can separate between different implementations dynamically. MCAM register supports querying whether the MCIA register supports 128 bytes payloads or only 48 bytes. Add support for the register as preparation for allowing larger MCIA transactions. Note that the access to the bits in the field 'mng_feature_cap_mask' is not same to other mask fields in other registers. In most of the cases bit #0 is the first one in the last dword, in MCAM register, bits #0-#31 are in the first dword and so on. Declare the mask field using bits arrays per dword to simplify the access. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/1427a3f57ba93db1c5dd4f982bfb31dd5c82356e.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26mlxsw: reg: Move 'mpsc' definition in 'mlxsw_reg_infos'Amit Cohen
The array 'mlxsw_reg_infos' is ordered by registers' IDs. The ID of MPSC register is 0x9080, so it should be after MCDA (register ID 0x9063) and not after MTUTC (register ID 0x9055). Note that the register's fields are defined in the correct place in the file, only the definition in 'mlxsw_reg_infos' is wrong. This issue was found while adding new register which supposed to be before mpsc. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/c5e270cd5769f301fe81235622215143506e1b48.1690281940.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26dt-bindings: net: qca,ar803x: add missing unevaluatedProperties for each ↵Krzysztof Kozlowski
regulator Each regulator node, which references common regulator.yaml schema, should disallow additional or unevaluated properties. Otherwise mistakes in properties will go unnoticed. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230725123711.149230-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26bcmasp: BCMASP should depend on ARCH_BRCMSTBGeert Uytterhoeven
The Broadcom ASP 2.0 Ethernet controller is only present on Broadcom STB SoCs. Hence add a dependency on ARCH_BRCMSTB, to prevent asking the user about this driver when configuring a kernel without Broadcom ARM-based set-top box chipset support. Fixes: 490cb412007de593 ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Acked-by: Justin Chen <justin.chen@broadcom.com> Link: https://lore.kernel.org/r/1e8b998aa8dcc6e38323e295ee2430b48245cc79.1690299794.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: phy: smsc: add WoL support to LAN8740/LAN8742 PHYsTristram Ha
Microchip LAN8740/LAN8742 PHYs support basic unicast, broadcast, and Magic Packet WoL. They have one pattern filter matching up to 128 bytes of frame data, which can be used to implement ARP or multicast WoL. ARP WoL matches any ARP frame with broadcast address. Multicast WoL matches any multicast frame. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/1690329270-2873-1-git-send-email-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-26net: skbuff: remove unused HAVE_HW_TIME_STAMP feature definePeter Seiderer
Remove unused HAVE_HW_TIME_STAMP feature define (introduced by commit ac45f602ee3d ("net: infrastructure for hardware time stamping"). Signed-off-by: Peter Seiderer <ps.report@gmx.net> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-25Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ice: switchdev bridge offload Wojciech Drewek says: Linux bridge provides ability to learn MAC addresses and vlans detected on bridge's ports. As a result of this, FDB (forward data base) entries are created and they can be offloaded to the HW. By adding VF's port representors to the bridge together with the uplink netdev, we can learn VF's and link partner's MAC addresses. This is achieved by slow/exception-path, where packets that do not match any filters (FDB entries in this case) are send to the bridge ports. Driver keeps track of the netdevs added to the bridge by listening for NETDEV_CHANGEUPPER event. We distinguish two types of bridge ports: uplink port and VF's representor port. Linux bridge always learns src MAC of the packet on rx path. With the current slow-path implementation, it means that we will learn VF's MAC on port repr (when the VF transmits the packet) and link partner's MAC on uplink (when we receive it on uplink from LAN). The driver is notified about learning of the MAC/VLAN by SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation of the HW filter. The direction of the filter is based on port type (uplink or VF repr). In case of the uplink, rule forwards the packets to the LAN (matching on link partner's MAC). When the notification is received on VF repr then the rule forwards the packets to the associated VF (matching on VF's MAC). This approach would not work on its own however. This is because if one of the directions is offloaded, then the bridge would not be able to learn the other one. If the egress rule is added (learned on uplink) then the response from the VF will be sent directly to the LAN. The packet will not got through slow-path, it would not be seen on VF's port repr. Because of that, the bridge would not learn VF's MAC. This is solved by introducing guard rule. It prevents forward rule from working until the opposite direction is offloaded. Aging is not fully supported yet, aging time is static for now. The follow up submissions will introduce counters that will allow us to keep track if the rule is actually being used or not. A few fixes/changes are needed for this feature to work with ice driver. These are introduced in first 5 patches. Reviewed-by: Vlad Buslov <vladbu@nvidia.com> * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: add tracepoints for the switchdev bridge ice: implement static version of ageing ice: implement bridge port vlan ice: Add VLAN FDB support in switchdev mode ice: Add guard rule when creating FDB in switchdev ice: Switchdev FDB events support ice: Implement basic eswitch bridge setup ice: Unset src prune on uplink VSI ice: Disable vlan pruning for uplink VSI ice: Don't tx before switchdev is fully configured ice: Prohibit rx mode change in switchdev mode ice: Skip adv rules removal upon switchdev release ==================== Link: https://lore.kernel.org/r/20230724161152.2177196-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-25net: stmmac: correct MAC propagation delayJohannes Zink
The IEEE1588 Standard specifies that the timestamps of Packets must be captured when the PTP message timestamp point (leading edge of first octet after the start of frame delimiter) crosses the boundary between the node and the network. As the MAC latches the timestamp at an internal point, the captured timestamp must be corrected for the additional path latency, as described in the publicly available datasheet [1]. This patch only corrects for the MAC-Internal delay, which can be read out from the MAC_Ingress_Timestamp_Latency register, since the Phy framework currently does not support querying the Phy ingress and egress latency. The Closs Domain Crossing Circuits errors as indicated in [1] are already being accounted in the stmmac_get_tx_hwtstamp() function and are not corrected here. As the Latency varies for different link speeds and MII modes of operation, the correction value needs to be updated on each link state change. As the delay also causes a phase shift in the timestamp counter compared to the rest of the network, this correction will also reduce phase error when generating PPS outputs from the timestamp counter. [1] i.MX8MP Reference Manual, rev.1 Section 11.7.2.5.3 "Timestamp correction" Signed-off-by: Johannes Zink <j.zink@pengutronix.de> Link: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v2-1-3366f38ee9a6@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-25net: mdio_bus: validate "addr" for mdiobus_is_registered_device()Russell King (Oracle)
mdiobus_is_registered_device() doesn't checking that "addr" was valid before dereferencing bus->mdio_map[]. Extract the code that checks this from mdiobus_get_phy(), and use it here as well. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1qNxvu-00111m-1V@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-25s390/lcs: Remove FDDI optionAlexandra Winter
The last s390 machine that supported FDDI was z900 ('7th generation', released in 2000). The oldest machine generation currently supported by the Linux kernel is MARCH_Z10 (released 2008). If there is still a usecase for connecting a Linux on s390 instance to a LAN Channel Station (LCS), it can only do so via Ethernet. Randy Dunlap[1] found that LCS over FDDI has never worked, when FDDI was compiled as module. Instead of fixing that, remove the FDDI option from the lcs driver. While at it, make the CONFIG_LCS description a bit more helpful. References: [1] https://lore.kernel.org/netdev/20230621213742.8245-1-rdunlap@infradead.org/ Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230724131546.3597001-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-25net: remove redundant NULL check in remove_xps_queue()Zhengchao Shao
There are currently two paths that call remove_xps_queue(): 1. __netif_set_xps_queue -> remove_xps_queue 2. clean_xps_maps -> remove_xps_queue_cpu -> remove_xps_queue There is no need to check dev_maps in remove_xps_queue() because dev_maps has been checked on these two paths. Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20230724023735.2751602-1-shaozhengchao@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-25Merge branch 'support-udp-encapsulation-in-packet-offload-mode'Paolo Abeni
Leon Romanovsky says: ==================== Support UDP encapsulation in packet offload mode As was raised by Ilia in this thread [1], the ESP over UDP feature is supported in packet offload mode. So comes this series, which adds relevant bits to the mlx5 driver and opens XFRM core code to accept such configuration. NAT-T is part of IKEv2 and strongswan uses it automatically [2]. [1] https://lore.kernel.org/all/20230718092405.4124345-1-quic_ilial@quicinc.com [2] https://wiki.strongswan.org/projects/1/wiki/NatTraversal ==================== Link: https://lore.kernel.org/r/cover.1689757619.git.leon@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25xfrm: Support UDP encapsulation in packet offload modeLeon Romanovsky
Since mlx5 supports UDP encapsulation in packet offload, change the XFRM core to allow users to configure it. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net/mlx5e: Support IPsec NAT-T functionalityLeon Romanovsky
Extend mlx5 IPsec packet offload to support UDP encapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net/mlx5e: Check for IPsec NAT-T supportLeon Romanovsky
Set relevant IPsec capability to indicate if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net/mlx5: Add relevant capabilities bits to support NAT-TLeon Romanovsky
Provide an ability to check if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25Merge branch 'remove-legacy-phylink-behaviour'Paolo Abeni
Russell King says: ==================== Remove legacy phylink behaviour This series removes the - as far as I can tell - unreachable code in mtk_eth_soc that relies upon legacy phylink behaviour, and then removes the support in phylink for this legacy behaviour. Patch 1 removes the clocking configuration from mtk_eth_soc for non- TRGMII, non-serdes based interface modes, and disables those interface modes prior to phylink configuration. Patch 2 removes the mac_pcs_get_state() method from mtk_eth_soc which I believe is also not used - mtk_eth_soc appears not to be used with SFPs (which would use a kind of in-band mode) nor does any DT appear to specify in-band mode for any non-serdes based interface mode. With both of those dealt with, the kernel is now free of any driver relying on the phylink legacy mode. Therefore, patch 3 removes support for this. Finally, with the advent of a new driver being submitted today that makes use of state->speed in the mac_config() path, patch 4 ensures that any phylink_link_state member that should not be used in mac_config is either cleared or set to an invalid value. ==================== Link: https://lore.kernel.org/r/ZLw8DoRskRXLQK37@shell.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net: phylink: explicitly invalidate link_state members in mac_configRussell King (Oracle)
Explicitly invalidate the phylink_link_state structure members in mac_config that do not contain reliable information for this function, thereby preventing their future incorrect use. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net: phylink: strip out pre-March 2020 legacy codeRussell King (Oracle)
Strip out all the pre-March 2020 legacy code from phylink now that the last user of it is gone. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net: ethernet: mtk_eth_soc: remove mac_pcs_get_state and moderniseRussell King (Oracle)
Remove the .mac_pcs_get_state function, since as far as I can tell is never called - no DT appears to specify an in-band-status management nor SFP support for this driver. Removal of this, along with the previous patch to remove the incorrect clocking configuration, means that the driver becomes non-legacy, so we can remove the "legacy_pre_march2020" status from this driver. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25net: ethernet: mtk_eth_soc: remove incorrect PLL configurationRussell King (Oracle)
MT7623 GMAC0 attempts to configure the system clocking according to the required speed in the .mac_config callback for non-SGMII, non-baseX and non-TRGMII modes. state->speed setting has never been reliable in the .mac_config callback - there are cases where this is not the link speed, particularly via ethtool paths, so this has always been unreliable (as detailed in phylink's documentation.) There is the additional issue that mtk_gmac0_rgmii_adjust() will only be called if state->interface changes, which means it only configures the system clocking on the very first .mac_config call, which will be made when the network device is first brought up before any link is established. Essentially, this code is incredibly buggy, and probably never worked. Moreover, checking the in-kernel DT files, it seems no platform makes use of this code path. Therefore, let's remove it, and disable interface modes for port 0 that are not SGMII, 1000base-X, 2500base-X or TRGMII on the MT7623. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-25octeontx2-af: Install TC filter rules in hardware based on prioritySuman Ghosh
As of today, hardware does not support installing tc filter rules based on priority. This patch adds support to install the hardware rules based on priority. The final hardware rules will not be dependent on rule installation order, it will be strictly priority based, same as software. Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721043925.2627806-1-sumang@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-07-24mptcp: fix rcv buffer auto-tuningPaolo Abeni
The MPTCP code uses the assumption that the tcp_win_from_space() helper does not use any TCP-specific field, and thus works correctly operating on an MPTCP socket. The commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") broke such assumption, and as a consequence most MPTCP connections stall on zero-window event due to auto-tuning changing the rcv buffer size quite randomly. Address the issue syncing again the MPTCP auto-tuning code with the TCP one. To achieve that, factor out the windows size logic in socket independent helpers, and reuse them in mptcp_rcv_space_adjust(). The MPTCP level scaling_ratio is selected as the minimum one from the all the subflows, as a worst-case estimate. Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20230720-upstream-net-next-20230720-mptcp-fix-rcv-buffer-auto-tuning-v1-1-175ef12b8380@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-24netconsole: Use kstrtobool() instead of kstrtoint()Breno Leitao
Replace kstrtoint() by kstrtobool() in the sysfs _store() functions. This improves the user usability and simplify the code. With this fix, it is now possible to use [YyNn] to set and unset a feature. Old behaviour is still unchanged. kstrtobool() is also safer and doesn't need the extra validation that is required when converting a string to bool (end field in the struct), which makes the code simpler. Suggested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721092146.4036622-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-24netconsole: Use sysfs_emit() instead of snprintf()Breno Leitao
According to the sysfs.rst documentation, _show() functions should only use sysfs_emit() instead of snprintf(). Since snprintf() shouldn't be used in the sysfs _show() path, replace it by sysfs_emit(). Suggested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721092146.4036622-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-24net: add missing net_device::xdp_zc_max_segs descriptionMaciej Fijalkowski
Cited commit under 'Fixes' tag introduced new member to struct net_device without providing description of it - fix it. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20230720141613.61488b9e@canb.auug.org.au/ Fixes: 13ce2daa259a ("xsk: add new netlink attribute dedicated for ZC max frags") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> # build-tested Link: https://lore.kernel.org/r/20230721145808.596298-1-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-24tcx: Fix splat in ingress_destroy upon tcx_entry_freeDaniel Borkmann
On qdisc destruction, the ingress_destroy() needs to update the correct entry, that is, tcx_entry_update must NULL the dev->tcx_ingress pointer. Therefore, fix the typo. Fixes: e420bed02507 ("bpf: Add fd-based tcx multi-prog infra with link support") Reported-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Reported-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Tested-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Tested-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Tested-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20230721233330.5678-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-24ice: add tracepoints for the switchdev bridgePawel Chmielewski
Add tracepoints for the following events: - Add FDB entry - Delete FDB entry - Create bridge VLAN - Cleanup bridge VLAN - Link port to the bridge - Unlink port from the bridge Signed-off-by: Pawel Chmielewski <pawel.chmielewski@intel.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: implement static version of ageingMichal Swiatkowski
Remove fdb entries always when ageing time expired. Allow user to set ageing time using port object attribute. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: implement bridge port vlanMichal Swiatkowski
Port VLAN in this case means push and pop VLAN action on specific vid. There are a few limitation in hardware: - push and pop can't be used separately - if port VLAN is used there can't be any trunk VLANs, because pop action is done on all traffic received by VSI in port VLAN mode - port VLAN mode on uplink port isn't supported Reflect these limitations in code using dev_info to inform the user about unsupported configuration. In bridge mode there is a need to configure port vlan without resetting VFs. To do that implement ice_port_vlan_on/off() functions. They are only configuring correct vlan_ops to allow setting port vlan. We also need to clear port vlan without resetting the VF which is not supported right now. Change it by implementing clear_port_vlan ops. As previous VLAN configuration isn't always the same, store current config while creating port vlan and restore it in clear function. Configuration steps: - configure switchdev with bridge - #bridge vlan add dev eth0 vid 120 pvid untagged - #bridge vlan add dev eth1 vid 120 pvid untagged - ping from VF0 to VF1 Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Add VLAN FDB support in switchdev modeMarcin Szycik
Add support for matching on VLAN tag in bridge offloads. Currently only trunk mode is supported. To enable VLAN filtering (existing FDB entries will be deleted): ip link set $BR type bridge vlan_filtering 1 To add VLANs to bridge in trunk mode: bridge vlan add dev $PF1 vid 110-111 bridge vlan add dev $VF1_PR vid 110-111 Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Add guard rule when creating FDB in switchdevMarcin Szycik
Introduce new "guard" rule upon FDB entry creation. It matches on src_mac, has valid bit unset, allow_pass_l2 set and has a nop action. Previously introduced "forward" rule matches on dst_mac, has valid bit set, need_pass_l2 set and has a forward action. With these rules, a packet will be offloaded only if FDB exists in both directions (RX and TX). Let's assume link partner sends a packet to VF1: src_mac = LP_MAC, dst_mac = is VF1_MAC. Bridge adds FDB, two rules are created: 1. Guard rule matching on src_mac == LP_MAC 2. Forward rule matching on dst_mac == LP_MAC Now VF1 responds with src_mac = VF1_MAC, dst_mac = LP_MAC. Before this change, only one rule with dst_mac == LP_MAC would have existed, and the packet would have been offloaded, meaning the bridge wouldn't add FDB in the opposite direction. Now, the forward rule matches (dst_mac == LP_MAC), but it has need_pass_l2 set an there is no guard rule with src_mac == VF1_MAC, so the packet goes through slow-path and the bridge adds FDB. Two rules are created: 1. Guard rule matching on src_mac == VF1_MAC 2. Forward rule matching on dst_mac == VF1_MAC Further packets in both directions will be offloaded. The same example is true in opposite direction (i.e. VF1 is the first to send a packet out). Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Switchdev FDB events supportWojciech Drewek
Listen for SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events while in switchdev mode. Accept these events on both uplink and VF PR ports. Add HW rules in newly created workqueue. FDB entries are stored in rhashtable for lookup when removing the entry and in the list for cleanup purpose. Direction of the HW rule depends on the type of the ports on which the FDB event was received: ICE_ESWITCH_BR_UPLINK_PORT: TX rule that forwards the packet to the LAN (egress). ICE_ESWITCH_BR_VF_REPR_PORT: RX rule that forwards the packet to the VF associated with the port representor. In both cases the rule matches on the dst mac address. All the FDB entries are stored in the bridge structure. When the port is removed all the FDB entries associated with this port are removed as well. This is achieved thanks to the reference to the port that FDB entry holds. In the fwd rule we use only one lookup type (MAC address) but lkups_cnt variable is already introduced because we will have more lookups in the subsequent patches. Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Implement basic eswitch bridge setupWojciech Drewek
With this patch, ice driver is able to track if the port representors or uplink port were added to the linux bridge in switchdev mode. Listen for NETDEV_CHANGEUPPER events in order to detect this. ice_esw_br data structure reflects the linux bridge and stores all the ports of the bridge (ice_esw_br_port) in xarray, it's created when the first port is added to the bridge and freed once the last port is removed. Note that only one bridge is supported per eswitch. Bridge port (ice_esw_br_port) can be either a VF port representor port or uplink port (ice_esw_br_port_type). In both cases bridge port holds a reference to the VSI, VF's VSI in case of the PR and uplink VSI in case of the uplink. VSI's index is used as an index to the xarray in which ports are stored. Add a check which prevents configuring switchdev mode if uplink is already added to any bridge. This is needed because we need to listen for NETDEV_CHANGEUPPER events to record if the uplink was added to the bridge. Netdevice notifier is registered after eswitch mode is changed to switchdev. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Unset src prune on uplink VSIWojciech Drewek
In switchdev mode uplink VSI is supposed to receive all packets that were not matched by existing filters. If ICE_AQ_VSI_SW_FLAG_LOCAL_LB bit is unset and we have a filter associated with uplink VSI which matches on dst mac equal to MAC1, then packets with src mac equal to MAC1 will be pruned from reaching uplink VSI. Fix this by updating uplink VSI with ICE_AQ_VSI_SW_FLAG_LOCAL_LB bit set when configuring switchdev mode. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-24ice: Disable vlan pruning for uplink VSIWojciech Drewek
In switchdev mode, uplink VSI is configured to be default VSI which means it will receive all unmatched packets. In order to receive vlan packets we need to disable vlan pruning as well. This is done by dis_rx_filtering vlan op. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
generated by cgit (git 2.34.1) at 2024-06-29 21:50:09 +0000