Re: [PATCH v7 0/14] ax88179_178a: Add support for AX88179A-based chips

[Jianhui Xu <neuromoments@gmail.com>]

Hi Birger, 

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.
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, &reg8);
 	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.

Thanks,
Jianhui