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

Hi Jianhui,

thanks again for the thorough testing!
On 8/16/26 09:09, Jianhui Xu wrote:
> 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.
>
Perfect. So the race condition with the firmware looks solved.

> 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.
It makes perfect sense to do it this way round. I will test the proposed fix.

Birger