Re: [PATCH net-next 3/3] net: phylink: add phylink_sfp_select_interface_speed()

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

On Thu, Jul 10, 2025 at 10:22:44AM -0700, Alexander Duyck wrote:
> On Thu, Jul 10, 2025 at 9:11 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > What is wrong, that it is reporting LP information, or that it is
> > reporting it does not support autoneg when in fact it is actually
> > doing autoneg?
> 
> I have some debug code on here that is reporting the FW config as the
> "LP Advertised". I had borrowed that approach from the phylink
> fixedlink config as I thought it was a good way for me to know what
> the FW was requesting without having to report it out to a log file.

There are a few points to be made here.

1. Fixed link configuration is not the same as !autoneg setting with
   the presence of a PHY. !autoneg with a PHY present means that the
   PHY has been instructed not to perform autonegotiation, but to set
   the specified parameters for the link and only allow the link to
   operate at the specified speed/duplex. There are exceptions - as
   users expect 1G to work with "autoneg" disabled, and 1G requires
   AN in order to bring the link up. Some PHYs support disabling the
   autoneg function at 1G speed by internally ignoring the request
   to disable autoneg, and instead only advertising to the link
   partner that 1G at the specified duplex is supported. We took
   that and turned it into a software thing for all PHYs as some
   PHYs decided to go a different route - basically not supporting
   the AN enable bit being turned off at 1G speeds.

2. Fixed link configuration is a software concept where there is no
   accessible PHY present. Phylink rejects fixed link configuration
   with a PHY. There is no support to configure a PHY into fixed
   speed/duplex if present, and has never been supported prior to
   phylink.

3. The history. Prior to phylink (and it remains in some cases today),
   fixed link configuration was created by providing a software
   emulated PHY to phylib for the MAC driver to use, thus avoiding
   MAC drivers having to add explicit code for fixed links. They
   looked just like a normal PHY, but was limited to no faster than
   1G speeds as the software emulation is a Clause 22 PHY.

   This software emulated PHY replaces the presence of a physical
   PHY (there is none) and the PHY it emulates looks like a PHY that
   supports AN, has AN enabled, but only supports a single speed
   and duplex, only advertises a single baseT(x) speed and duplex,
   and the link partner agrees on the speed and duplex. This "fools
   phylib into resolving the speed and duplex as per the fixed link
   configuration.

   However, in reality, there is no AN.

   This has become part of the user API, because the MII registers of
   the fixed link PHY were exported to userspace, and of course through
   ethtool.

   There has never been a MII API for reading the fixed link parameters
   for speeds > 1G, so while phylink enables fixed link configuration
   for those speeds, there is no MII register support for this for
   userspace.

(As an aside)
Someone earlier today sent a reminder about a bug I'd introduced for
10GBASE-R, 5GBASE-R and another interface (I don't recall right now)
and I proposed a patch that only cleared the Autoneg bit in the
adertising mask. Having been reminded about it, and had Andrew's
input on this thread, I'm wondering whether config.advertising
should be entirely cleared as in !autoneg mode, the advertising mask
makes no sense.

However, I'm supposed to be on my vacation, so I'm not going to start
testing anything... this email as a bonus that would've otherwise have
been delayed by about two weeks... but the way things are going (family
issues) it could turn out to be a lot longer as I may have to become a
full time carer. So much for an opportunity to have an opportunity to
relax, which I desperately need.

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