Thread (2 messages) flat view 2 messages, 2 authors, 2025-08-23

Re: [PATCH RFC net-next] net: phy: marvell: 88e1111: define gigabit features

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2025-08-23 14:24:20
Also in: lkml

On Sat, Aug 23, 2025 at 04:03:12PM +0200, Josua Mayer wrote:
When connecting RJ45 SFP modules to Linux an ethernet phy is expected -
and probed on the i2c bus when possible. Once the PHY probed, phylink
populates the supported link modes for the netdev based on bmsr
register bits set at the time (see phy_device.c: phy_probe).
No, phy*lib* does this.
Marvell phy driver probe function only allocates memory, leaving actual
configuration for config_init callback.
This means the supported link modes of the netdev depend entirely on the
power-on status of the phy bmsr register.

Certain Cisco SFP modules such as GLC-T and GLC-TE have invalid
configuration at power-on: MII_M1111_HWCFG_MODE_COPPER_1000X_AN
This means fiber with automatic negotiation to copper. As the module
exhibits a physical RJ45 connector this configuration is wrong.
As a consequence after power-on the bmsr does not set bits for 10/100
modes.

During config_init marvell phy driver identifies the correct intended
MII_M1111_HWCFG_MODE_SGMII_NO_CLK which means sgmii with automatic
negotiation to copper, and configures the phy accordingly.

At this point the bmsr register correctly indicates support for 10/100
link modes - however the netedev supported modes bitmask is never
updated.

Hence the netdev fails to negotiate or link-up at 10/100
speeds, limiting to 1000 links only.

Explicitly define features for 88e1111 phy to ensure that all supported
modes are available at runtime even when phy power-on configuration was
invalid.
So we have a PHY which changes what it's capable of depending on its
configuration, which gives us a chicken-and-egg problem when it comes
to working out whether a PHY (on a SFP module) can be used with a
MAC, because it's not clear from reading its abilities what it might
actually be capable of.

So yes, I think this is the right approach for the common case - but
if we really do have a PHY that's using 1000base-X -to- Copper mode,
this change will be wrong.

Reviewed-by: Russell King (Oracle) <redacted>

Thanks!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help