aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa
AgeCommit message (Collapse)AuthorFilesLines
2025-11-26net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing trafficVladimir Oltean1-7/+0
When using the SGMII PCS as a fixed-link chip-to-chip connection, it is easy to miss the fact that traffic passes only at 1G, since that's what any normal such connection would use. When using the SGMII PCS connected towards an on-board PHY or an SFP module, it is immediately noticeable that when the link resolves to a speed other than 1G, traffic from the MAC fails to pass: TX counters increase, but nothing gets decoded by the other end, and no local RX counters increase either. Artificially lowering a fixed-link rate to speed = <100> makes us able to see the same issue as in the case of having an SGMII PHY. Some debugging shows that the XPCS configuration is A-OK, but that the MAC Configuration Table entry for the port has the SPEED bits still set to 1000Mbps, due to a special condition in the driver. Deleting that condition, and letting the resolved link speed be programmed directly into the MAC speed field, results in a functional link at all 3 speeds. This piece of evidence, based on testing on both generations with SGMII support (SJA1105S and SJA1110A) directly contradicts the statement from the blamed commit that "the MAC is fixed at 1 Gbps and we need to configure the PCS only (if even that)". Worse, that statement is not backed by any documentation, and no one from NXP knows what it might refer to. I am unable to recall sufficient context regarding my testing from March 2020 to understand what led me to draw such a braindead and factually incorrect conclusion. Yet, there is nothing of value regarding forcing the MAC speed, either for SGMII or 2500Base-X (introduced at a later stage), so remove all such logic. Fixes: ffe10e679cec ("net: dsa: sja1105: Add support for the SGMII port") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20251122111324.136761-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-25net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()Bastien Curutchet (Schneider Electric)1-11/+7
The IRQ numbers created through irq_create_mapping() are only assigned to ptpmsg_irq[n].num at the end of the IRQ setup. So if an error occurs between their creation and their assignment (for instance during the request_threaded_irq() step), we enter the error path and fail to release the newly created virtual IRQs because they aren't yet assigned to ptpmsg_irq[n].num. Move the mapping creation to ksz_ptp_msg_irq_setup() to ensure symetry with what's released by ksz_ptp_msg_irq_free(). In the error path, move the irq_dispose_mapping to the out_ptp_msg label so it will be called only on created IRQs. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-5-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-25net: dsa: microchip: Free previously initialized ports on init failuresBastien Curutchet (Schneider Electric)1-12/+11
If a port interrupt setup fails after at least one port has already been successfully initialized, the gotos miss some resource releasing: - the already initialized PTP IRQs aren't released - the already initialized port IRQs aren't released if the failure occurs in ksz_pirq_setup(). Merge 'out_girq' and 'out_ptpirq' into a single 'port_release' label. Behind this label, use the reverse loop to release all IRQ resources for all initialized ports. Jump in the middle of the reverse loop if an error occurs in ksz_ptp_irq_setup() to only release the port IRQ of the current iteration. Cc: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-4-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-25net: dsa: microchip: Don't free uninitialized ksz_irqBastien Curutchet (Schneider Electric)1-1/+1
If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-3-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-25net: dsa: microchip: ptp: Fix checks on irq_find_mapping()Bastien Curutchet (Schneider Electric)1-2/+2
irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, during the PTP IRQ setup, we verify that its returned value isn't negative. Fix the irq_find_mapping() check to enter the error path when 0 is returned. Return -EINVAL in such case. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-2-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-25net: dsa: microchip: common: Fix checks on irq_find_mapping()Bastien Curutchet (Schneider Electric)1-4/+4
irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, on each irq_find_mapping() call, we verify that the returned value isn't negative. Fix the irq_find_mapping() checks to enter error paths when 0 is returned. Return -EINVAL in such cases. CC: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-1-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-20net: dsa: microchip: lan937x: Fix RGMII delay tuningOleksij Rempel1-0/+1
Correct RGMII delay application logic in lan937x_set_tune_adj(). The function was missing `data16 &= ~PORT_TUNE_ADJ` before setting the new delay value. This caused the new value to be bitwise-OR'd with the existing PORT_TUNE_ADJ field instead of replacing it. For example, when setting the RGMII 2 TX delay on port 4, the intended TUNE_ADJUST value of 0 (RGMII_2_TX_DELAY_2NS) was incorrectly OR'd with the default 0x1B (from register value 0xDA3), leaving the delay at the wrong setting. This patch adds the missing mask to clear the field, ensuring the correct delay value is written. Physical measurements on the RGMII TX lines confirm the fix, showing the delay changing from ~1ns (before change) to ~2ns. While testing on i.MX 8MP showed this was within the platform's timing tolerance, it did not match the intended hardware-characterized value. Fixes: b19ac41faa3f ("net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20251114090951.4057261-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-14net: dsa: hellcreek: fix missing error handling in LED registrationPavel Zhigulin1-2/+12
The LED setup routine registered both led_sync_good and led_is_gm devices without checking the return values of led_classdev_register(). If either registration failed, the function continued silently, leaving the driver in a partially-initialized state and leaking a registered LED classdev. Add proper error handling Fixes: 7d9ee2e8ff15 ("net: dsa: hellcreek: Add PTP status LEDs") Signed-off-by: Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Kurt Kanzenbach <kurt@linutronix.de> Link: https://patch.msgid.link/20251113135745.92375-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: dsa: microchip: Fix reserved multicast address table programmingTristram Ha4-16/+91
KSZ9477/KSZ9897 and LAN937X families of switches use a reserved multicast address table for some specific forwarding with some multicast addresses, like the one used in STP. The hardware assumes the host port is the last port in KSZ9897 family and port 5 in LAN937X family. Most of the time this assumption is correct but not in other cases like KSZ9477. Originally the function just setups the first entry, but the others still need update, especially for one common multicast address that is used by PTP operation. LAN937x also uses different register bits when accessing the reserved table. Fixes: 457c182af597 ("net: dsa: microchip: generic access to ksz9477 static and reserved table") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Tested-by: Ɓukasz Majewski <lukma@nabladev.com> Link: https://patch.msgid.link/20251105033741.6455-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-03net: dsa: b53: properly bound ARL searches for < 4 ARL bin chipsJonas Gorski1-3/+6
When iterating over the ARL table we stop at max ARL entries / 2, but this is only valid if the chip actually returns 2 results at once. For chips with only one result register we will stop before reaching the end of the table if it is more than half full. Fix this by only dividing the maximum results by two if we have a chip with more than one result register (i.e. those with 4 ARL bins). Fixes: cd169d799bee ("net: dsa: b53: Bound check ARL searches") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251102100758.28352-4-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-03net: dsa: b53: stop reading ARL entries if search is doneJonas Gorski1-1/+1
The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it finished traversing the ARL table. This means that there will be no valid result, so we should not attempt to read and process any further entries. We only ever check the validity of the entries for 4 ARL bin chips, and only after having passed the first entry to the b53_fdb_copy(). This means that we always pass an invalid entry at the end to the b53_fdb_copy(). b53_fdb_copy() does check the validity though before passing on the entry, so it never gets passed on. On < 4 ARL bin chips, we will even continue reading invalid entries until we reach the result limit. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251102100758.28352-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-03net: dsa: b53: fix enabling ip multicastJonas Gorski2-4/+3
In the New Control register bit 1 is either reserved, or has a different function: Out of Range Error Discard When enabled, the ingress port discards any frames if the Length field is between 1500 and 1536 (excluding 1500 and 1536) and with good CRC. The actual bit for enabling IP multicast is bit 0, which was only explicitly enabled for BCM5325 so far. For older switch chips, this bit defaults to 0, so we want to enable it as well, while newer switch chips default to 1, and their documentation says "It is illegal to set this bit to zero." So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit also for other switch chips. While at it, rename it to (B53_)IP_MC as that is how it is called in Broadcom code. Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251102100758.28352-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-03net: dsa: b53: fix bcm63xx RGMII port link adjustmentJonas Gorski1-1/+11
BCM63XX's switch does not support MDIO scanning of external phys, so its MACs needs to be manually configured for autonegotiated link speeds. So b53_force_port_config() and b53_force_link() accordingly also when mode is MLO_AN_PHY for those ports. Fixes lower speeds than 1000/full on rgmii ports 4 - 7. This aligns the behaviour with the old bcm63xx_enetsw driver for those ports. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251101132807.50419-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-03net: dsa: b53: fix resetting speed and pause on forced linkJonas Gorski1-0/+9
There is no guarantee that the port state override registers have their default values, as not all switches support being reset via register or have a reset GPIO. So when forcing port config, we need to make sure to clear all fields, which we currently do not do for the speed and flow control configuration. This can cause flow control stay enabled, or in the case of speed becoming an illegal value, e.g. configured for 1G (0x2), then setting 100M (0x1), results in 0x3 which is invalid. For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on supported chips, as the bit can have different meanings on other chips, e.g. for BCM5389 this controls scanning PHYs for link/speed configuration. Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251101132807.50419-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-5/+16
Cross-merge networking fixes after downstream PR (net-6.17-rc8). Conflicts: drivers/net/can/spi/hi311x.c 6b6968084721 ("can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled") 27ce71e1ce81 ("net: WQ_PERCPU added to alloc_workqueue users") https://lore.kernel.org/72ce7599-1b5b-464a-a5de-228ff9724701@kernel.org net/smc/smc_loopback.c drivers/dibs/dibs_loopback.c a35c04de2565 ("net/smc: fix warning in smc_rx_splice() when calling get_page()") cc21191b584c ("dibs: Move data path to dibs layer") https://lore.kernel.org/74368a5c-48ac-4f8e-a198-40ec1ed3cf5f@kernel.org Adjacent changes: drivers/net/dsa/lantiq/lantiq_gswip.c c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()") 7a1eaef0a791 ("net: dsa: lantiq_gswip: support model-specific mac_select_pcs()") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-25net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries added to the CPU portVladimir Oltean1-1/+2
The blamed commit and others in that patch set started the trend of reusing existing DSA driver API for a new purpose: calling ds->ops->port_fdb_add() on the CPU port. The lantiq_gswip driver was not prepared to handle that, as can be seen from the many errors that Daniel presents in the logs: [ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22 [ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode [ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22 [ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22 [ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2 The errors are because gswip_port_fdb() wants to get a handle to the bridge that originated these FDB events, to associate it with a FID. Absolutely honourable purpose, however this only works for user ports. To get the bridge that generated an FDB entry for the CPU port, one would need to look at the db.bridge.dev argument. But this was introduced in commit c26933639b54 ("net: dsa: request drivers to perform FDB isolation"), first appeared in v5.18, and when the blamed commit was introduced in v5.14, no such API existed. So the core DSA feature was introduced way too soon for lantiq_gswip. Not acting on these host FDB entries and suppressing any errors has no other negative effect, and practically returns us to not supporting the host filtering feature at all - peacefully, this time. Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list") Reported-by: Daniel Golle <daniel@makrotopia.org> Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com Tested-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()Vladimir Oltean1-4/+14
A port added to a "single port bridge" operates as standalone, and this is mutually exclusive to being part of a Linux bridge. In fact, gswip_port_bridge_join() calls gswip_add_single_port_br() with add=false, i.e. removes the port from the "single port bridge" to enable autonomous forwarding. The blamed commit seems to have incorrectly thought that ds->ops->port_enable() is called one time per port, during the setup phase of the switch. However, it is actually called during the ndo_open() implementation of DSA user ports, which is to say that this sequence of events: 1. ip link set swp0 down 2. ip link add br0 type bridge 3. ip link set swp0 master br0 4. ip link set swp0 up would cause swp0 to join back the "single port bridge" which step 3 had just removed it from. The correct DSA hook for one-time actions per port at switch init time is ds->ops->port_setup(). This is what seems to match the coder's intention; also see the comment at the beginning of the file: * At the initialization the driver allocates one bridge table entry for ~~~~~~~~~~~~~~~~~~~~~ * each switch port which is used when the port is used without an * explicit bridge. Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com Tested-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-22net: dsa: microchip: Set SPI as bus interface during reset for KSZ8463Bastien Curutchet1-0/+45
At reset, the KSZ8463 uses a strap-based configuration to set SPI as bus interface. SPI is the only bus supported by the driver. If the required pull-ups/pull-downs are missing (by mistake or by design to save power) the pins may float and the configuration can go wrong preventing any communication with the switch. Introduce a ksz8463_configure_straps_spi() function called during the device reset. It relies on the 'straps-rxd-gpios' OF property and the 'reset' pinmux configuration to enforce SPI as bus interface. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20250918-ksz-strap-pins-v3-3-16662e881728@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-19net: dsa: dsa_loop: remove duplicated definition of NUM_FIXED_PHYSHeiner Kallweit1-2/+0
Remove duplicated definition of NUM_FIXED_PHYS. This was a leftover from 41357bc7b94b ("net: dsa: dsa_loop: remove usage of mdio_board_info"). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/67a3b7df-c967-4431-86b6-a836dc46a4ef@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: move mv88e6xxx_hwtstamp_work() prototypeRussell King (Oracle)2-6/+1
Since mv88e6xxx_hwtstamp_work() is defined in hwtstamp.c, its prototype should be in hwtstamp.h, so move it there. Remove it's redundant stub definition, as both hwtstamp.c (the function provider) and ptp.c (the consumer) are both dependent on the same config symbol. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused 88E6165 register definitionsRussell King (Oracle)1-42/+3
Remove the unused 88E6165 register definitions. For the port registers, add a comment describing that each arrival and departure offset is for a set of four registers that correspond with status, two timestamp registers and the PTP sequence ID captured from the packet. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove duplicated register definitionRussell King (Oracle)2-7/+1
There are two identical MV88E6XXX_PTP_GC_ETYPE definitions in ptp.h, and MV88E6XXX_PTP_ETHERTYPE in hwtstamp.h which all refer to the exact same register. As the code that accesses this register is in hwtstamp.c, use the hwtstamp.h definition, and remove the unnecessary duplicated definition in ptp.h Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused TAI definitionsRussell King (Oracle)1-26/+0
Remove the TAI definitions that the code never uses. Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: rename TAI definitions according to coreRussell King (Oracle)2-37/+34
The TAI_EVENT_STATUS and TAI_CFG definitions are only used for the 88E6352-family of TAI implementations. Rename them as such, and remove the TAI_EVENT_TIME_* definitions that are unused (although we read them as a block.) Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: dsa_loop: remove usage of mdio_board_infoHeiner Kallweit4-62/+60
dsa_loop is the last remaining user of mdio_board_info. Let's remove using mdio_board_info, so that support for it can be dropped from phylib. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/da9563a4-8e14-41cf-bfea-cf5f1b58a4b7@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net: dsa: mv88e6xxx: clean up PTP clock during setup failureRussell King (Oracle)2-8/+8
If an error occurs during mv88e6xxx_setup() and the PTP clock has been registered, the clock will not be unregistered as mv88e6xxx_ptp_free() will not be called. mv88e6xxx_hwtstamp_free() also is not called. As mv88e6xxx_ptp_free() can cope with being called without a successful call to mv88e6xxx_ptp_setup(), and mv88e6xxx_hwtstamp_free() is empty, add both these *_free() calls to the error cleanup paths in mv88e6xxx_setup(). Moreover, mv88e6xxx_teardown() should teardown setup done in mv88e6xxx_setup() - see dsa_switch_setup(). However, instead *_free() are called from mv88e6xxx_remove() function that is only called when a device is unbound, which omits cleanup should a failure occur later in dsa_switch_setup(). Move the *_free() calls from mv88e6xxx_remove() to mv88e6xxx_teardown(). Note that mv88e6xxx_ptp_setup() must be called holding the reg_lock, but mv88e6xxx_ptp_free() must never be. This is especially true after commit "ptp: rework ptp_clock_unregister() to disable events". This patch does not change this, but adds a comment to that effect. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/E1uy84w-00000005Spi-46iF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove unused support for PPS event captureRussell King (Oracle)2-19/+3
mv88e6352_config_eventcap() is documented as handling both EXTTS and PPS capture modes, but nothing ever calls it for PPS capture. Remove the unused PPS capture mode support, and the now unused MV88E6XXX_TAI_EVENT_STATUS_CAP_TRIG definition. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uwep9-00000004ikJ-2FeF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove chip->evcap_configRussell King (Oracle)2-7/+5
evcap_config is only read and written in mv88e6352_config_eventcap(), so it makes little sense to store it in the global chip struct. Make it a local variable instead. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uwep4-00000004ikD-1ZEh@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove chip->trig_configRussell King (Oracle)2-2/+1
chip->trig_config is never written, and thus takes the value zero. Remove this struct member and its single reader. Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uweoz-00000004ik7-13Fl@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove mv88e6250_ptp_opsRussell King (Oracle)3-26/+1
mv88e6250_ptp_ops and mv88e6352_ptp_ops are identical since commit 7e3c18097a70 ("net: dsa: mv88e6xxx: read cycle counter period from hardware"). Remove the unnecessary duplication. Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uweou-00000004ik1-0aiX@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-4/+13
Cross-merge networking fixes after downstream PR (net-6.17-rc6). Conflicts: net/netfilter/nft_set_pipapo.c net/netfilter/nft_set_pipapo_avx2.c c4eaca2e1052 ("netfilter: nft_set_pipapo: don't check genbit from packetpath lookups") 84c1da7b38d9 ("netfilter: nft_set_pipapo: use avx2 algorithm for insertions too") Only trivial adjacent changes (in a doc and a Makefile). Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-08net: dsa: b53: fix ageing time for BCM53101Jonas Gorski1-4/+13
For some reason Broadcom decided that BCM53101 uses 0.5s increments for the ageing time register, but kept the field width the same [1]. Due to this, the actual ageing time was always half of what was configured. Fix this by adapting the limits and value calculation for BCM53101. So far it looks like this is the only chip with the increased tick speed: $ grep -l -r "Specifies the aging time in 0.5 seconds" cdk/PKG/chip | sort cdk/PKG/chip/bcm53101/bcm53101_a0_defs.h $ grep -l -r "Specifies the aging time in seconds" cdk/PKG/chip | sort cdk/PKG/chip/bcm53010/bcm53010_a0_defs.h cdk/PKG/chip/bcm53020/bcm53020_a0_defs.h cdk/PKG/chip/bcm53084/bcm53084_a0_defs.h cdk/PKG/chip/bcm53115/bcm53115_a0_defs.h cdk/PKG/chip/bcm53118/bcm53118_a0_defs.h cdk/PKG/chip/bcm53125/bcm53125_a0_defs.h cdk/PKG/chip/bcm53128/bcm53128_a0_defs.h cdk/PKG/chip/bcm53134/bcm53134_a0_defs.h cdk/PKG/chip/bcm53242/bcm53242_a0_defs.h cdk/PKG/chip/bcm53262/bcm53262_a0_defs.h cdk/PKG/chip/bcm53280/bcm53280_a0_defs.h cdk/PKG/chip/bcm53280/bcm53280_b0_defs.h cdk/PKG/chip/bcm53600/bcm53600_a0_defs.h cdk/PKG/chip/bcm89500/bcm89500_a0_defs.h [1] https://github.com/Broadcom/OpenMDK/blob/a5d3fc9b12af3eeb68f2ca0ce7ec4056cd14d6c2/cdk/PKG/chip/bcm53101/bcm53101_a0_defs.h#L28966 Fixes: e39d14a760c0 ("net: dsa: b53: implement setting ageing time") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250905124507.59186-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-05net: dsa: felix: support phy-mode = "10g-qxgmii"Vladimir Oltean3-2/+8
The "usxgmii" phy-mode that the Felix switch ports support on LS1028A is not quite USXGMII, it is defined by the USXGMII multiport specification document as 10G-QXGMII. It uses the same signaling as USXGMII, but it multiplexes 4 ports over the link, resulting in a maximum speed of 2.5G per port. This change is needed in preparation for the lynx-10g SerDes driver on LS1028A, which will make a more clear distinction between usxgmii (supported on lane 0) and 10g-qxgmii (supported on lane 1). These protocols have their configuration in different PCCR registers (PCCRB vs PCCR9). Continue parsing and supporting single-port-per-lane USXGMII when found in the device tree as usual (because it works), but add support for 10G-QXGMII too. Using phy-mode = "10g-qxgmii" will be required when modifying the device trees to specify a "phys" phandle to the SerDes lane. The result when the "phys" phandle is present but the phy-mode is wrong is undefined. The only PHY driver in known use with this phy-mode, AQR412C, will gain logic to transition from "usxgmii" to "10g-qxgmii" in a future change. Prepare the driver by also setting PHY_INTERFACE_MODE_10G_QXGMII in supported_interfaces when PHY_INTERFACE_MODE_USXGMII is there, to prevent breakage with existing device trees. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250903130730.2836022-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-4/+13
Cross-merge networking fixes after downstream PR (net-6.17-rc5). No conflicts. Adjacent changes: include/net/sock.h c51613fa276f ("net: add sk->sk_drop_counters") 5d6b58c932ec ("net: lockless sock_i_ino()") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-04net: dsa: dsa_loop: use int type to store negative error codesQianfeng Rong1-1/+2
Change the 'ret' variable in dsa_loop_init() from unsigned int to int, as it needs to store either negative error codes or zero returned by mdio_driver_register(). Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but can be confusing. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20250903123404.395946-1-rongqianfeng@vivo.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: move MDIO bus registration to .setup()Daniel Golle1-7/+7
Instead of registering the switch MDIO bus in the probe() function, move the call to gswip_mdio() into the .setup() DSA switch op, so it can be reused independently of the probe() function. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/2650602042c0bfdc5664b88d59071ed4dca96c26.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: support standard MDIO node nameDaniel Golle1-0/+3
Instead of matching against the child node's compatible string also support locating the node of the device tree node of the MDIO bus in the standard way by referencing the node name ("mdio"). Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/5a9a3d659ef0d8b7eca37fb69ec87ff5a3192820.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: support offset of MII registersDaniel Golle2-2/+13
The MaxLinear GSW1xx family got a single (R)(G)MII port at index 5 but the registers MII_PCDU and MII_CFG are those of port 0. Allow applying an offset for the port index to access those registers. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/88145164c1f948e4ae9b04706f408359cf54223c.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: ignore SerDes modes in phylink_mac_config()Daniel Golle1-0/+4
We can safely ignore SerDes interface modes 1000Base-X, 2500Base-X and SGMII in phylink_mac_config() as they are being taken care of by the PCS and the SGMII port anyway doesn't have MII_CFG and MII_PCDU registers and hence gswip_phylink_mac_config() is already a no-op apart from outputing a misleading error message. Return early in case of SerDes interface modes to avoid printing that error message. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/dcb066d6a02e6340314b5ff4f73937757a4f8eb3.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: support model-specific mac_select_pcs()Daniel Golle2-3/+19
Call mac_select_pcs() function if provided in struct gswip_hwinfo. The MaxLinear GSW1xx series got one port wired to a SerDes PCS and PHY which can do 1000Base-X, 2500Base-X and SGMII. Support for the SerDes port will be provided using phylink_pcs, so provide a convenient way for mac_select_pcs() to differ based on the hardware model. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/7668666aa51e43e7f2a6cbcf36eb5a0a3020998f.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: lantiq_gswip: move to dedicated folderDaniel Golle7-8/+10
Move the lantiq_gswip driver to its own folder and update MAINTAINERS file accordingly. This is done ahead of extending the driver to support the MaxLinear GSW1xx series of standalone switch ICs, which includes adding a bunch of files. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/a5923dee9a174501b284dc473bdec9dd89c68de1.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-02net: dsa: mv88e6xxx: Fix fwnode reference leaks in mv88e6xxx_port_setup_ledsMiaoqian Lin1-4/+13
Fix multiple fwnode reference leaks: 1. The function calls fwnode_get_named_child_node() to get the "leds" node, but never calls fwnode_handle_put(leds) to release this reference. 2. Within the fwnode_for_each_child_node() loop, the early return paths that don't properly release the "led" fwnode reference. This fix follows the same pattern as commit d029edefed39 ("net dsa: qca8k: fix usages of device_get_named_child_node()") Fixes: 94a2a84f5e9e ("net: dsa: mv88e6xxx: Support LED control") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250901073224.2273103-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-26net: phy: fixed_phy: let fixed_phy_unregister free the phy_deviceHeiner Kallweit1-6/+3
fixed_phy_register() creates and registers the phy_device. To be symmetric, we should not only unregister, but also free the phy_device in fixed_phy_unregister(). This allows to simplify code in users. Note wrt of_phy_deregister_fixed_link(): put_device(&phydev->mdio.dev) and phy_device_free(phydev) are identical. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/ad8dda9a-10ed-4060-916b-3f13bdbb899d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: store switch API version in privDaniel Golle2-4/+22
Store the switch API version in struct gswip_priv. As the hardware has the 'major/minor' version bytes in the wrong order preventing numerical comparisons the version to be stored in gswip_priv is constructed in such a way that the REV field is the most significant byte and the MOD field the least significant byte. Also provide a conveniance macro to allow comparing the stored version of the hardware against the already defined GSWIP_VERSION_* macros. This is done in order to prepare supporting newer features such as 4096 VLANs and per-port configurable learning which are only available starting from specific hardware versions. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/eddb51ae8d0b2046ca91906e93daad7be5af56d7.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: make DSA tag protocol model-specificDaniel Golle2-1/+6
While the older Lantiq / Intel which are currently supported all use the DSA_TAG_GSWIP tagging protocol, newer MaxLinear GSW1xx modules use another 8-byte tagging protocol. Move the tag protocol information to struct gswip_hw_info to make it possible for new models to specify a different tagging protocol. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/841281b62fdb472048fa98fbad6c88dfbf512825.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: load model-specific microcodeDaniel Golle3-12/+20
Load microcode as specified in struct hw_info instead of relying on a single array of instructions. This is done in preparation to allow loading different microcode for the MaxLinear GSW1xx family. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/486d95c085913d506745fbe4a0ab5d1ebdc3ed63.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: introduce bitmap for MII portsDaniel Golle2-3/+12
Instead of relying on hard-coded numbers for MII ports, introduce a bitmap for MII ports. This is done in order to prepare for supporting MaxLinear GSW1xx ICs which got a different layout of ports. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/019fc8ed06f2317976eac143320d1dc046e8f392.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: move definitions to headerDaniel Golle2-247/+255
Introduce header file and move register definitions as well as the definitions struct gswip_hw_info and struct gswip_priv there. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/551c72c93131cd200b38340741e68ff21793ba0b.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: prepare for more CPU port optionsDaniel Golle1-29/+50
The MaxLinear GSW1xx series of switches support using either the (R)(G)MII interface on port 5 or the SGMII interface on port 4 to be used as CPU port. Prepare for supporting them by defining a mask of allowed CPU ports instead of a single port. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/879c66672d26fe49c1f5d9aa40d8ebc0f31885ab.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-25net: dsa: lantiq_gswip: deduplicate dsa_switch_opsDaniel Golle1-29/+15
The two instances of struct dsa_switch_ops differ only by their .phylink_get_caps op. Instead of having two instances of dsa_switch_ops, rather just have a pointer to the phylink_get_caps function in struct gswip_hw_info. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/03d72eceeb3faecdbe03ce58aab40861cf6b77c1.1755878232.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>