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

Amin Vakil <[email protected]> Tue, 16 Jun 2026 15:21:41 +0330
Newsgroups	dev.linux.lists.regressions,org.kernel.vger.linux-usb
Message-ID	<[email protected]>
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

>> 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)