Re: [PATCH v7 0/14] ax88179_178a: Add support for AX88179A-based chips
From: Birger Koblitz
Date: Sun Aug 16 2026 - 03:43:34 EST
Hi Jianhui,
thanks again for the thorough testing!
On 8/16/26 09:09, Jianhui Xu wrote:
Hi Birger,Perfect. So the race condition with the firmware looks solved.
I tested v7 on the same ASIX AX88179B adapter. The 14 patches applied
cleanly to net-next commit df13c1df8147675470213ffff29dd5762fa321f5 and
built as 7.2.0-rc3-ax88179b-v7. Full and focused W=1 builds for phylink.o,
ax88179.o, and ax88796b.o completed without warnings or errors.
The main functional tests passed: cold DHCP at 1000baseT/Full, the
1000/100/10/1000 Mbit/s matrix, EEE and pause disable/restore, EEPROM read,
module reload, and QEMU USB detach/reattach. I also ran 30 additional
100baseT/Full -> 1000baseT/Full cycles; all points passed carrier,
negotiated speed, bound traffic, and RX-growth checks. Including the normal
matrix, all 31 tested 100baseT/Full points passed, so I did not reproduce
the v6 intermittent 100-Mbit carrier-without-RX issue.
However, suspend/resume with magic-packet wake failed reproducibly.It makes perfect sense to do it this way round. I will test the proposed fix.
A deep-S3 cycle with `wol d` passed, but two independent fresh cycles with
`wol g` both resumed with the AX88179B interface stuck NO-CARRIER. Bound
traffic failed, neighbors remained unresolved, and RX did not increase
during immediate, 10-second, or 20-second checks.
In both failures, dmesg showed the USB reset followed by `Link is Down` and
`Link is Up - 1Gbps/Full` only about 11-13 ms apart, both before `PM:
suspend exit`. No later link event arrived after resume. By comparison, all
six retained v6 `wol g` trials passed, with Link Up occurring about 2.4-2.8
seconds after `PM: suspend exit`, when the link was actually usable.
I then tested a small ordering change in ax88179a_resume():
diff --git a/drivers/net/usb/ax88179a_devices.c b/drivers/net/usb/ax88179a_devices.c
index 6b57111a0..dc101902b 100644
--- a/drivers/net/usb/ax88179a_devices.c
+++ b/drivers/net/usb/ax88179a_devices.c
@@ -215,14 +215,14 @@ static int ax88179a_resume(struct usb_interface *intf)
ax88179_write_cmd(dev, AX88179A_PHY_POWER, 0, 0, 1, ®8);
msleep(250);
+ ax88179a_reset(dev);
+
if (netif_running(dev->net)) {
rtnl_lock();
phylink_resume(ax179_data->phylink);
rtnl_unlock();
}
- ax88179a_reset(dev);
-
ax88179_set_pm_mode(dev, false);
return usbnet_resume(intf);
The modified v7 passed all the aforementioned tests, plus 13 additional
`wol g` deep-S3 cycles. Every cycle resumed at 1000baseT/Full and passed
immediate, 10-second, and 20-second traffic/RX checks. All 13 `wol g`
traces contained a usable Link Up 2.017-4.020 seconds after `PM: suspend
exit`.
I'm not an expert in the Linux networking subsystem, so I'd appreciate it
if you could take another look at whether this ordering is appropriate.
Birger