aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/dsa
AgeCommit message (Collapse)AuthorFilesLines
2024-04-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2-39/+213
Cross-merge networking fixes after downstream PR. Conflicts: net/unix/garbage.c 47d8ac011fe1 ("af_unix: Fix garbage collector racing against connect()") 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Adjacent changes: drivers/net/ethernet/broadcom/bnxt/bnxt.c faa12ca24558 ("bnxt_en: Reset PTP tx_avail after possible firmware reset") b3d0083caf9a ("bnxt_en: Support RSS contexts in ethtool .{get|set}_rxfh()") drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c 7ac10c7d728d ("bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()") 194fad5b2781 ("bnxt_en: Refactor bnxt_rdma_aux_device_init/uninit functions") drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c 958f56e48385 ("net/mlx5e: Un-expose functions in en.h") 49e6c9387051 ("net/mlx5e: RSS, Block XOR hash with over 128 channels") Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-11net: dsa: mt7530: trap link-local frames regardless of ST Port StateArınç ÜNAL2-34/+200
In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer (DLL) of the Open Systems Interconnection basic reference model (OSI/RM) are described; the medium access control (MAC) and logical link control (LLC) sublayers. The MAC sublayer is the one facing the physical layer. In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A Bridge component comprises a MAC Relay Entity for interconnecting the Ports of the Bridge, at least two Ports, and higher layer entities with at least a Spanning Tree Protocol Entity included. Each Bridge Port also functions as an end station and shall provide the MAC Service to an LLC Entity. Each instance of the MAC Service is provided to a distinct LLC Entity that supports protocol identification, multiplexing, and demultiplexing, for protocol data unit (PDU) transmission and reception by one or more higher layer entities. It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC Entity associated with each Bridge Port is modeled as being directly connected to the attached Local Area Network (LAN). On the switch with CPU port architecture, CPU port functions as Management Port, and the Management Port functionality is provided by software which functions as an end station. Software is connected to an IEEE 802 LAN that is wholly contained within the system that incorporates the Bridge. Software provides access to the LLC Entity associated with each Bridge Port by the value of the source port field on the special tag on the frame received by software. We call frames that carry control information to determine the active topology and current extent of each Virtual Local Area Network (VLAN), i.e., spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN Registration Protocol Data Units (MVRPDUs), and frames from other link constrained protocols, such as Extensible Authentication Protocol over LAN (EAPOL) and Link Layer Discovery Protocol (LLDP), link-local frames. They are not forwarded by a Bridge. Permanently configured entries in the filtering database (FDB) ensure that such frames are discarded by the Forwarding Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in detail: Each of the reserved MAC addresses specified in Table 8-1 (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be permanently configured in the FDB in C-VLAN components and ERs. Each of the reserved MAC addresses specified in Table 8-2 (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently configured in the FDB in S-VLAN components. Each of the reserved MAC addresses specified in Table 8-3 (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB in TPMR components. The FDB entries for reserved MAC addresses shall specify filtering for all Bridge Ports and all VIDs. Management shall not provide the capability to modify or remove entries for reserved MAC addresses. The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of propagation of PDUs within a Bridged Network, as follows: The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that no conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN) component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward. PDUs transmitted using this destination address, or any other addresses that appear in Table 8-1, Table 8-2, and Table 8-3 (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can therefore travel no further than those stations that can be reached via a single individual LAN from the originating station. The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an address that no conformant S-VLAN component, C-VLAN component, or MAC Bridge can forward; however, this address is relayed by a TPMR component. PDUs using this destination address, or any of the other addresses that appear in both Table 8-1 and Table 8-2 but not in Table 8-3 (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed by any TPMRs but will propagate no further than the nearest S-VLAN component, C-VLAN component, or MAC Bridge. The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an address that no conformant C-VLAN component, MAC Bridge can forward; however, it is relayed by TPMR components and S-VLAN components. PDUs using this destination address, or any of the other addresses that appear in Table 8-1 but not in either Table 8-2 or Table 8-3 (01-80-C2-00-00-[00,0B,0C,0D,0F]), will be relayed by TPMR components and S-VLAN components but will propagate no further than the nearest C-VLAN component or MAC Bridge. Because the LLC Entity associated with each Bridge Port is provided via CPU port, we must not filter these frames but forward them to CPU port. In a Bridge, the transmission Port is majorly decided by ingress and egress rules, FDB, and spanning tree Port State functions of the Forwarding Process. For link-local frames, only CPU port should be designated as destination port in the FDB, and the other functions of the Forwarding Process must not interfere with the decision of the transmission Port. We call this process trapping frames to CPU port. Therefore, on the switch with CPU port architecture, link-local frames must be trapped to CPU port, and certain link-local frames received by a Port of a Bridge comprising a TPMR component or an S-VLAN component must be excluded from it. A Bridge of the switch with CPU port architecture cannot comprise a Two-Port MAC Relay (TPMR) component as a TPMR component supports only a subset of the functionality of a MAC Bridge. A Bridge comprising two Ports (Management Port doesn't count) of this architecture will either function as a standard MAC Bridge or a standard VLAN Bridge. Therefore, a Bridge of this architecture can only comprise S-VLAN components, C-VLAN components, or MAC Bridge components. Since there's no TPMR component, we don't need to relay PDUs using the destination addresses specified on the Nearest non-TPMR section, and the proportion of the Nearest Customer Bridge section where they must be relayed by TPMR components. One option to trap link-local frames to CPU port is to add static FDB entries with CPU port designated as destination port. However, because that Independent VLAN Learning (IVL) is being used on every VID, each entry only applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC Bridge component or a C-VLAN component, there would have to be 16 times 4096 entries. This switch intellectual property can only hold a maximum of 2048 entries. Using this option, there also isn't a mechanism to prevent link-local frames from being discarded when the spanning tree Port State of the reception Port is discarding. The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4 registers. Whilst this applies to every VID, it doesn't contain all of the reserved MAC addresses without affecting the remaining Standard Group MAC Addresses. The REV_UN frame tag utilised using the RGAC4 register covers the remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF destination addresses which may be relayed by MAC Bridges or VLAN Bridges. The latter option provides better but not complete conformance. This switch intellectual property also does not provide a mechanism to trap link-local frames with specific destination addresses to CPU port by Bridge, to conform to the filtering rules for the distinct Bridge components. Therefore, regardless of the type of the Bridge component, link-local frames with these destination addresses will be trapped to CPU port: 01-80-C2-00-00-[00,01,02,03,0E] In a Bridge comprising a MAC Bridge component or a C-VLAN component: Link-local frames with these destination addresses won't be trapped to CPU port which won't conform to IEEE Std 802.1Q-2022: 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] In a Bridge comprising an S-VLAN component: Link-local frames with these destination addresses will be trapped to CPU port which won't conform to IEEE Std 802.1Q-2022: 01-80-C2-00-00-00 Link-local frames with these destination addresses won't be trapped to CPU port which won't conform to IEEE Std 802.1Q-2022: 01-80-C2-00-00-[04,05,06,07,08,09,0A] Currently on this switch intellectual property, if the spanning tree Port State of the reception Port is discarding, link-local frames will be discarded. To trap link-local frames regardless of the spanning tree Port State, make the switch regard them as Bridge Protocol Data Units (BPDUs). This switch intellectual property only lets the frames regarded as BPDUs bypass the spanning tree Port State function of the Forwarding Process. With this change, the only remaining interference is the ingress rules. When the reception Port has no PVID assigned on software, VLAN-untagged frames won't be allowed in. There doesn't seem to be a mechanism on the switch intellectual property to have link-local frames bypass this function of the Forwarding Process. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Reviewed-by: Daniel Golle <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Link: https://lore.kernel.org/r/20240409-b4-for-net-mt7530-fix-link-local-when-stp-discarding-v2-1-07b1150164ac@arinc9.com Signed-off-by: Paolo Abeni <[email protected]>
2024-04-10net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boardsArınç ÜNAL2-5/+13
The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board (bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to SkyLake Huang (黃啟澤) from MediaTek for providing information on the internal EEE switch bit. There are existing boards that were not designed to pull the pin low. Because of that, the EEE status currently depends on the board design. The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually used to control an LED. Once the bit is unset, the pin will be low. That will make the active low LED turn on. The pin is controlled by the switch PHY. It seems that the PHY controls the pin in the way that it inverts the pin state. That means depending on the wiring of the LED connected to LAN2LED0 on the board, the LED may be on without an active link. To not cause this unwanted behaviour whilst enabling EEE on all boards, set the internal EEE switch bit on the CORE_PLL_GROUP4 register. My testing on MT7531 shows a certain amount of traffic loss when EEE is enabled. That said, I haven't come across a board that enables EEE. So enable EEE on the switch MACs but disable EEE advertisement on the switch PHYs. This way, we don't change the behaviour of the majority of the boards that have this switch. The mediatek-ge PHY driver already disables EEE advertisement on the switch PHYs but my testing shows that it is somehow enabled afterwards. Disabling EEE advertisement before the PHY driver initialises keeps it off. With this change, EEE can now be enabled using ethtool. Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Tested-by: Daniel Golle <[email protected]> Reviewed-by: Daniel Golle <[email protected]> Link: https://lore.kernel.org/r/20240408-for-net-mt7530-fix-eee-for-mt7531-mt7988-v3-1-84fdef1f008b@arinc9.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8_r_dyn_mac_table(): use entries variable to signal ↵Oleksij Rempel1-17/+7
0 entries We already have a variable to provide number of entries. So use it, instead of using error number. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8_r_dyn_mac_table(): return read/write error if we ↵Oleksij Rempel1-5/+15
got any The read/write path may fail. So, return error if we got it. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8_r_dyn_mac_table(): ksz: do not return EAGAIN on ↵Oleksij Rempel1-6/+5
timeout EAGAIN was not used by previous code and not used by current code. So, remove it and use proper error value. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8: Unify variable naming in ksz8_r_dyn_mac_table()Oleksij Rempel1-6/+6
Use 'ret' instead of 'rc' in ksz8_r_dyn_mac_table() to maintain consistency with the rest of the file. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8: Refactor ksz8_r_dyn_mac_table() for readabilityOleksij Rempel1-29/+31
Move the code out of a long if statement scope in ksz8_r_dyn_mac_table() to improve code readability. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: ksz8: Refactor ksz8_fdb_dump()Oleksij Rempel2-13/+17
Refactor ksz8_fdb_dump() to address potential issues: - Limit the number of iterations to avoid endless loops. - Handle error codes returned by ksz8_r_dyn_mac_table(), with an exception for -ENXIO when no more dynamic entries are detected. Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: Make ksz8_r_dyn_mac_table() staticOleksij Rempel2-4/+2
ksz8_r_dyn_mac_table() is not used outside the source file. Make it static. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: microchip: Remove unused FDB timestamp support in ↵Oleksij Rempel2-6/+3
ksz8_r_dyn_mac_table() The FDB timestamps are not being utilized. This commit removes the unused timestamp support from ksz8_r_dyn_mac_table() function. Reviewed-by: Vladimir Oltean <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2-2/+6
Cross-merge networking fixes after downstream PR. Conflicts: net/ipv4/ip_gre.c 17af420545a7 ("erspan: make sure erspan_base_hdr is present in skb->head") 5832c4a77d69 ("ip_tunnel: convert __be16 tunnel flags to bitmaps") https://lore.kernel.org/all/[email protected]/ Adjacent changes: net/ipv6/ip6_fib.c d21d40605bca ("ipv6: Fix infinite recursion in fib6_dump_done().") 5fc68320c1fb ("ipv6: remove RTNL protection from inet6_dump_fib()") Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-04net: dsa: sja1105: Fix parameters order in sja1110_pcs_mdio_write_c45()Christophe JAILLET1-1/+1
The definition and declaration of sja1110_pcs_mdio_write_c45() don't have parameters in the same order. Knowing that sja1110_pcs_mdio_write_c45() is used as a function pointer in 'sja1105_info' structure with .pcs_mdio_write_c45, and that we have: int (*pcs_mdio_write_c45)(struct mii_bus *bus, int phy, int mmd, int reg, u16 val); it is likely that the definition is the one to change. Found with cppcheck, funcArgOrderDifferent. Fixes: ae271547bba6 ("net: dsa: sja1105: C45 only transactions for PCS") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Michael Walle <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/ff2a5af67361988b3581831f7bd1eddebfb4c48f.1712082763.git.christophe.jaillet@wanadoo.fr Signed-off-by: Paolo Abeni <[email protected]>
2024-04-02net: dsa: sja1105: drop driver owner assignmentKrzysztof Kozlowski1-1/+0
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-04-02net: dsa: microchip: drop driver owner assignmentKrzysztof Kozlowski1-1/+0
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-29net: dsa: mv88e6xxx: fix usable ports on 88e6020Michael Krummsdorf1-1/+5
The switch has 4 ports with 2 internal PHYs, but ports are numbered up to 6, with ports 0, 1, 5 and 6 being usable. Fixes: 71d94a432a15 ("net: dsa: mv88e6xxx: add support for MV88E6020 switch") Signed-off-by: Michael Krummsdorf <[email protected]> Signed-off-by: Matthias Schiffer <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-29net: dsa: hellcreek: Convert to gettimex64()Kurt Kanzenbach1-10/+15
As of commit 916444df305e ("ptp: deprecate gettime64() in favor of gettimex64()") (new) PTP drivers should rather implement gettimex64(). In addition, this variant provides timestamps from the system clock. The readings have to be recorded right before and after reading the lowest bits of the PHC timestamp. Reported-by: Thomas Gleixner <[email protected]> Signed-off-by: Kurt Kanzenbach <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-03-26net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530Arınç ÜNAL1-2/+3
The MT7530 switch after reset initialises with a core clock frequency that works with a 25MHz XTAL connected to it. For 40MHz XTAL, the core clock frequency must be set to 500MHz. The mt7530_pll_setup() function is responsible of setting the core clock frequency. Currently, it runs on MT7530 with 25MHz and 40MHz XTAL. This causes MT7530 switch with 25MHz XTAL to egress and ingress frames improperly. Introduce a check to run it only on MT7530 with 40MHz XTAL. The core clock frequency is set by writing to a switch PHY's register. Access to the PHY's register is done via the MDIO bus the switch is also on. Therefore, it works only when the switch makes switch PHYs listen on the MDIO bus the switch is on. This is controlled either by the state of the ESW_P1_LED_1 pin after reset deassertion or modifying bit 5 of the modifiable trap register. When ESW_P1_LED_1 is pulled high, PHY indirect access is used. That means accessing PHY registers via the PHY indirect access control register of the switch. When ESW_P1_LED_1 is pulled low, PHY direct access is used. That means accessing PHY registers via the MDIO bus the switch is on. For MT7530 switch with 40MHz XTAL on a board with ESW_P1_LED_1 pulled high, the core clock frequency won't be set to 500MHz, causing the switch to egress and ingress frames improperly. Run mt7530_pll_setup() after PHY direct access is set on the modifiable trap register. With these two changes, all MT7530 switches with 25MHz and 40MHz, and P1_LED_1 pulled high or low, will egress and ingress frames properly. Link: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/4a5dd143f2172ec97a2872fa29c7c4cd520f45b5/linux-mt/drivers/net/ethernet/mediatek/gsw_mt7623.c#L1039 Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <[email protected]> Link: https://lore.kernel.org/r/20240320-for-net-mt7530-fix-25mhz-xtal-with-direct-phy-access-v1-1-d92f605f1160@arinc9.com Signed-off-by: Paolo Abeni <[email protected]>
2024-03-21net: dsa: mt7530: fix handling of all link-local framesArınç ÜNAL2-4/+46
Currently, the MT753X switches treat frames with :01-0D and :0F MAC DAs as regular multicast frames, therefore flooding them to user ports. On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA must only be propagated to C-VLAN and MAC Bridge components. That means VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports, these frames are supposed to be processed by the CPU (software). So we make the switch only forward them to the CPU port. And if received from a CPU port, forward to a single port. The software is responsible of making the switch conform to the latter by setting a single port as destination port on the special tag. This switch intellectual property cannot conform to this part of the standard fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC DAs, it also includes :22-FF which the scope of propagation is not supposed to be restricted for these MAC DAs. Set frames with :01-03 MAC DAs to be trapped to the CPU port(s). Add a comment for the remaining MAC DAs. Note that the ingress port must have a PVID assigned to it for the switch to forward untagged frames. A PVID is set by default on VLAN-aware and VLAN-unaware ports. However, when the network interface that pertains to the ingress port is attached to a vlan_filtering enabled bridge, the user can remove the PVID assignment from it which would prevent the link-local frames from being trapped to the CPU port. I am yet to see a way to forward link-local frames while preventing other untagged frames from being forwarded too. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-21net: dsa: mt7530: fix link-local frames that ingress vlan filtering portsArınç ÜNAL2-9/+23
Whether VLAN-aware or not, on every VID VLAN table entry that has the CPU port as a member of it, frames are set to egress the CPU port with the VLAN tag stacked. This is so that VLAN tags can be appended after hardware special tag (called DSA tag in the context of Linux drivers). For user ports on a VLAN-unaware bridge, frame ingressing the user port egresses CPU port with only the special tag. For user ports on a VLAN-aware bridge, frame ingressing the user port egresses CPU port with the special tag and the VLAN tag. This causes issues with link-local frames, specifically BPDUs, because the software expects to receive them VLAN-untagged. There are two options to make link-local frames egress untagged. Setting CONSISTENT or UNTAGGED on the EG_TAG bits on the relevant register. CONSISTENT means frames egress exactly as they ingress. That means egressing with the VLAN tag they had at ingress or egressing untagged if they ingressed untagged. Although link-local frames are not supposed to be transmitted VLAN-tagged, if they are done so, when egressing through a CPU port, the special tag field will be broken. BPDU egresses CPU port with VLAN tag egressing stacked, received on software: 00:01:25.104821 AF Unknown (382365846), length 106: | STAG | | VLAN | 0x0000: 0000 6c27 614d 4143 0001 0000 8100 0001 ..l'aMAC........ 0x0010: 0026 4242 0300 0000 0000 0000 6c27 614d .&BB........l'aM 0x0020: 4143 0000 0000 0000 6c27 614d 4143 0000 AC......l'aMAC.. 0x0030: 0000 1400 0200 0f00 0000 0000 0000 0000 ................ BPDU egresses CPU port with VLAN tag egressing untagged, received on software: 00:23:56.628708 AF Unknown (25215488), length 64: | STAG | 0x0000: 0000 6c27 614d 4143 0001 0000 0026 4242 ..l'aMAC.....&BB 0x0010: 0300 0000 0000 0000 6c27 614d 4143 0000 ........l'aMAC.. 0x0020: 0000 0000 6c27 614d 4143 0000 0000 1400 ....l'aMAC...... 0x0030: 0200 0f00 0000 0000 0000 0000 ............ BPDU egresses CPU port with VLAN tag egressing tagged, received on software: 00:01:34.311963 AF Unknown (25215488), length 64: | Mess | 0x0000: 0000 6c27 614d 4143 0001 0001 0026 4242 ..l'aMAC.....&BB 0x0010: 0300 0000 0000 0000 6c27 614d 4143 0000 ........l'aMAC.. 0x0020: 0000 0000 6c27 614d 4143 0000 0000 1400 ....l'aMAC...... 0x0030: 0200 0f00 0000 0000 0000 0000 ............ To prevent confusing the software, force the frame to egress UNTAGGED instead of CONSISTENT. This way, frames can't possibly be received TAGGED by software which would have the special tag field broken. VLAN Tag Egress Procedure For all frames, one of these options set the earliest in this order will apply to the frame: - EG_TAG in certain registers for certain frames. This will apply to frame with matching MAC DA or EtherType. - EG_TAG in the address table. This will apply to frame at its incoming port. - EG_TAG in the PVC register. This will apply to frame at its incoming port. - EG_CON and [EG_TAG per port] in the VLAN table. This will apply to frame at its outgoing port. - EG_TAG in the PCR register. This will apply to frame at its outgoing port. EG_TAG in certain registers for certain frames: PPPoE Discovery_ARP/RARP: PPP_EG_TAG and ARP_EG_TAG in the APC register. IGMP_MLD: IGMP_EG_TAG and MLD_EG_TAG in the IMC register. BPDU and PAE: BPDU_EG_TAG and PAE_EG_TAG in the BPC register. REV_01 and REV_02: R01_EG_TAG and R02_EG_TAG in the RGAC1 register. REV_03 and REV_0E: R03_EG_TAG and R0E_EG_TAG in the RGAC2 register. REV_10 and REV_20: R10_EG_TAG and R20_EG_TAG in the RGAC3 register. REV_21 and REV_UN: R21_EG_TAG and RUN_EG_TAG in the RGAC4 register. With this change, it can be observed that a bridge interface with stp_state and vlan_filtering enabled will properly block ports now. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-18net: dsa: mt7530: prevent possible incorrect XTAL frequency selectionArınç ÜNAL1-10/+4
On MT7530, the HT_XTAL_FSEL field of the HWTRAP register stores a 2-bit value that represents the frequency of the crystal oscillator connected to the switch IC. The field is populated by the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins, which is done right after reset is deasserted. ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 0 Reserved 0 1 20MHz 1 0 40MHz 1 1 25MHz On MT7531, the XTAL25 bit of the STRAP register stores this. The LAN0LED0 pin is used to populate the bit. 25MHz when the pin is high, 40MHz when it's low. These pins are also used with LEDs, therefore, their state can be set to something other than the bootstrapping configuration. For example, a link may be established on port 3 before the DSA subdriver takes control of the switch which would set ESW_P3_LED_0 to high. Currently on mt7530_setup() and mt7531_setup(), 1000 - 1100 usec delay is described between reset assertion and deassertion. Some switch ICs in real life conditions cannot always have these pins set back to the bootstrapping configuration before reset deassertion in this amount of delay. This causes wrong crystal frequency to be selected which puts the switch in a nonfunctional state after reset deassertion. The tests below are conducted on an MT7530 with a 40MHz crystal oscillator by Justin Swartz. With a cable from an active peer connected to port 3 before reset, an incorrect crystal frequency (0b11 = 25MHz) is selected: [1] [3] [5] : : : _____________________________ __________________ ESW_P4_LED_0 |_______| _____________________________ ESW_P3_LED_0 |__________________________ : : : : : : [4]...: : : [2]................: [1] Reset is asserted. [2] Period of 1000 - 1100 usec. [3] Reset is deasserted. [4] Period of 315 usec. HWTRAP register is populated with incorrect XTAL frequency. [5] Signals reflect the bootstrapped configuration. Increase the delay between reset_control_assert() and reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and gpiod_set_value_cansleep(priv->reset, 1) to 5000 - 5100 usec. This amount ensures a higher possibility that the switch IC will have these pins back to the bootstrapping configuration before reset deassertion. With a cable from an active peer connected to port 3 before reset, the correct crystal frequency (0b10 = 40MHz) is selected: [1] [2-1] [3] [5] : : : : _____________________________ __________________ ESW_P4_LED_0 |_______| ___________________ _______ ESW_P3_LED_0 |_________| |__________________ : : : : : : [2-2]...: [4]...: [2]................: [1] Reset is asserted. [2] Period of 5000 - 5100 usec. [2-1] ESW_P3_LED_0 goes low. [2-2] Remaining period of 5000 - 5100 usec. [3] Reset is deasserted. [4] Period of 310 usec. HWTRAP register is populated with bootstrapped XTAL frequency. [5] Signals reflect the bootstrapped configuration. ESW_P3_LED_0 low period before reset deassertion: 5000 usec - 5100 usec TEST RESET HOLD # (usec) --------------------- 1 5410 2 5440 3 4375 4 5490 5 5475 6 4335 7 4370 8 5435 9 4205 10 4335 11 3750 12 3170 13 4395 14 4375 15 3515 16 4335 17 4220 18 4175 19 4175 20 4350 Min 3170 Max 5490 Median 4342.500 Avg 4466.500 Revert commit 2920dd92b980 ("net: dsa: mt7530: disable LEDs before reset"). Changing the state of pins via reset assertion is simpler and more efficient than doing so by setting the LED controller off. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Co-developed-by: Justin Swartz <[email protected]> Signed-off-by: Justin Swartz <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-03-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-4/+6
Merge in late fixes to prepare for the 6.9 net-next PR. Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-11net: dsa: mt7530: disable LEDs before resetJustin Swartz1-0/+6
Disable LEDs just before resetting the MT7530 to avoid situations where the ESW_P4_LED_0 and ESW_P3_LED_0 pin states may cause an unintended external crystal frequency to be selected. The HT_XTAL_FSEL (External Crystal Frequency Selection) field of HWTRAP (the Hardware Trap register) stores a 2-bit value that represents the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins (seemingly) sampled just after the MT7530 has been reset, as: ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 1 20MHz 1 0 40MHz 1 1 25MHz The value of HT_XTAL_FSEL is bootstrapped by pulling ESW_P4_LED_0 and ESW_P3_LED_0 up or down accordingly, but: if a 40MHz crystal has been selected and the ESW_P3_LED_0 pin is high during reset, or a 20MHz crystal has been selected and the ESW_P4_LED_0 pin is high during reset, then the value of HT_XTAL_FSEL will indicate that a 25MHz crystal is present. By default, the state of the LED pins is PHY controlled to reflect the link state. To illustrate, if a board has: 5 ports with active low LED control, and HT_XTAL_FSEL bootstrapped for 40MHz. When the MT7530 is powered up without any external connection, only the LED associated with Port 3 is illuminated as ESW_P3_LED_0 is low. In this state, directly after mt7530_setup()'s reset is performed, the HWTRAP register (0x7800) reflects the intended HT_XTAL_FSEL (HWTRAP bits 10:9) of 40MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007dcf >>> bin(0x7dcf >> 9 & 0b11) '0b10' But if a cable is connected to Port 3 and the link is active before mt7530_setup()'s reset takes place, then HT_XTAL_FSEL seems to be set for 25MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007fcf >>> bin(0x7fcf >> 9 & 0b11) '0b11' Once HT_XTAL_FSEL reflects 25MHz, none of the ports are functional until the MT7621 (or MT7530 itself) is reset. By disabling the LED pins just before reset, the chance of an unintended HT_XTAL_FSEL value is reduced. Signed-off-by: Justin Swartz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-07net: dsa: mv88e6xxx: update 88e6185 PCS driver to use neg_modeRussell King (Oracle)1-1/+2
Update the Marvell 88e6185 PCS driver to use neg_mode rather than the mode argument to match the other updated PCS drivers. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-07net: dsa: microchip: make sure drive strength configuration is not lost by ↵Oleksij Rempel1-4/+6
soft reset This driver has two separate reset sequence in different places: - gpio/HW reset on start of ksz_switch_register() - SW reset on start of ksz_setup() The second one will overwrite drive strength configuration made in the ksz_switch_register(). To fix it, move ksz_parse_drive_strength() from ksz_switch_register() to ksz_setup(). Fixes: d67d7247f641 ("net: dsa: microchip: Add drive strength configuration") Signed-off-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-2/+2
Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: net/core/page_pool_user.c 0b11b1c5c320 ("netdev: let netlink core handle -EMSGSIZE errors") 429679dcf7d9 ("page_pool: fix netlink dump stop/resume") Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-05net: dsa: microchip: fix register write order in ksz8_ind_write8()Tobias Jakobi (Compleo)1-2/+2
This bug was noticed while re-implementing parts of the kernel driver in userspace using spidev. The goal was to enable some of the errata workarounds that Microchip describes in their errata sheet [1]. Both the errata sheet and the regular datasheet of e.g. the KSZ8795 imply that you need to do this for indirect register accesses: - write a 16-bit value to a control register pair (this value consists of the indirect register table, and the offset inside the table) - either read or write an 8-bit value from the data storage register (indicated by REG_IND_BYTE in the kernel) The current implementation has the order swapped. It can be proven, by reading back some indirect register with known content (the EEE register modified in ksz8_handle_global_errata() is one of these), that this implementation does not work. Private discussion with Oleksij Rempel of Pengutronix has revealed that the workaround was apparantly never tested on actual hardware. [1] https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/KSZ87xx-Errata-DS80000687C.pdf Signed-off-by: Tobias Jakobi (Compleo) <[email protected]> Reviewed-by: Oleksij Rempel <[email protected]> Fixes: 7b6e6235b664 ("net: dsa: microchip: ksz8795: handle eee specif erratum") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-03-05net: dsa: mt7530: simplify link operationsArınç ÜNAL2-13/+1
The "MT7621 Giga Switch Programming Guide v0.3", "MT7531 Reference Manual for Development Board v1.0", and "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1" documents show that these bits are enabled at reset: PMCR_IFG_XMIT(1) (not part of PMCR_LINK_SETTINGS_MASK) PMCR_MAC_MODE (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_EN PMCR_RX_EN PMCR_BACKOFF_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_BACKPR_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_FC_EN PMCR_RX_FC_EN These bits also don't exist on the MT7530_PMCR_P(6) register of the switch on the MT7988 SoC: PMCR_IFG_XMIT() PMCR_MAC_MODE PMCR_BACKOFF_EN PMCR_BACKPR_EN Remove the setting of the bits not part of PMCR_LINK_SETTINGS_MASK on phylink_mac_config as they're already set. The bit for setting the port on force mode is already done on mt7530_setup() and mt7531_setup_common(). So get rid of PMCR_FORCE_MODE_ID() which helped determine which bit to use for the switch model. Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: sort link settings ops and force link down on all portsArınç ÜNAL1-2/+12
port_enable and port_disable clears the link settings. Move that to mt7530_setup() and mt7531_setup_common() which set up the switches. This way, the link settings are cleared on all ports at setup, and then only once with phylink_mac_link_down() when a link goes down. Enable force mode at setup to apply the force part of the link settings. This ensures that disabled ports will have their link down. Suggested-by: Vladimir Oltean <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: put initialising PCS devices code back to original orderArınç ÜNAL1-10/+10
The commit fae463084032 ("net: dsa: mt753x: fix pcs conversion regression") fixes regression caused by cpu_port_config manually calling phylink operations. cpu_port_config was deemed useless and was removed. Therefore, put initialising PCS devices code back to its original order. Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: get rid of mt753x_mac_config()Arınç ÜNAL1-12/+2
There is no need for a separate function to call priv->info->mac_port_config(). Call it from mt753x_phylink_mac_config() instead and remove mt753x_mac_config(). Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: get rid of priv->info->cpu_port_config()Arınç ÜNAL2-118/+7
priv->info->cpu_port_config() is used for MT7531 and the switch on the MT7988 SoC. It sets up the ports described as a CPU port earlier than the phylink code path would do. This function is useless as: - Configuring the MACs can be done from the phylink_mac_config code path instead. - All the link configuration it does on the CPU ports are later undone with the port_enable, phylink_mac_config, and then phylink_mac_link_up code path [1]. priv->p5_interface and priv->p6_interface were being used to prevent configuring the MACs from the phylink_mac_config code path. Remove them now that they hold no purpose. Remove priv->info->cpu_port_config(). On mt753x_phylink_mac_config, switch to if statements to simplify the code. Remove the overwriting of the speed and duplex interfaces for certain interface modes. Phylink already provides the speed and duplex variables with proper values. Phylink already sets the max speed of TRGMII to SPEED_1000. Add SPEED_2500 for PHY_INTERFACE_MODE_2500BASEX to where the speed and EEE bits are set instead. On the switch on the MT7988 SoC, PHY_INTERFACE_MODE_INTERNAL is being used to describe the interface mode of the 10G MAC, which is of port 6. On mt7988_cpu_port_config() PMCR_FORCE_SPEED_1000 was set via the PMCR_CPU_PORT_SETTING() mask. Add SPEED_10000 case to where the speed bits are set to cover this. No need to add it to where the EEE bits are set as the "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1" document shows that these bits don't exist on the MT7530_PMCR_P(6) register. Remove the definition of PMCR_CPU_PORT_SETTING() now that it holds no purpose. Change mt753x_cpu_port_enable() to void now that there're no error cases left. Link: https://lore.kernel.org/netdev/[email protected]/ [1] Suggested-by: Russell King (Oracle) <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: get rid of useless error returns on phylink code pathArınç ÜNAL2-68/+19
Remove error returns on the cases where they are already handled with the function the mac_port_get_caps member in mt753x_table points to. mt7531_mac_config() is also called from mt7531_cpu_port_config() outside of phylink but the port and interface modes are already handled there. Change the functions and the mac_port_config function pointer to void now that there're no error returns anymore. Remove mt753x_is_mac_port() that used to help the said error returns. On mt7531_mac_config(), switch to if statements to simplify the code. Remove internal phy cases from mt753x_phylink_mac_config(), there is no need to check the interface mode as that's already handled with the function the mac_port_get_caps member in mt753x_table points to. Acked-by: Daniel Golle <[email protected]> Tested-by: Daniel Golle <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: do not use SW_PHY_RST to reset MT7531 switchArınç ÜNAL1-4/+2
According to the document MT7531 Reference Manual for Development Board v1.0, the SW_PHY_RST bit on the SYS_CTRL register doesn't exist for MT7531. This is likely why forcing link down on all ports is necessary for MT7531. Therefore, do not set SW_PHY_RST on mt7531_setup(). Signed-off-by: Arınç ÜNAL <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: set interrupt register only for MT7530Arınç ÜNAL1-1/+1
Setting this register related to interrupts is only needed for the MT7530 switch. Make an exclusive check to ensure this. Signed-off-by: Arınç ÜNAL <[email protected]> Acked-by: Daniel Golle <[email protected]> Tested-by: Daniel Golle <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-03-05net: dsa: mt7530: remove .mac_port_config for MT7988 and make it optionalArınç ÜNAL1-14/+4
For the switch on the MT7988 SoC, the mac_port_config member for ID_MT7988 in mt753x_table is not needed as the interfaces of all MACs are already handled on mt7988_mac_port_get_caps(). Therefore, remove the mac_port_config member from ID_MT7988 in mt753x_table. Before calling priv->info->mac_port_config(), if there's no mac_port_config member in mt753x_table, exit mt753x_mac_config() successfully. Remove calling priv->info->mac_port_config() from the sanity check as the sanity check requires a pointer to a mac_port_config function to be non-NULL. This will fail for MT7988 as mac_port_config won't be a member of its info table. Co-developed-by: Daniel Golle <[email protected]> Signed-off-by: Daniel Golle <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-02-29net: dsa: mv88e6xxx: add Amethyst specific SMI GPIO functionRobert Marko3-1/+37
The existing mv88e6390_g2_scratch_gpio_set_smi() cannot be used on the 88E6393X as it requires certain P0_MODE, it also checks the CPU mode as it impacts the bit setting value. This is all irrelevant for Amethyst (MV88E6191X/6193X/6393X) as only the default value of the SMI_PHY Config bit is set to CPU_MGD bootstrap pin value but it can be changed without restrictions so that GPIO pins 9 and 10 are used as SMI pins. So, introduce Amethyst specific function and call that if the Amethyst family wants to setup the external PHY. Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-02-29net: dsa: mv88e6xxx: rename mv88e6xxx_g2_scratch_gpio_set_smiRobert Marko3-4/+4
The name mv88e6xxx_g2_scratch_gpio_set_smi is a bit ambiguous as it appears to only be applicable to the 6390 family, so lets rename it to mv88e6390_g2_scratch_gpio_set_smi to make it more obvious. Signed-off-by: Robert Marko <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-02-28net: dsa: realtek: support reset controllerLuiz Angelo Daros de Luca3-5/+41
Add support for resetting the device using a reset controller, complementing the existing GPIO reset functionality (reset-gpios). Although the reset is optional and the driver performs a soft reset during setup, if the initial reset pin state was asserted, the driver will not detect the device until the reset is deasserted. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Alvin Šipraga <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-26net: dsa: microchip: Add support for bridge port isolationOleksij Rempel2-5/+51
Implement bridge port isolation for KSZ switches. Enabling the isolation of switch ports from each other while maintaining connectivity with the CPU and other forwarding ports. For instance, to isolate swp1 and swp2 from each other, use the following commands: - bridge link set dev swp1 isolated on - bridge link set dev swp2 isolated on Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-0/+1
Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: net/core/dev.c 9f30831390ed ("net: add rcu safety to rtnl_prop_list_size()") 723de3ebef03 ("net: free altname using an RCU callback") net/unix/garbage.c 11498715f266 ("af_unix: Remove io_uring code for GC.") 25236c91b5ab ("af_unix: Fix task hung while purging oob_skb in GC.") drivers/net/ethernet/renesas/ravb_main.c ed4adc07207d ("net: ravb: Count packets instead of descriptors in GbEth RX path" ) c2da9408579d ("ravb: Add Rx checksum offload support for GbEth") net/mptcp/protocol.c bdd70eb68913 ("mptcp: drop the push_pending field") 28e5c1380506 ("mptcp: annotate lockless accesses around read-mostly fields") Signed-off-by: Jakub Kicinski <[email protected]>
2024-02-13net: dsa: realtek: fix digital interface select macro for EXT0Luiz Angelo Daros de Luca1-2/+2
While no supported devices currently utilize EXT0, the register reserves the bits for an EXT0. EXT0 is utilized by devices from the generation prior to rtl8365mb, such as those supported by the driver library rtl8367b. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Alvin Šipraga <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-02-12net: dsa: realtek: embed dsa_switch into realtek_privLuiz Angelo Daros de Luca4-16/+19
Embed dsa_switch within realtek_priv to eliminate the need for a second memory allocation. Suggested-by: Alvin Šipraga <[email protected]> Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: use the same mii bus driver for both interfacesLuiz Angelo Daros de Luca6-97/+14
The realtek-mdio will now use this driver instead of the generic DSA driver ("dsa user smi"), which should not be used with OF[1]. With a single ds_ops for both interfaces, the ds_ops in realtek_priv is no longer necessary. Now, the realtek_variant.ds_ops can be used directly. The realtek_priv.setup_interface() has been removed as we can directly call the new common function. [1] https://lkml.kernel.org/netdev/[email protected]/T/ Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: migrate user_mii_bus setup to realtek_dsaLuiz Angelo Daros de Luca3-56/+70
In the user MDIO driver, despite numerous references to SMI, including its compatible string, there's nothing inherently specific about the SMI interface in the user MDIO bus. Consequently, the code has been migrated to the rtl83xx module. All references to SMI have been eliminated. The MDIO bus id was changed from Realtek-<switch id> to the switch devname suffixed with :user_mii, giving more information about the bus it is referencing. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: clean user_mii_bus setupLuiz Angelo Daros de Luca1-10/+3
Remove the line assigning dev.of_node in mdio_bus as subsequent of_mdiobus_register will always overwrite it. As discussed in [1], allow the DSA core to be simplified, by not assigning ds->user_mii_bus when the MDIO bus is described in OF, as it is unnecessary. Since commit 3b73a7b8ec38 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), we can put the "mdio" node just after the MDIO bus registration. [1] https://lkml.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/T/#u Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: get internal MDIO node by nameLuiz Angelo Daros de Luca1-1/+1
The binding docs requires for SMI-connected devices that the switch must have a child node named "mdio" and with a compatible string of "realtek,smi-mdio". Meanwile, for MDIO-connected switches, the binding docs only requires a child node named "mdio". This patch changes the driver to use the common denominator for both interfaces, looking for the MDIO node by name, ignoring the compatible string. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: merge rtl83xx and interface modules into realtek_dsaLuiz Angelo Daros de Luca5-14/+12
Since rtl83xx and realtek-{smi,mdio} are always loaded together, we can optimize resource usage by consolidating them into a single module. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: common rtl83xx moduleLuiz Angelo Daros de Luca8-273/+322
Some code can be shared between both interface modules (MDIO and SMI) and among variants. These interface functions migrated to a common module: - rtl83xx_lock - rtl83xx_unlock - rtl83xx_probe - rtl83xx_register_switch - rtl83xx_unregister_switch - rtl83xx_shutdown - rtl83xx_remove The reset during probe was moved to the end of the common probe. This way, we avoid a reset if anything else fails. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-12net: dsa: realtek: keep variant reference in realtek_privLuiz Angelo Daros de Luca3-12/+7
Instead of copying values from the variant, we can keep a reference in realtek_priv. This is a preliminary change for sharing code betwen interfaces. It will allow to move most of the probe into a common module while still allow code specific to each interface to read variant fields. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.