Re: [REGRESSION] usb: core: interrupt-IN wBytesPerInterval fixup (727d045d064b) breaks RTL8153 in Lenovo dock

Amin Vakil <[email protected]> Tue, 16 Jun 2026 17:38:32 +0330
Newsgroups	dev.linux.lists.regressions,org.kernel.vger.linux-usb
Message-ID	<[email protected]>
On 6/16/26 3:21 PM, Amin Vakil wrote:
> On 6/16/26 1:58 PM, Thorsten Leemhuis wrote:
>> On 6/16/26 11:49, Amin Vakil wrote:
>>>
>>> The following change, backported to the 7.0.x stable series, introduces
>>> a regression that disables the wired ethernet of a Lenovo USB-C/
>>> Thunderbolt dock:
>>>
>>>    commit 727d045d064b7c9a24db3bce9c0485a382cb768b
>>>    usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval
>>
>> Is 7.1 affected as well? Ideally try using a non-hardened kernel to keep
>> the downstream patches out of the way.
>>
>> Ciao, Thorsten
>>
> 
> linux 7.1 is not available on official Arch Linux repositories, give me 
> a couple of hours to compile and test, I'll use non-hardened kernel as 
> well, I'll propose a patch ensuring issue has been fixed as well, if 
> that's OK.
> 
> Best Regards,
> Amin Vakil
> 
I can confirm 7.1 mainline (installed from AUR) still has the problem:

dmesg (kernel 7.1.0)

   usb 2-1.1: New USB device found, idVendor=17ef, idProduct=721e, 
bcdDevice=31.03
   usbcore: registered new device driver r8152-cfgselector
   r8152-cfgselector 2-1.1: reset SuperSpeed USB device number 3 using 
xhci_hcd
   r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Invalid header 
when reading pass-thru MAC addr
   usbcore: registered new interface driver r8152
   r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0
   r8152-cfgselector 2-1.1: USB disconnect, device number 3


>>> Hardware: Lenovo dock built-in Realtek RTL8153, enumerating as USB ID
>>> 17ef:721e (Lenovo rebrand of 0bda:8153), driven by r8152 through r8152-
>>> cfgselector. Host is an Intel laptop with xhci_hcd.
>>>
>>> Symptom: on the patched kernel the NIC enumerates, r8152 binds and the
>>> netdev is created, then about one second later the device is USB-
>>> disconnected by r8152-cfgselector and never returns. No ethernet
>>> interface remains. USB, HDMI and the rest of the dock keep working, and
>>> plugging the cable straight into the laptop built-in NIC is unaffected.
>>>
>>> Affected vs working (Arch linux-hardened): 7.0.11.hardened2 works,
>>> 7.0.12.hardened1 is broken. This commit is the only RTL8153/USB-core
>>> change in that delta, and it activates a code path that did not run
>>> before on this device (note the new wBytesPerInterval message in the
>>> dmesg below, absent on 7.0.11).
>>>
>>> Why this commit: configuration 2 (CDC) of the device has an interrupt IN
>>> endpoint (EP 0x83) with wMaxPacketSize=16 and wBytesPerInterval=8. The
>>> new condition (wBytesPerInterval < wMaxPacketSize on an interrupt IN
>>> endpoint) now fires and rewrites wBytesPerInterval from 8 to 16. On this
>>> dock plus xHCI host that rewrite appears to make the device fall off the
>>> bus right after the cfgselector reset.
>>>
>>> dmesg (broken kernel 7.0.12.hardened1):
>>>    usb 2-1.1: New USB device found, idVendor=17ef, idProduct=721e,
>>> bcdDevice=31.03
>>>    usb 2-1.1: Int endpoint with wBytesPerInterval of 8 in config 2
>>> interface 0 altsetting 0 ep 131: setting to 16
>>>    r8152-cfgselector 2-1.1: reset SuperSpeed USB device number 3 using
>>> xhci_hcd
>>>    r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Invalid header
>>> when reading pass-thru MAC addr
>>>    r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0
>>>    r8152-cfgselector 2-1.1: USB disconnect, device number 3
>>>
>>> Relevant descriptors (lsusb -v -d 17ef:721e, captured on the working
>>> 7.0.11 kernel): configuration 2 (CDC), endpoint 0x83 IN Interrupt has
>>> wMaxPacketSize=0x0010 (16 bytes), bInterval=8, bMaxBurst=0,
>>> wBytesPerInterval=8 (rewritten to 16 by the new fixup). Configuration 1,
>>> the vendor config that r8152 actually uses, has its interrupt endpoint
>>> 0x83 with wMaxPacketSize=2 and wBytesPerInterval=2, which is not 
>>> affected.
>>>
>>> Reverting this commit (or just the new interrupt IN branch in drivers/
>>> usb/core/config.c) should restore the device. I am happy to build and
>>> confirm a revert, and to test any proposed fix. A quirk to skip the
>>> interrupt IN fixup for the RTL8153 CDC configuration, or otherwise
>>> narrowing the new condition, seems like the right direction.
>>>
>>> I can provide the full dmesg and full lsusb -v output on request.
>>>
>>> #regzbot introduced: 727d045d064b7c9a24db3bce9c0485a382cb768b
>>>
>>> Best Regards,
>>> Amin Vakil
>>
>
OpenPGP_0x1EFC1864E9D9E56B.asc (application/pgp-keys, 2.4 KB)
OpenPGP_signature.asc (application/pgp-signature, 665 B)