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

Thanks so much for testing, again, Jianhui!

On 03/08/2026 09:33, Jianhui Xu wrote:
> 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.
This issue is not critically problematic, the speed variable only affects the bulk
configuration settins that control how data is assembled in the controller and
assembled to larger USB transfers, including timing and so on. This should only harm
performance, but not the issues with the link after suspend/resume. It was introduced
in v3 or v4 when the speed info no longer came from the USB interrupt URB.

The following should fix this:
diff --git a/drivers/net/usb/ax88179a_devices.c b/drivers/net/usb/ax88179a_devices.c
index 37a55ff5464c..a4d782979c63 100644
--- a/drivers/net/usb/ax88179a_devices.c
+++ b/drivers/net/usb/ax88179a_devices.c
@@ -215,13 +215,13 @@ static void ax88179a_get_drvinfo(struct net_device *net, struct ethtool_drvinfo
                  priv->fw_version[2], priv->fw_version[3]);
  }

-static void ax88179a_bulkin_config(struct usbnet *dev, u8 link_sts)
+static void ax88179a_bulkin_config(struct usbnet *dev, u8 link_sts, u8 speed)
  {
         struct ax88179_data *ax179_data = dev->driver_priv;
         const struct ax_bulkin_settings *bulkin_data;
         int index = 0;

-       switch (ax179_data->speed) {
+       switch (speed) {
         case ETHER_LINK_2500:   /* AX88279 only */
                 index = 0;
                 break;
@@ -451,6 +451,7 @@ static void ax88179a_mac_link_up(struct phylink_config *config,
         struct usbnet *dev = netdev_priv(to_net_dev(config->dev));
         struct ax88179_data *ax179_data = dev->driver_priv;
         u8 tmp8, link_sts, reg8[3];
+       u8 bulk_config_speed = 0;
         u16 tmp16, mode;

         /* Stop RX/TX for link configuration */
@@ -503,11 +504,13 @@ static void ax88179a_mac_link_up(struct phylink_config *config,
                 ax88179_write_cmd(dev, AX_ACCESS_MAC, AX88179A_MAC_LSO_ENHANCE_CTRL, 1, 1, &tmp8);

                 mode |= AX_MEDIUM_GIGAMODE | AX_MEDIUM_FULL_DUPLEX;
+               bulk_config_speed = ETHER_LINK_2500;

                 break;

         case SPEED_1000:
                 mode |= AX_MEDIUM_GIGAMODE;
+               bulk_config_speed = ETHER_LINK_1000;
                 fallthrough;

         case SPEED_100:
@@ -518,6 +521,8 @@ static void ax88179a_mac_link_up(struct phylink_config *config,

                 tmp8 = 0x40;
                 ax88179_write_cmd(dev, AX_ACCESS_MAC, AX88179A_MAC_RX_DATA_CDC_CNT, 1, 1, &tmp8);
+               if (!bulk_config_speed)
+                       bulk_config_speed = ETHER_LINK_100;
                 break;

         case SPEED_10:
@@ -529,12 +534,12 @@ static void ax88179a_mac_link_up(struct phylink_config *config,
                 tmp8 = 0xFA;
                 ax88179_write_cmd(dev, AX_ACCESS_MAC, AX88179A_MAC_RX_DATA_CDC_CNT, 1, 1, &tmp8);

-               speed = 10;
+               bulk_config_speed = ETHER_LINK_10;
                 break;
         }

         ax88179_read_cmd(dev, AX_ACCESS_MAC, PHYSICAL_LINK_STATUS, 1, 1, &link_sts);
-       ax88179a_bulkin_config(dev, link_sts);
+       ax88179a_bulkin_config(dev, link_sts, bulk_config_speed);

         if (ax179_data->chip_version < AX_VERSION_AX88279) {
                 tmp8 = 0;


> 
> 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.
Could you trace the calls to __ax88179_write_cmd (registers, values) around the
suspend/resume events. Since the issue is not deterministic, it is probably sequence/timing-related.
My suspicion is that phylink sends PHY-polls after the controller got the sleep command.
Are there differences in the sequence of calls for the successfull suspend/resume
cycles and the unsuccessful ones?

Thanks!
   Birger