Re: [PATCH net-next 0/7] Allow controlling PHY loopback and isolate modes

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hello Andrew, Florian,

On Thu, 12 Sep 2024 11:26:41 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 9/12/24 11:21, Andrew Lunn wrote:
> >> The loopback control from that API is added as it fits the API
> >> well, and having the ability to easily set the PHY in MII-loopback
> >> mode is a helpful tool to have when bringing-up a new device and
> >> troubleshooting the link setup.  
> > 
> > We might want to take a step back and think about loopback some more.
> > 
> > Loopback can be done at a number of points in the device(s). Some
> > Marvell PHYs can do loopback in the PHY PCS layer. Some devices also
> > support loopback in the PHY SERDES layer. I've not seen it for Marvell
> > devices, but maybe some PHYs allow loopback much closer to the line?
> > And i expect some MAC PCS allow loopback.
> > 
> > So when talking about loopback, we might also want to include the
> > concept of where the loopback occurs, and maybe it needs to be a NIC
> > wide concept, not a PHY concept?  
> 
> Agreed, you can loop pretty much anywhere in the data path, assuming the 
> hardware allows it. For the hardware I maintain, we can loop back within 
> the MAC as close as possible from the interface to DRAM, or as "far" as 
> possible, within the MII signals, but without actually involving the PHY.
> 
> Similarly, the PHY can loop as close as possible from the electrical 
> data lines, or as far as possible by looping the *MII pins, before 
> hitting the MAC.
> 
> So if nothing else, we have at least 4 kinds of loopbacks that could be 
> supported, it is not clear whether we want to define all of those as 
> standardized "modes" within Linux, and let drivers implement the ones 
> they can, or if we just let drivers implement the mode they have, and 
> advertise those. Meaning your user experience could vary.

Oleksji identified some loopback modes in TI PHYs, the PHYs have access
to have even different sets of loopback modes / locations as well, to me
it's hard to come-up with a list of all the possible loopback locations
indeed.

However, I don't think it's inconceivable to come-up with a list - that
can be extented - of possible loopback spots.

Making the loopback a NIC concept would indeed make sense here, where we
would aggregate all possible loopback points within the NIC and PHY(s)
combined, and having ways for MAC/PHYS to enumerate their loopback
modes through a set of ethtoop ops.

With that being said, is it OK if I split the loopback part out of that
series ? From the comments, it looks like a complex-enough topic to be
covered on its own, and if we consider the loopback as a NIC feature,
then it doesn't really fit into the current work anymore.

I am however happy to continue discussing that topic. Using loopback
has proven to be most helpful several times for me when bringing-up
devices.

Thanks,

Maxime