Re: [PATCH net-next v2 02/12] ax88179_178a: Add HW support for AX179A-based chips

[Birger Koblitz <mail@birger-koblitz.de>]

On 7/16/26 17:42, Andrew Lunn wrote:
>> A comment on phylink and USB-Ethernet NICs, though. Grepping for phylink
>> in drivers/net/usb shows only 2 drivers that use phylink: asix_devices (the
>> antiquated one using the 772A-PHYs) and lan789xx, which is also rather old.
>> There are more than 30 drivers there, so that makes < 7% phylink usage vs 93% mii.
> 
> Most USB dongles are old. There might be new variant, but generally,
> that only means adding new VID:PID to a table and they work.
> 
> phylink becomes interesting is with speeds > 1G and enabling more
> features of the PHY, like EEE. Because mii is so old, it only supports
> speeds up to 1G. It also requires that PHY stick to the 802.3 C22
> registers, and don't really have an vendor registers. There is no
> concept of a PHY driver for mii, so there is nowhere to put per PHY
> code.
> 
> For a totally new USB-ethernet driver, i would strongly push back on
> mii and want to see phylink. For the existing drivers, there is little
> i can do, i don't have the hardware. Converting to phylink would
> however be a good project for a newbie, if they have the hardware, and
> what to really learn something, rather than all the AI driven
> theoretical bug fix patches we are getting at the moment.
> 
> You are in the space in between. It is not a fully new driver, but you
> are doing speeds > 1G. And you are looking at lots of features and
> need vendor registers, so per PHY code.
I will submit a new set of patches as v3, which will be based on using
phylink. I added the phy drivers to ax88796b.c, which already has the drivers
for the older chips such as the AX88772A, keeping the tradition that the
ASIX PHYs are called like the controllers they are included in (the ax88796b
like the 772A is actually an Ethernet controller according to the datasheet).

Using phylink makes the separation between MAC and PHY much cleaner, but
I have to say that it was not that easy to switch to phylink, as many things
no longer are done directly but rely on configuration magic that often fails,
for example when MMD devices are not correctly reported to be present by the PHY.
I have trouble to understand why an RTLN-lock needs to be held over many ms
to send the half a dozen configuration URBs to configure EEE, but maybe I am
just frustrated because I had to debug locking issues that froze my development
machine...

One thing I was not able to figure out is whether it is possible to make phylink
listen to callbacks when the link-change interrupt URBs arrive. The solution now
relies on phylink polling the controller for the link status, which prevents the
USB bus from going to sleep. This solution is also used by the other USB-Ethernet
drivers using phylink.

> 
> I have another idea to throw out there, and it might be a bad idea. I
> will let you think about it. Split the current driver into two. Make a
> library out of all the code handling packets. Leave the mii code in
> the actual driver. Then add a new driver, making use of the library
> for moving packets around, but using phylink for PHY management. You
> can add the new VID:PID to this new driver. This has the advantage of
> reducing the risk of regressing the old devices you don't have. Also,
> we can put out a request for test, see if anybody has the older
> hardware, and ask them to try testing with the VID:PID added to the
> new driver. We might be able to slowly migrate them to the phylink
> driver.
> 
I looked into that. ASIX changes the format of their RX and TX packets basically
with every major firmware release. The older 179 chips use 32 bit values in the
packet headers, the 179A use 64 bit, so those fixup routines cannot be re-used and
put into a library. What is being re-used is the framework of of how the
controllers are configured and react to events, so I would like to keep the code
together in the hope that the 179 hardware can also be convert like the rest of
to use phylink.

>> Looking into the Realtek PHY driver code, what is done there appears to duplicate
>> the code in r8152.
> 
> And other reason to use the Linux PHY driver, no code duplication. And
> there might be some freebies, like cable testing just works, it is
> possible to control the LEDs, etc.

Personally, I think it would be great to push these drivers to use phylink and also
use usbnet. But for that one needs to figure out how to make phylink also react
to USB-linkchange URBs and usbnet also needs support for multiple RX/TX queues.

Birger