Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval

From: Michal Pecio

Date: Wed Apr 22 2026 - 02:36:55 EST


On Fri, 3 Apr 2026 09:16:21 +0200, Michal Pecio wrote:
> On Thu, 2 Apr 2026 19:55:16 +0800, Xuetao (kirin) wrote:
> > > Any other examples besides AX88179?
> >
> > We tested 18 different USB 3.0 docks, but they only contained two
> > different types of USB 3.0 Ethernet devices based on VID/PID.
> > The dwc3 controller works fine with all of the devices mentioned
> > above. The other USB host controller works fine with all 12 Realtek
> > devices, but fails with all 6 ASIX devices.

I think this issue hasn't been solved yet?

> > 1. Realtek USB 10/100/1000 LAN (12 devices)
> > All 12 devices share the same VID/PID and descriptor values.
> >
> > VID = 0x0BDA, PID = 0x8153
> > wMaxPacketSize = 0x10
> > bMaxBurst = 0
> > wBytesPerInterval = 0x8
>
> My RTL8153 has this endpoint for its default proprietary configuration:
>
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0002 1x 2 bytes
> bInterval 8
> bMaxBurst 0
> wBytesPerInterval 2
>
> which should be problem-free, and this for its CDC configuration:
>
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0010 1x 16 bytes
> bInterval 8
> bMaxBurst 0
> wBytesPerInterval 8
>
> The CDC configuration needs to be enabled with a patch, I'm not sure
> if there is any other way. It will then use the r8153_ecm driver.

I have done some experimentation with RTL8153 CDC configuration and
found that it responds with 8 and 16 byte packets alternately:

# modprobe usbmon
# cat /sys/kernel/debug/usb/usbmon/0u
# ifconfig eth1 up
[...]
ffff88812bcc1600 364545038 S Ii:11:007:3 -115:128 16 <
ffff88812bcc1600 364577011 C Ii:11:007:3 0:128 8 = a1000000 01000000
ffff88812bcc1600 364577037 S Ii:11:007:3 -115:128 16 <
ffff88812bcc1600 364608979 C Ii:11:007:3 0:128 16 = a12a0000 01000800 00000000 00000000

I'm curious how your HC would treat this, because technically it should
interpret the first packet of wBytesPerInterval size as a partial
transfer and continue the same URB in the next interval, then complete
it with babble due to 16B packet exceeding both wBPI and URB capacity.

Other HCs work like that if I do the opposite and reduce wMaxPacketSize
to match wBytesPerInterval.

We would need to perform this alternative fixup for devices where
wBytesPerInterval is correct and 16B transfers are sent as two 8B
packets oven two intervals, while wMaxPacketSize is more than wBPI.
I hope no such insane devices exist. Currently, they wouldn't work
on the vast majority of HCs.

> > 2. ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter (6 devices)
> > All 6 devices share the same VID/PID.
> >
> > VID = 0x0B95, PID = 0x1790
> > (a) 4 devices:
> > wMaxPacketSize = 0x10
> > bMaxBurst = 0
> > wBytesPerInterval = 0x0
>
> This looks like my AX88179 and it's obviously broken.
>
> > (b) 2 devices:
> > wMaxPacketSize = 0x10
> > bMaxBurst = 0
> > wBytesPerInterval = 0x8
>
> But this is odd. When I use mine, I see that the driver submits 8 byte
> URBs and they complete successfully with 8 bytes received, no babble.

My driver submits 8B URBs because my AX88179 has wMaxPacketSize of 8.
On your device usbnet would submit 16B URBs. So I'm curious, how much
does your AX88179 send in response to those URBs?

Regards,
Michal