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

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