Re: 7.1 regression bisected to "usb: core: Fix SuperSpeed root hub wMaxPacketSize"

[Michal Pecio <michal.pecio@gmail.com>]

On Thu, 2 Jul 2026 00:09:42 +0300, Mathias Nyman wrote:
> On 7/1/26 19:02, Michel Dänzer wrote:
> > 
> > The ethernet port of a Lenovo ThinkPad USB-C Dock Gen2 connected to
> > a ThinkPad P14s Gen 5 AMD stopped working in 7.1.
> > 
> >   ip addr show enx482ae347e7c3
> > 
> > says the interface doesn't exist. The only thing about it in dmesg
> > is:
> > 
> >   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> > 
> > In previous kernels, dmesg had more lines about it:
> > 
> >   r8152 8-1.1:1.0 enx482ae347e7c3: renamed from eth0
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier off
> >   r8152 8-1.1:1.0 enx482ae347e7c3: carrier on
> > 
> > 
> > I bisected this to d1e280334b7f ("usb: core: Fix SuperSpeed root
> > hub wMaxPacketSize"). Reverting that commit on top of 7.1.2 fixes
> > the issue.

Incredibly bizarre, I wonder if it's some userspace madness.

Does this alternative patch (on top of the revert) break it too?
https://lore.kernel.org/linux-usb/20260504111353.55ba2530.michal.pecio@gmail.com/

> That patch limits USB3 roothub change bitmap from 4 bytes to 2 bytes,
> which should be enough for the max 15 children USB3 hubs support.
> Odd that this change impacts the usb ethernet device of that dock.

Very odd: as you said before, hub driver wouldn't support more than
15 ports anyway, the problem occurs on port 1, and is not any obvious
hub issue like connection event never noticed by the kernel.

I thought that maybe writing the status change URB overflows its
transfer buffer, but usb_hcd_poll_rh_status() seems to be handling
such cases correctly. And xhci_hub_status_data() isn't even aware
of URB length, so it can't be sensitive to this change.

> If possible, could you share a dmesg with usbcore dynamic debug
> enabled
> 
> mount -t debugfs none /sys/kernel/debug
> echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> <connect dock>
> dmesg

If not possible, please at least post ordinary dmesg. Even if there is
nothing more about "enx482ae347e7c3", there might be about "8-1.1:1.0".
The snippet above is a small part of typical r8152 connection log.

Regards,
Michal