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 03:35, Jianhui Xu wrote:
>> The only way this could be coming from the driver that I see is via a call
>> to ax88179a_stop(), which would clear exactly that bit.
>> Have you traced this and can exclude that this function is called somehow?
> 
> Yes. I added a dynamic kprobe on ax88179_write_cmd(), filtered to
> AX_MEDIUM_STATUS_MODE writes, and recorded the value and caller stack.
> 
> During 30 100baseT/Full-to-1000baseT/Full cycles, four transitions to
> 100baseT/Full lost RX. In all four cases:
> 
> - ax88179a_mac_link_up() first wrote 0x0102;
> - there was no intervening Linux write to AX_MEDIUM_STATUS_MODE;
> - about one second later the delayed worker read the register with
>    AX_MEDIUM_RECEIVE_EN clear and restored 0x0102.
> 
> All 71 traced writes to AX_MEDIUM_STATUS_MODE had
> AX_MEDIUM_RECEIVE_EN set. The complete 1,209-entry trace contained no
> ax88179a_stop() or ax88179_change_mtu() caller.
> 
[...]
> I do not think this proves an unconditional device-side bug, though. The v6
> driver failed four times in 30 cycles after writing 0x0102, while the vendor
> driver had no failures after writing 0x0132.
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. When a link change
is requested by phylink triggering re-configuring the PHY, the PHY is continued
to be polled by phylink. At this point, the PHY may report that the link is up
before the controller is actually finished configuring it. mac_link_up() is called
by phylink, but the controller overwrites the AX_MEDIUM_RECEIVE_EN
bit that is set by mac_link_up() when it continues with its configuration.

The solution is simple: do not poll the PHY with phylink, but wait until the
controller decides the link is completely configured, at which point an interrupt
USB-URB is sent. Then handle this interrupt in phylink in order to read the final PHY
configuration and only then call mac_link_up().

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.

Birger