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

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

[Amin Vakil]

[-- Attachment #1.1.1: Type: text/plain, Size: 3080 bytes --]

Hello everyone,

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

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2493 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

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

[Thorsten Leemhuis]

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

> 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

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

[Amin Vakil]

[-- Attachment #1.1.1: Type: text/plain, Size: 3717 bytes --]

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
> 


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2493 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

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

[Amin Vakil]

[-- Attachment #1.1.1: Type: text/plain, Size: 4462 bytes --]

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


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2493 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

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

[Michal Pecio]

On Tue, 16 Jun 2026 17:38:32 +0330, Amin Vakil wrote:
> 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

Was this junk always here?

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

RTL8153 was one of the chips specifically targeted by this fix, but
it affects the CDC configuration which you don't seem to be using.

I have tried linux-hardened-7.0.12.hardened1-1-x86_64 from Arch repo
as well as my own build of 7.1-rc6, and my RTL8153 (0bda:8153) in a
different kind of USB-C dock still works with a few xHCI controllers.

So it's some weird problem narrowly specific to your system. Now that
you have built your own kernel, please also revert the suspect patch
to verify if that's really it.

> >>> I can provide the full dmesg and full lsusb -v output on request.

lsusb -v of the NIC may be useful in case it's different from mine.
lsusb -tv of the whole dock, because there are other recent patches
for Lenovo docks and I'm not sure if they apply to yours.

Regards,
Michal

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

[Amin Vakil]

[-- Attachment #1.1.1: Type: text/plain, Size: 3846 bytes --]

On 6/16/26 8:06 PM, Michal Pecio wrote:
> On Tue, 16 Jun 2026 17:38:32 +0330, Amin Vakil wrote:
>> 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
> 
> Was this junk always here?

Yes, do you want me to look for older boots?

$ sudo journalctl -b -OLDER | grep -E "r8152"
kernel: Linux version 7.0.8-hardened1-1-hardened 
(linux-hardened@archlinux) (gcc (GCC) 16.1.1 20260430, GNU ld (GNU 
Binutils) 2.46.0) #1 SMP PREEMPT_DYNAMIC Fri, 15 May 2026 15:44:09 +0000
kernel: usbcore: registered new device driver r8152-cfgselector
kernel: r8152-cfgselector 2-1.1: reset SuperSpeed USB device number 3 
using xhci_hcd
kernel: r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Invalid 
header when reading pass-thru MAC addr
kernel: usbcore: registered new interface driver r8152
kernel: r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0
kernel: r8152 2-1.1:1.0 enp0s13f0u1u1: carrier on

> 
>>     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).
> 
> RTL8153 was one of the chips specifically targeted by this fix, but
> it affects the CDC configuration which you don't seem to be using.
> 
> I have tried linux-hardened-7.0.12.hardened1-1-x86_64 from Arch repo
> as well as my own build of 7.1-rc6, and my RTL8153 (0bda:8153) in a
> different kind of USB-C dock still works with a few xHCI controllers.
> 
> So it's some weird problem narrowly specific to your system. Now that
> you have built your own kernel, please also revert the suspect patch
> to verify if that's really it.

Honestly I've tried patching it myself :)

by changing

(le16_to_cpu(desc->wBytesPerInterval) < usb_endpoint_maxp(&ep->desc) &&

to

(le16_to_cpu(desc->wBytesPerInterval) == 0 &&

in line 187 of drivers/usb/core/config.c to see if that fixes the issue 
and it did not, but I didn't specifically reverted the commit to see if 
that fixes the issue.

I will revert the exact commit and report back.
> 
>>>>> I can provide the full dmesg and full lsusb -v output on request.
> 
> lsusb -v of the NIC may be useful in case it's different from mine.
> lsusb -tv of the whole dock, because there are other recent patches
> for Lenovo docks and I'm not sure if they apply to yours.
> 

Sure, I do not have the dock with me now, I'll send this tomorrow as well.

Best Regards,
Amin Vakil

> Regards,
> Michal


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2493 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

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

[Michal Pecio]

On Tue, 16 Jun 2026 20:22:19 +0330, Amin Vakil wrote:
> On 6/16/26 8:06 PM, Michal Pecio wrote:
> > RTL8153 was one of the chips specifically targeted by this fix, but
> > it affects the CDC configuration which you don't seem to be using.
> > 
> > I have tried linux-hardened-7.0.12.hardened1-1-x86_64 from Arch repo
> > as well as my own build of 7.1-rc6, and my RTL8153 (0bda:8153) in a
> > different kind of USB-C dock still works with a few xHCI controllers.
> > 
> > So it's some weird problem narrowly specific to your system. Now that
> > you have built your own kernel, please also revert the suspect patch
> > to verify if that's really it.  
> 
> Honestly I've tried patching it myself :)
> 
> by changing
> 
> (le16_to_cpu(desc->wBytesPerInterval) < usb_endpoint_maxp(&ep->desc) &&
> 
> to
> 
> (le16_to_cpu(desc->wBytesPerInterval) == 0 &&
> 
> in line 187 of drivers/usb/core/config.c to see if that fixes the issue 
> and it did not, but I didn't specifically reverted the commit to see if 
> that fixes the issue.

This should be enough to prevent overriding wBytesPerInterval on
RTL8153 (and get rid of the new log message).

If the message goes away but the device still doesn't work, the problem
must be somewhere else.

I would start with userspace - if you haven't already, downgrade to
some kernel package which worked in the past. See if it still works.
Or check if 9ddb9c0deca48d2c2a22ebf4d2f35c925a520328 applies to your
dock and try reverting it if it does.

Otherwise, no idea, besides git-bisect I guess.

Regards,
Michal