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

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

On 8/10/26 15:25, Andrew Lunn wrote:
>> 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.

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