Re: [net PATCH 1/2] net: phy: Cleanup handling of recent changes to phy_lookup_setting

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Apr 03, 2025 at 02:53:22PM -0700, Alexander Duyck wrote:
> On Thu, Apr 3, 2025 at 9:34 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > Maybe go back to why fixed-link exists? It is basically a hack to make
> > MAC configuration easier. It was originally used for MAC to MAC
> > connections, e.g. a NIC connected to a switch, without PHYs in the
> > middle. By faking a PHY, there was no need to add any special
> > configuration API to the MAC, the phylib adjust_link callback would be
> > sufficient to tell the MAC to speed and duplex to use. For {R}{G}MII,
> > or SGMII, that is all you need to know. The phy-mode told you to
> > configure the MAC to MII, GMII, SGMII.
> 
> Another issue is that how you would define the connection between the
> two endpoints is changing. Maxime is basing his data off of
> speed/duplex however to source that he is pulling data from
> link_mode_params that is starting to broaden including things like
> lanes.

Just a quick correction - this is not entirely correct. It's speed,
duplex and "lanes" is defined by interface mode.

For example, 10GBASER is a single lane, as is SGMII, 1000BASE-X,
2500BASE-X. XLGMII and CGMII are defined by 802.3 as 8 lanes (clause
81.)

speed and duplex just define the speed operated over the link defined
by the PHY interface mode.

(I've previously described why we don't go to that depth with fixed
links, but to briefly state it, it's what we've done in the past and
it's visible to the user, and we try to avoid breaking userspace.)

> I really think going forward lanes is going to start playing a
> role as we get into the higher speeds and it is already becoming a
> standard config item to use to strip out unsupported modes when
> configuring the interface via autoneg.

Don't vendors already implement downshift for cases where there are
problems with lanes/cabling?

> I am wondering about that. I know I specified we were XLGMII for fbnic
> but that has proven problematic since we aren't actually 40G.

If you aren't actually 40G, then you aren't actually XLGMII as
defined by 802.3... so that begs the question - what are you!

> So we
> are still essentially just reporting link up/down using that. That is
> why I was looking at going with a fixed mode as I can at least specify
> the correct speed duplex for the one speed I am using if I want to use
> ethtool_ksettings_get.
> 
> I have a patch to add the correct phy_interface_t modes for 50, and
> 100G links. However one thing I am seeing is that after I set the
> initial interface type I cannot change the interface type without the
> SFP code added. One thing I was wondering. Should I just ignore the
> phy_interface_t on the pcs_config call and use the link mode mask
> flags in autoneg and the speed/duplex/lanes in non-autoneg to
> configure the link? It seems like that is what the SFP code itself is
> doing based on my patch 2 in the set.

That is most certainly *not* what the SFP code is doing. As things stand
today, everything respects the PHY interface mode, if it says SGMII then
we get SGMII. If it says 1000BASE-X, we get 1000BASE-X. If it says
2500BASE-X, then that's what we get... and so on.

The SFP code has added support to switch between 2500BASE-X and
1000BASE-X because this is a use case with optical SFPs that can operate
at either speed. That's why this happens for the SFP case.

For PHYs, modern PHYs switch their host facing interface, so we support
the interface mode changing there - under the control of the PHY and
most certainly not under user control (the user doesn't know how the
PHY has been configured and whether the PHY does switch or rate
adapt.)

For everything else, we're in fixed host interface mode, because that
is how we've been - and to do anything else is new development.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!