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

Hi Jianhui,

thanks for testing this so thoroughly, again!
On 09/08/2026 03:36, Jianhui Xu wrote:

Hi Birger,

I tested v6 on the same ASIX AX88179B adapter (USB 0b95:1790,
bcdDevice 0x0200, firmware 1.3.0.0).

The 13 patches applied to net-next commit
df13c1df8147675470213ffff29dd5762fa321f5 and built successfully as
7.2.0-rc3-ax88179b-v6. The full build and focused W=1 builds for ax88179.o
and ax88796b.o were clean.

All 13 fresh direct-kernel QEMU starts completed a new DHCPDISCOVER at
1000baseT/Full without reloading the driver. This includes five functional
runs and the eight independent suspend/resume runs described below, so
I did not reproduce the v5 cold zero-RX failure.

However, I reproduced the intermittent 100-Mbit carrier-without-RX problem
in two of the five functional runs. In both failures, advertise 0x008
negotiated 100baseT/Full and reported carrier, but ARP remained incomplete,
bound pings to both the gateway and test host failed, and the RX counter
did not move (60 to 60 and 61 to 61) while TX increased. The same
transition passed in the other three runs.

So the bottom line is that everything works, except that there are spurious
failures with 100baseT/Full links where RX is disabled after the link
was established. I have so far not seen this myself, but will test with more
and different adapters as link partners in order to reproduce the issue. I tested
the 100MBit connections mainly with a AX88772E 100MBit adapter (UGREEN CR110),
which has the same firmware (1.3.0.0) as your and my AX88179B adapter. You did
not mention which device is used on the other side of the Ethernet link (or maybe
I missed that), could you specify this?

An immediate readback in mac_link_up() was not sufficient. An exact build
with that diagnostic reproduced zero RX after an EEE restore, showing that
AX_MEDIUM_RECEIVE_EN can be lost after mac_link_up() has returned.

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?
If this is not the case, this would mean there is a bug in the firmware
of the adapter which clears AX_MEDIUM_RECEIVE_EN in some cases for 100baseT/Full,
which seems to be what you also seem to suspect based on your proposed patch.

As an experiment, I therefore added a delayed check one second after
link-up. If carrier is still present and AX_MEDIUM_RECEIVE_EN is clear, the
worker restores the bit and verifies it by readback. The work is cancelled
on link-down and synchronously cancelled during stop, suspend, and detach.

If this can indeed be attributed to a bug in the firmware of the adapters, I would
add your patch to the series with an "Authored-by" you, as this sounds like a
good solution for this issue.

Birger