Hi Andrew,

thanks for reviewing this patch-series! I will answer to the other questions later,
so that the answers stay together. But it is probably best if I give this answer
immediately:
On 7/1/26 17:08, Andrew Lunn wrote:

quoted

quoted

+static void ax88179a_get_pauseparam(struct net_device *net, struct ethtool_pauseparam *pause)
+	if (!(bmcr & BMCR_ANENABLE)) {
+		pause->autoneg = 0;
+		pause->rx_pause = 0;
+		pause->tx_pause = 0;

The best way to have this correct is to use phylink, but for that you'd need to
have a proper PHY driver instead of using the mii_ API here.

I said the some to one of the other patches.

Do we know what PHYs are being used? Can register 2 and 3 be read to
get the PHY IDs?

	Andrew

I tested
   id1 = ax88179_mdio_read(dev->net, dev->mii.phy_id, MII_PHYSID1);
   id2 = ax88179_mdio_read(dev->net, dev->mii.phy_id, MII_PHYSID2);

and got:
Renkforce AX88179A: ID1 7c9f, ID2 7061
Delock AX88279  ID1 03a2, ID2 a411
UGreen AX88772D ID1 e65b, ID2 2c61
TP-Link AX88179A ID1 e65b, ID2 2c61

The UGreen 100MBit PHY has the same ID as the TP-Link 1GBit PHY.
The vendor and device IDs look rather arbitrary, but I checked, they
are consistent between unplugging and pluging back. They are not
known PHY-IDs, not even the vendor makes sense.

My understanding is that this does not look promising. I also have
the problem that I do not have any of the older AX88179 devices, which
all have the same USB vendor and device ID as the AX88179A-based devices,
which is the reason for adding them to this existing driver.

Birger