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

[Jianhui Xu <neuromoments@gmail.com>]

Hi Birger,

I tested v5 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-v5. The focused W=1 builds for ax88179.o and
ax88796b.o were clean.

Unfortunately I reproduced an intermittent cold-activation failure, so I cannot
add a Tested-by for v5. In four fresh direct-kernel QEMU starts with complete
diagnostic capture, the old lease was released before starting DHCPDISCOVER. Two
reported 1000baseT/Full carrier but timed out DHCP, while two succeeded
normally. In both failed runs, RX remained at zero while TX increased. Reloading
ax88179 and ax88796b recovered DHCP, RX, and bound traffic in both cases.

Before this follow-up campaign, in the earlier v5 validation session, I observed
a separate 100baseT/Full failure: the adapter negotiated carrier after I changed
the advertisement to 100baseT/Full-only, but ARP and bound traffic failed.
I then tried to reproduce that result with three new advertise-0x008
transitions. All three negotiated 100baseT/Full and passed bound gateway
traffic; two also explicitly passed traffic to the test host. These repetitions
included tests both with and without a preceding module reload. I could not
reproduce the earlier 100-Mbit failure.

That earlier v5 validation session also produced a separate guest ACPI S3
failure: after resume, the adapter returned with 1000baseT/Full carrier, but RX
remained frozen and traffic was broken. I then performed three new S3 cycles.
All three logged QEMU's same emulated-XHCI resume reinitialization and USB
reset, but returned working traffic with increasing RX counters immediately. The
final repetition also recreated the earlier speed, EEE, and pause setting
sequence and verified working gateway traffic immediately before suspend.
I could not reproduce the earlier frozen-RX result. This remains a QEMU
emulated-XHCI test, not a physical-XHCI suspend test.

While reviewing the speed result, I noticed ax88179a_bulkin_config() selects its
table using ax179_data->speed, while ax88179a_mac_link_up() receives the speed
argument but I could not find an assignment to that private member. The new
passing 100-Mbit tests do not support linking that source observation to the
original one-off failure, and the same pattern appears in v4.

EEE disable/restore, pause enable/restore, EEPROM read, module reload, and USB
detach/reattach otherwise worked. I also tried Wake-on-LAN in QEMU. The driver
accepted magic-packet wake, ethtool read back Wake-on: g, and USB wakeup was
enabled before the guest entered S3. QEMU was configured with USB remote-wake
suppression disabled, but the guest did not resume after directed-broadcast,
limited-broadcast, and unicast magic packets. I consider that result
inconclusive because I did not independently verify the physical USB
remote-wakeup propagation through QEMU.

Please let me know if you would like me to test a fix or collect a specific
register trace.

Thanks,
Jianhui