kernel/linux.git/drivers/net/pcs, branch v6.19.11

net: pcs: pcs-mtk-lynxi: report in-band capability for 2500Base-X

2026-01-22T04:01:03+00:00

It turns out that 2500Base-X actually works fine with in-band status on MediaTek's LynxI PCS -- I wrongly concluded it didn't because it is broken in all the copper SFP modules and GPON sticks I used for testing. Hence report LINK_INBAND_ENABLE also for 2500Base-X mode. This reverts most of commit a003c38d9bbb ("net: pcs: pcs-mtk-lynxi: correctly report in-band status capabilities"). The removal of the QSGMII interface mode was correct and is left untouched. Link: https://github.com/openwrt/openwrt/issues/21436 Fixes: a003c38d9bbb ("net: pcs: pcs-mtk-lynxi: correctly report in-band status capabilities") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/b1cf26157b63fee838be09ae810497fb22fd8104.1768961746.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

net: pcs: lynx: accept in-band autoneg for 2500base-x

2025-12-01T21:50:15+00:00

Testing in two circumstances: 1. back to back optical SFP+ connection between two LS1028A-QDS ports with the SCH-26908 riser card 2. T1042 with on-board AQR115 PHY using "OCSGMII", as per https://lore.kernel.org/lkml/aIuEvaSCIQdJWcZx@FUE-ALEWI-WINX/ strongly suggests that enabling in-band auto-negotiation is actually possible when the lane baud rate is 3.125 Gbps. It was previously thought that this would not be the case, because it was only tested on 2500base-x links with on-board Aquantia PHYs, where it was noticed that MII_LPA is always reported as zero, and it was thought that this is because of the PCS. Test case #1 above shows it is not, and the configured MII_ADVERTISE on system A ends up in the MII_LPA on system B, when in 2500base-x mode (IF_MODE=0). Test case #2, which uses "SGMII" auto-negotiation (IF_MODE=3) for the 3.125 Gbps lane, is actually a misconfiguration, but it is what led to the discovery. There is actually an old bug in the Lynx PCS driver - it expects all register values to contain their default out-of-reset values, as if the PCS were initialized by the Reset Configuration Word (RCW) settings. There are 2 cases in which this is problematic: - if the bootloader (or previous kexec-enabled Linux) wrote a different IF_MODE value - if dynamically changing the SerDes protocol from 1000base-x to 2500base-x, e.g. by replacing the optical SFP module. Specifically in test case #2, an accidental alignment between the bootloader configuring the PCS to expect SGMII in-band code words, and the AQR115 PHY actually transmitting SGMII in-band code words when operating in the "OCSGMII" system interface protocol, led to the PCS transmitting replicated symbols at 3.125 Gbps baud rate. This could only have happened if the PCS saw and reacted to the SGMII code words in the first place. Since test #2 is invalid from a protocol perspective (there seems to be no standard way of negotiating the data rate of 2500 Mbps with SGMII, and the lower data rates should remain 10/100/1000), in-band auto-negotiation for 2500base-x effectively means Clause 37 (i.e. IF_MODE=0). Make 2500base-x be treated like 1000base-x in this regard, by removing all prior limitations and calling lynx_pcs_config_giga(). This adds a new feature: LINK_INBAND_ENABLE and at the same time fixes the Lynx PCS's long standing problem that the registers (specifically IF_MODE, but others could be misconfigured as well) are not written by the driver to the known valid values for 2500base-x. Co-developed-by: Alexander Wilhelm Signed-off-by: Alexander Wilhelm Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20251125103507.749654-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: pcs: xpcs: Add support for FBNIC 25G, 50G, 100G PMD

2025-11-27T09:41:31+00:00

The fbnic driver is planning to make use of the XPCS driver to enable support for PCS and better integration with phylink. To do this though we will need to enable several workarounds since the PMD interface for fbnic is likely to be unique since it is a mix of two different vendor products with a unique wrapper around the IP. I have generated a PHY identifier based on IEEE 802.3-2022 22.2.4.3.1 using an OUI belonging to Meta Platforms and used with our NICs. Using this we will provide it as the PMD ID via the SW based MDIO interface so that the fbnic device can be identified and necessary workarounds enabled in the XPCS driver. As an initial workaround this change adds an exception so that soft_reset is not set when the driver is initially bound to the PCS. In addition I have added logic to integrate the PMD Rx signal detect state into the link state for the PCS. With this we can avoid the link coming up too soon on the FBNIC PMD and as a result of it being in the training state so we can avoid link flaps. Signed-off-by: Alexander Duyck Link: https://patch.msgid.link/176374321695.959489.6648161125012056619.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni

net: pcs: xpcs: Fix PMA identifier handling in XPCS

2025-11-27T09:41:31+00:00

The XPCS driver was mangling the PMA identifier as the original code appears to have been focused on just capturing the OUI. Rather than store a mangled ID it is better to work with the actual PMA ID and instead just mask out the values that don't apply rather than shifting them and reordering them as you still don't get the original OUI for the NIC without having to bitswap the values as per the definition of the layout in IEEE 802.3-2022 22.2.4.3.1. By laying it out as it was in the hardware it is also less likely for us to have an unintentional collision as the enum values will occupy the revision number area while the OUI occupies the upper 22 bits. Signed-off-by: Alexander Duyck Link: https://patch.msgid.link/176374320920.959489.17267159479370601070.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni

net: pcs: xpcs: Add support for 25G, 50G, and 100G interfaces

2025-11-27T09:41:30+00:00

With this change we are adding support for 25G, 50G, and 100G interface types to the XPCS driver. This had supposedly been enabled with the addition of XLGMII but I don't see any capability for configuration there so I suspect it may need to be refactored in the future. With this change we can enable the XPCS driver with the selected interface and it should be able to detect link, speed, and report the link status to the phylink interface. Signed-off-by: Alexander Duyck Link: https://patch.msgid.link/176374320248.959489.11649590675011158859.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni

net: mdio: remove redundant fwnode cleanup

2025-11-26T02:45:37+00:00

Remove redundant fwnode cleanup in of_mdiobus_register_device() and xpcs_plat_init_dev(). mdio_device_free() eventually calls mdio_device_release(), which already performs fwnode_handle_put(), making the manual cleanup unnecessary. Combine fwnode_handle_get() with device_set_node() in of_mdiobus_register_device() for clarity. Signed-off-by: Buday Csaba Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/00847693daa8f7c8ff5dfa19dd35fc712fa4e2b5.1763995734.git.buday.csaba@prolan.hu Signed-off-by: Jakub Kicinski

net: pcs: xpcs-plat: fix MODULE_AUTHOR

2025-11-14T01:41:06+00:00

This field needs to hold just Serge's name. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20251112211118.700875-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: pcs: Kconfig: Fix unmet dependency warning

2025-09-17T21:57:52+00:00

Fix the Kconfig dependencies for PCS_RZN1_MIIC to avoid the unmet direct dependency warning when enabling DWMAC_RENESAS_GBETH. The PCS driver is used on multiple Renesas SoCs including RZ/N1, RZ/N2H and RZ/T2H, but the existing condition only allowed ARCH_RZN1, ARCH_R9A09G077, or ARCH_R9A09G087. This conflicted with the GBETH/GMAC driver which selects PCS_RZN1_MIIC under ARCH_RENESAS. Update the dependency to ARCH_RENESAS || COMPILE_TEST so that the PCS driver is available on all Renesas platforms. Fixes: 08f89e42121d ("net: pcs: rzn1-miic: Add RZ/T2H MIIC support") Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/aMlgg_QpJOEDGcEA@monster/ Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250916162335.3339558-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski

net: pcs: rzn1-miic: Add RZ/T2H MIIC support

2025-09-16T00:44:36+00:00

Add support for the Renesas RZ/T2H MIIC by defining SoC-specific modctrl match tables, register map, and string representations for converters and ports. Signed-off-by: Lad Prabhakar Tested-by: Wolfram Sang Link: https://patch.msgid.link/20250910204132.319975-10-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski

net: pcs: rzn1-miic: Add per-SoC control for MIIC register unlock/lock

2025-09-16T00:44:36+00:00

Make MIIC accessory register unlock/lock behaviour selectable via SoC/OF data. Add init_unlock_lock_regs and miic_write to struct miic_of_data so the driver can either perform the traditional global unlock sequence (as used on RZ/N1) or use a different policy for other SoCs (for example RZ/T2H, which does not require leaving registers unlocked). miic_reg_writel() now calls the per-SoC miic_write callback to perform register writes. Provide miic_reg_writel_unlocked() as the default writer and set it for the RZ/N1 OF data so existing platforms keep the same behaviour. Add a miic_unlock_regs() helper that implements the accessory register unlock sequence so the unlock/lock sequence can be reused where needed (for example when a SoC requires explicit unlock/lock around individual accesses). This change is preparatory work for supporting RZ/T2H. Signed-off-by: Lad Prabhakar Tested-by: Wolfram Sang Link: https://patch.msgid.link/20250910204132.319975-9-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski