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 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.

And at least for the 179A-based controllers it is clear that there is an
advantage not to use phylink: When the link changes, the controller sends out
an interrupt URB, that has everything in there to set up the link. No need to
do costly USB requests to query the PHY.

How costly? You need to balance cost with frequency. If this is
something that happens once a day, when the machine is booted in the
morning, does it actually cost anything? And think about all the non
USB NICs, which do need to use a number of MDIO operations to find out
the state of the PHY. Nobody seems to complain about that.

In fact, the proprietary driver
works hard to not talk to the PHY at all. A good example is WoL, which is in
principle a PHY configuration issue. For setting that up, the driver actually
never talks to the PHY, everything necessary is done by the controller's
firmware. For USB Ethernet controllers it makes a lot of sense to abstract the
PHY away and rely only on controller commands that concurrently configure MAC and
PHY to reduce USB transfers.

I somewhat agree with you, if you can totally abstract the PHY, so a
PHY driver is not needed. Yet the driver code you posted has lots of
code dealing with the PHY. So it is clearly is not abstracted
away. Such abstractions do occur, with firmware driving the hardware,
look at many of the intel NICs, and most PCIe cards with speeds >
1G. They often only expose a MAC interface to Linux and everything
below that is hidden away in firmware.

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.

	Andrew