Message-ID: <CAKgT0UdaeXS=7YTnTSdRO4hyNrSbxuM3pDdmE=1JCvkizUYrZA@mail.gmail.com>
Date: Mon, 7 Apr 2025 11:20:24 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn <andrew@...n.ch>, 
	Maxime Chevallier <maxime.chevallier@...tlin.com>, netdev@...r.kernel.org, 
	hkallweit1@...il.com, davem@...emloft.net, pabeni@...hat.com
Subject: Re: [net PATCH 1/2] net: phy: Cleanup handling of recent changes to phy_lookup_setting

On Mon, Apr 7, 2025 at 10:01 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 4 Apr 2025 09:18:30 -0700 Alexander Duyck wrote:
> > > > Yep, this is pretty typical of SOHO switches, you use strapping to set
> > > > the port, and it never changes, at least not without a soldering iron
> > > > to take off/add resistors. There are also some SOHO switches which
> > > > have a dedicated 'cpu port' and there is no configuration options at
> > > > all. The CPU MAC must conform to what the switch MAC is doing.
> >
> > I don't think you guys understand my case well either. You seem to
> > think I am more flexible than I actually am in this setup. While I do
> > have the firmware I can ask about settings all it provides me with is
> > fixed link info. I can't talk to the link partner on the other end as
> > it is just configured for whatever the one mode is it has and there is
> > no changing it. Now yes, it isn't physically locked down. However most
> > of the silicon in the "fixed-link" configs likely aren't either until
> > they are put in their embedded setups.
>
> I understand this code the least of all of you, obviously, but FWIW
> in my mind the datacenter use case is more like trying to feed
> set_link_ksettings() from the EEPROM. Rather than a OS config script.
> Maybe call it "stored link" ? Not sure how fruitful arguing whether
> the term "fixed-link" can be extended to cover this is going to be :S

Arguably understanding this code, both phylink and our own MAC/PCS/PMD
code, has been a real grind but I think I am getting there. If I am
not mistaken the argument is that we aren't "fixed-link" as we have
control over what the PCS/PMA configuration is. We are essentially
managing things top down, whereas the expectation for "fixed-link" is
more of a bottom up. Where that gets murky for us is that the firmware
in our case did the top down config and is just notifying us of what
it did.

One thing I wasn't getting was that pcs_config doesn't actually set up
the PCS. If I am understanding things correctly now that will be
handled in the mac_config function. It will need to adjust the signals
running to the PCS IP in order for it to get into the correct PCS/FEC
mode, and then the PCS driver itself is only using the mii interface
to access the registers on the device to tweak things. It isn't
actually responsible for changing the PCS interface mode, just taking
care of any remaining configuration setting things such as autoneg
advertising.

The other thing I realized is that it looks like we might actually end
up using the XPCS driver. I also think I understand somewhat how they
may have things working as for the 25, 40, and 50 speeds at least most
of the management can be driven by the external pins so you can say
whatever you want about the config, but it will set itself up based on
what the external signals are telling it is.

The only complication is that we have a PMA/PMD on the end of the link
handling the role of CR PMD and it is behind the firmware so we will
have to see what I can do to make this all work. In the meantime I
think I can build things up slowly as sort of a reverse onion working
from the outside in starting with the MAC and working down toward the
PMD. It just means it will be a while before the upstream driver can
see a ksettings_set call as we will be fixed with the XLGMII interface
at the start until I can pull in the XPCS driver and then start
building out both at the same time.

Powered by blists - more mailing lists