Re: [PATCH net-next v6 00/13] ax88179_178a: Add support for AX88179A-based chips

On 8/10/26 15:25, Andrew Lunn wrote:

quoted

I have finally understood what is happening: There is a race condition between
the controller of the AX88179A trying to set up and optimize the link and
phylink trying to configure the link on the mac-side.

This is why i dislike any hardware/firmware which thinks it is smarter
than Linux and directly access the hardware. Such features often break
stuff, because it does not respect the mutex Linux uses to serialise
access to the device.

The hardware by default uses CDC_NCM and even needs to be switched to the
vendor mode in order to allow any manual configuration of MAC and PHY.
As much as possible is supposed to work automagically. Linux support looks
very much like an afterthought.

quoted

I will provide a v7 with an additional phylink function phylink_mac_interrupt()
being introduced as suggested by Andrew, which is called by ax88179a_status()
in response to usbnet receiving the link change interrupt. I tested changing
the link a couple of dozen times and it always worked, now.

This will make it safer, but might not stop all the problems. Does the
PHY have LEDs? Does it have temperature sensors? Features like this
operate asynchronously to link state. The user can configure them at
any time. Such register writes might collide with what the firmware is
doing. I don't suppose you have physical access to the MDIO bus and
can put a logic analyser on it? Are there bus transactions happening
during normal operation which are not from Linux?

The device has LEDs, but they are entirely controlled by firmware. The behaviour
can be configured from the EEPROM. Writing to the EEPROM involves stopping
the firmware on the device. There are no temperature sensors, or maybe there are,
but the firmware hides them from us.

There is no physical access to the MDIO bus, as MAC and PHY are in the same
chip. I hope that otherwise we are safe from firmware interference, though.

Birger