kernel/git/next/linux-next.git/drivers/net/dsa/microchip, branch master

net: dsa: microchip: enable the SGMII port of the KSZ9897S

2026-09-10T01:41:06+00:00

The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info entry never set .sgmii_port. ksz_has_sgmii_port() is therefore false, ksz9477_pcs_create() is never called and ksz9477_phylink_mac_select_pcs() returns NULL for port 7, so a phy-mode = "sgmii" or "1000base-x" link on that port cannot come up. Only the KSZ9897S has that port; the KSZ9897R has a second RGMII port instead. Both report chip ID 0x00989700, so the port cannot be enabled from the chip ID alone, and enabling it unconditionally breaks the KSZ9897R badly: ksz9477_setup() propagates the failure of xpcs_create_pcs_mdiodev() on a part without an XPCS, so the switch as a whole stops probing. The variants do differ in the read-only bit 7 of the port 7 XMII control 0 register, which reads one on the KSZ9897S and zero on the KSZ9897R. Compare the KSZ9897S data sheet DS00002394C section 5.2.4.1 with the KSZ9897R data sheet DS00002330D section 5.2.3.1. Read that bit in ksz_switch_register() and use it to select a KSZ9897S chip_data entry, which is the KSZ9897 one plus .sgmii_port = 7, with port 7 no longer marked as supporting MII, RMII and RGMII. On the KSZ9897S that port is permanently an SGMII port and only its differential pairs are brought out, so advertising the xMII modes on it would let phylink accept a mode the driver never programs: ksz_phylink_need_config() skips the XMII control registers for the SGMII port. The KSZ9477, which also has SGMII on port 7, is described the same way. See DS00002394C section 4.11. KSZ9897S_CHIP_ID selects that chip_data entry and nothing else. dev->chip_id keeps the KSZ9897 chip ID that both parts report, so no other chip ID comparison has to know about the variant, ksz_check_device_id() is unchanged, and a device tree naming the KSZ9897 keeps matching whichever part is fitted. No binding change is needed and existing device trees keep working. Tested on a KSZ9897S with a 1000BASE-LX fibre SFP on port 7: bit 7 of the port 7 XMII control 0 register reads one, the switch is identified as a KSZ9897S and the PCS is created. The port advertises 1000baseX/Full, clause 37 in-band autonegotiation completes against the link partner, and the link comes up at 1Gbps/full duplex and passes traffic. Suggested-by: Nicolai Buchwitz Suggested-by: Jerry Ray Suggested-by: Tristram Ha Signed-off-by: Tapio Reijonen Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260904-ksz9897-sgmii-port-v5-1-9bd4a0381aa8@vaisala.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: add two-steps PTP support for KSZ8463

2026-07-31T23:29:56+00:00

The KSZ8463 switch supports PTP but it's not supported by the driver. Add L2 two-step PTP support for the KSZ8463. IPv4 and IPv6 layers aren't supported. Neither is one-step PTP. Use KSZ8463-specific implementations of the .get_ts_info and .port_hwtstamp_set callbacks. The pdelay_req and pdelay_resp timestamps share one interrupt bit status while they're located in two different registers. So introduce last_tx_is_pdelayresp to keep track of the last sent event type. This flag is set by the xmit worker right before sending the packet and then used in the interrupt handler to retrieve the timestamp location. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-10-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: explicitly enable detection of L2 PTP frames

2026-07-31T23:29:56+00:00

Detection of L2 PTP frames needs to be enabled for PTP to work at the L2 layer. The bit enabling this detection is set by default on the switches currently supported by the driver, but it is unset by default on the KSZ8463 for which support will be added in upcoming patches. Explicitly enable the detection of L2 PTP frames for all switches when PTP is enabled. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-9-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: add KSZ8463 tail tag handling

2026-07-31T23:29:56+00:00

KSZ8463 uses the KSZ9893 DSA TAG driver. However, the KSZ8463 doesn't use the tail tag to convey timestamps to the host as KSZ9893 does. It uses the reserved fields in the PTP header instead. Add a KSZ8463-specific DSA_TAG driver to handle KSZ8463 timestamps. There is no information in the tail tag to distinguish PTP packets from others so use the ptp_classify_raw() helper to find the PTP packets and extract the timestamp from their PTP headers. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-8-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: adapt port offset for KSZ8463's PTP register

2026-07-31T23:29:55+00:00

In KSZ8463 register's layout, the offset between port 1 and port 2 registers isn't the same in the generic control register area than in the PTP register area. The get_port_addr() always uses the same offset so it doesn't work when it's used to access PTP registers. Adapt the port offset in get_port_addr() when the accessed register is in the PTP area. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-5-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: add PTP interrupt handling for KSZ8463

2026-07-31T23:29:55+00:00

KSZ8463 PTP interrupts aren't handled by the driver. The interrupt layout in KSZ8463 has nothing to do with the other switches: - Its global interrupt enable register is 16-bits long and follow an 'enable' logic, instead of a 'mask' one - all the interrupts of all ports are grouped into one status register while others have one interrupt register per port - xdelay_req and pdresp timestamps share one single interrupt bit on the KSZ8463 while each of them has its own interrupt bit on other switches Create a KSZ8463-specific set of interrupt domain operations to handle the global IRQ layer. To limit code duplication, it uses the same interrupt handler than the other switches. Since other switches have 8-bits registers, only the high-byte of the interrupt status/enable registers are used. This high-byte is where the PTP interrupts are located. The low-byte contains the wake-up detection interrupts so if at some points these interrupts are needed we'll need a bit of rework here. Create KSZ8463-specific functions to setup the PTP interrupts. The created IRQ domain is tied to the first port of the KSZ8463. Again, the same PTP interrupt handler than the others switches is used. Implement the teardown callback to release the interrupts. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-4-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: allow the use of other IRQ operations.

2026-07-31T23:29:55+00:00

The IRQ setup uses an hardcoded set of IRQ operations. These operations don't fit with the KSZ8463 which has an inverted bit logic (it uses an 'enable irq' register instead of a 'mask irq' one) and 16-bits registers. Take the IRQ domain operations as input of ksz_irq_common_setup() to allow KSZ8463 to use the already existing setup with its own set of IRQ operations. Expose ksz_irq_common_setup() and ksz_irq_bus_lock/unlock() so they can be used by ksz8.c. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-3-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: split ksz8_config_cpu_port()

2026-07-31T23:29:55+00:00

ksz8_config_cpu_port() is only called twice, once by ksz8_setup() and once by ksz8463_setup(). It contains a ksz8463 branch that could be avoided in the ksz8_setup() case and a ksz87xx/ksz88xx branches that could be avoided in ksz8463_setup() case. Create ksz8463_config_cpu_port() that only handles the ksz8463 case and remove the ksz8463 specificities from the common ksz8_config_cpu_port(). Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-2-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: implement ksz8463_setup()

2026-07-31T23:29:55+00:00

KSZ8463 uses the ksz8_setup() as setup() callback for its DSA operations. Its behavior is quite different than other KSZ8 switches, especially its interrupt scheme. Remove from the ksz8_setup()/ksz8_reset_switch() everything that is ksz8463-related. Create a dedicated ksz8463_setup() and a ksz8463_reset_switch() function. This new ksz8463_setup() is widely inspired from ksz8_setup, it has following differences: - it doesn't configure drive strength (not supported on KSZ8463) - it uses the ksz8463_reset_switch() - it doesn't call ksz8_handle_global_errata() (the handled errata only affects the KSZ87xx variant) - it doesn't configure IRQs. Note that ksz8_setup()'s IRQ initialization doesn't work for the KSZ8463 anyway. Proper support for it comes in upcoming patches. Remove the teardown implementation from the KSZ8463 operations. Since PTP and interrupts aren't setup, the common ksz_teardown() wouldn't do anything anyway. Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-1-caba39e680e3@bootlin.com Signed-off-by: Jakub Kicinski

net: dsa: microchip: Fix log typo in error path

2026-07-23T18:01:05+00:00

All other log messages in the driver prefix hex values with 0x, add it in the one missing message. While at it also add the missing opening parenthesis in the same log message. Signed-off-by: Niklas Söderlund Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260722174853.2316333-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski