On Thu, 12 Mar 2026 14:46:40 +0100 Andrew Lunn wrote: > > Which reminds me -- I was suggesting that we add an order / id to the > > stages, not just name. Because AFAIU being able to request the loopback > > "very last loopback point of MAC" or "first loopback point of PHY" > > How do you define where the MAC ends?
MAC may not be the greatest of names because I'd include in it everything past the PHY, up to the DMA blocks. > I suspect some vendors will include the PCS and the PMA, because the > MAC ends at the MII pins on their SoC. Other vendors are going to say > the MAC ends at the interface to the PCS, especially those who have > licensed the PCS, and are using the shared Linux driver for the > PCS. And the PMA might again be a shared implementation, since it is > also used for USB, PCIe and SATA. > > If Linux is driving the hardware, using phylink, phylib, PCS drivers > and generic PHY, we are very likely to have a uniform definition of > all these parts. Are we happy firmware devices will have a much > fuzzier, different interpretation, conglomerating it all together? As long as the kernel API lets "integrated" devices expose both a MAC and a PHY node I don't think we should let anyone conglomerate. I see your point that the enum would work nicely for PHY stages. But it will be limiting for MAC stages. These conflicting preferences make having all of loopback config in one API tricky. I guess we could have a half-measure to add in the kernel the "well known" PHY stage name, and WARN_ON_ONCE() if some driver exposes PHY stage in something that's not a PHY. Or uses an unknown name for a PHY stage?
