On 7/1/26 19:05, Andrew Lunn wrote:

On Wed, Jul 01, 2026 at 06:22:31PM +0200, Birger Koblitz wrote:

quoted

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

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:

Thanks for these numbers.

quoted

Renkforce AX88179A: ID1 7c9f, ID2 7061
Delock AX88279  ID1 03a2, ID2 a411

air_en8811h.c:#define EN8811H_PHY_ID		0x03a2a411

quoted

UGreen AX88772D ID1 e65b, ID2 2c61
TP-Link AX88179A ID1 e65b, ID2 2c61

The two ID registers contain part of an OUI, but it has some bits
missing. So it is not so easy to look it up.

However, anything using the MII framework basically assumes a very
simple PHY and only looks at the 802.3 defined registers. So the
genphy generic PHY driver might be sufficient for when there is not a
specific driver. At lot depends on how much extra code there is
accessing the PHY registers in the driver.

I started converting the driver to phylink, but hit rock-bottom. There definitely is
an Airoha EN8811H as IP-core in the AX88279, which is clear from the PHY-ID and quirks
such as only Full-Duplex and ANEG being supported by the phy, but the firmware is
completely different, leading to different register content. The most striking example
is that the 2.5GBit advertising bit in the firmware for the AX88279 abuses the
ADVERTISE_RESV bit of the MII_ADVERTISE register, but in the EN8811H this is the
standard bit in the 10GBit advertising register. There is no firmware needed for the
PHY in the AX88279. The EN8811H mechanism for vendor register access is using a so-called
buckpbus using phy-register reads/writes for access, whereas similar vendor registers
of the AX88279 are just standard AX88279 registers, also to avoid USB-transfers.
The pbuckbus logic is not implemented in the AX88279 firmware, but in any case a
vendor register read for the EN8811H would need 5 URBs, where as the AX88279 just needs
1. The vendor registers also have very different content, for example the WoL bits
are entirely different.

I am also relatively sure that the PHY in the AX88179a/b is an Airoha AN8801, but
again the firmware is so different it looks like a completely different chip with
regards to registers. Again it uses the pbuckbus to access the vendor registers,
which is not implemented in the AX88179a firmware.

Changing the behaviour of the EN8811H driver to also accept the firmware of the
AX88279 IP-core implementation does not appear to make sense, it would be cleaner
to add a separate driver, but that would not work from the phylink-logic as it would
grab the same PHY-IDs.

I could simulate the EN8811H firmware in the ax88179_178a.c driver, but I guess that
would beat the purpose, plus it would cost quite an overhead in URBs.

For me the way ahead is to stick with the simple MII-driver and just make sure that
features such as pause configuration are properly implemented. Please tell me if that
makes sense or there are better ways.

Birger