linux.git, branch v6.13.10

Linux 6.13.10

2025-04-07T08:09:36+00:00

Link: https://lore.kernel.org/r/20250403151622.273788569@linuxfoundation.org
Tested-by: Salvatore Bonaccorso 
Tested-by: Pavel Machek (CIP) 
Tested-by: Peter Schneider 
Tested-by: Mark Brown 
Tested-by: Shuah Khan 
Tested-by: Florian Fainelli 
Tested-by: Jon Hunter 
Tested-by: Justin M. Forbes 
Tested-by: Ron Economos 
Signed-off-by: Greg Kroah-Hartman

bcachefs: bch2_ioctl_subvolume_destroy() fixes

2025-04-07T08:09:36+00:00

[ Upstream commit 707549600c4a012ed71c0204a7992a679880bf33 ]

bch2_evict_subvolume_inodes() was getting stuck - due to incorrectly
pruning the dcache.

Also, fix missing permissions checks.

Reported-by: Alexander Viro 
Signed-off-by: Kent Overstreet 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dma: terminate correct DMA in tx_dma_flush()

2025-04-07T08:09:36+00:00

commit a26503092c75abba70a0be2aa01145ecf90c2a22 upstream.

When flushing transmit side DMA, it is the transmit channel that should
be terminated, not the receive channel.

Fixes: 9e512eaaf8f40 ("serial: 8250: Fix fifo underflow on flush")
Cc: stable 
Reported-by: Wentao Guan 
Signed-off-by: John Keeping 
Reviewed-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/20250224121831.1429323-1-jkeeping@inmusicbrands.com
Signed-off-by: Greg Kroah-Hartman

serial: stm32: do not deassert RS485 RTS GPIO prematurely

2025-04-07T08:09:36+00:00

commit 2790ce23951f0c497810c44ad60a126a59c8d84c upstream.

If stm32_usart_start_tx is called with an empty xmit buffer, RTS GPIO
could be deasserted prematurely, as bytes in TX FIFO are still
transmitting.
So this patch remove rts disable when xmit buffer is empty.

Fixes: d7c76716169d ("serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 mode")
Cc: stable 
Signed-off-by: Cheick Traore 
Link: https://lore.kernel.org/r/20250320152540.709091-1-cheick.traore@foss.st.com
Signed-off-by: Greg Kroah-Hartman

perf tools: Fix up some comments and code to properly use the event_source bus

2025-04-07T08:09:36+00:00

commit 0cced76a0276610e86e8b187c09f0e9ef85b9299 upstream.

In sysfs, the perf events are all located in
/sys/bus/event_source/devices/ but some places ended up hard-coding the
location to be at the root of /sys/devices/ which could be very risky as
you do not exactly know what type of device you are accessing in sysfs
at that location.

So fix this all up by properly pointing everything at the bus device
list instead of the root of the sysfs devices/ tree.

Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Kan Liang 
Link: https://lore.kernel.org/r/2025021955-implant-excavator-179d@gregkh
Signed-off-by: Namhyung Kim 
Signed-off-by: Greg Kroah-Hartman

memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove

2025-04-07T08:09:36+00:00

commit 4676741a3464b300b486e70585c3c9b692be1632 upstream.

This fixes the following crash:

==================================================================
BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241

CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
Call Trace:
 
 dump_stack_lvl+0x51/0x70
 print_address_description.constprop.0+0x27/0x320
 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 print_report+0x3e/0x70
 kasan_report+0xab/0xe0
 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]
 ? __pfx___schedule+0x10/0x10
 ? kick_pool+0x3b/0x270
 process_one_work+0x357/0x660
 worker_thread+0x390/0x4c0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x190/0x1d0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 

Allocated by task 161446:
 kasan_save_stack+0x20/0x40
 kasan_save_track+0x10/0x30
 __kasan_kmalloc+0x7b/0x90
 __kmalloc_noprof+0x1a7/0x470
 memstick_alloc_host+0x1f/0xe0 [memstick]
 rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]
 platform_probe+0x60/0xe0
 call_driver_probe+0x35/0x120
 really_probe+0x123/0x410
 __driver_probe_device+0xc7/0x1e0
 driver_probe_device+0x49/0xf0
 __device_attach_driver+0xc6/0x160
 bus_for_each_drv+0xe4/0x160
 __device_attach+0x13a/0x2b0
 bus_probe_device+0xbd/0xd0
 device_add+0x4a5/0x760
 platform_device_add+0x189/0x370
 mfd_add_device+0x587/0x5e0
 mfd_add_devices+0xb1/0x130
 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]
 usb_probe_interface+0x15c/0x460
 call_driver_probe+0x35/0x120
 really_probe+0x123/0x410
 __driver_probe_device+0xc7/0x1e0
 driver_probe_device+0x49/0xf0
 __device_attach_driver+0xc6/0x160
 bus_for_each_drv+0xe4/0x160
 __device_attach+0x13a/0x2b0
 rebind_marked_interfaces.isra.0+0xcc/0x110
 usb_reset_device+0x352/0x410
 usbdev_do_ioctl+0xe5c/0x1860
 usbdev_ioctl+0xa/0x20
 __x64_sys_ioctl+0xc5/0xf0
 do_syscall_64+0x59/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 161506:
 kasan_save_stack+0x20/0x40
 kasan_save_track+0x10/0x30
 kasan_save_free_info+0x36/0x60
 __kasan_slab_free+0x34/0x50
 kfree+0x1fd/0x3b0
 device_release+0x56/0xf0
 kobject_cleanup+0x73/0x1c0
 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]
 platform_remove+0x2f/0x50
 device_release_driver_internal+0x24b/0x2e0
 bus_remove_device+0x124/0x1d0
 device_del+0x239/0x530
 platform_device_del.part.0+0x19/0xe0
 platform_device_unregister+0x1c/0x40
 mfd_remove_devices_fn+0x167/0x170
 device_for_each_child_reverse+0xc9/0x130
 mfd_remove_devices+0x6e/0xa0
 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]
 usb_unbind_interface+0xf3/0x3f0
 device_release_driver_internal+0x24b/0x2e0
 proc_disconnect_claim+0x13d/0x220
 usbdev_do_ioctl+0xb5e/0x1860
 usbdev_ioctl+0xa/0x20
 __x64_sys_ioctl+0xc5/0xf0
 do_syscall_64+0x59/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Last potentially related work creation:
 kasan_save_stack+0x20/0x40
 kasan_record_aux_stack+0x85/0x90
 insert_work+0x29/0x100
 __queue_work+0x34a/0x540
 call_timer_fn+0x2a/0x160
 expire_timers+0x5f/0x1f0
 __run_timer_base.part.0+0x1b6/0x1e0
 run_timer_softirq+0x8b/0xe0
 handle_softirqs+0xf9/0x360
 __irq_exit_rcu+0x114/0x130
 sysvec_apic_timer_interrupt+0x72/0x90
 asm_sysvec_apic_timer_interrupt+0x16/0x20

Second to last potentially related work creation:
 kasan_save_stack+0x20/0x40
 kasan_record_aux_stack+0x85/0x90
 insert_work+0x29/0x100
 __queue_work+0x34a/0x540
 call_timer_fn+0x2a/0x160
 expire_timers+0x5f/0x1f0
 __run_timer_base.part.0+0x1b6/0x1e0
 run_timer_softirq+0x8b/0xe0
 handle_softirqs+0xf9/0x360
 __irq_exit_rcu+0x114/0x130
 sysvec_apic_timer_interrupt+0x72/0x90
 asm_sysvec_apic_timer_interrupt+0x16/0x20

The buggy address belongs to the object at ffff888136335000
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 896 bytes inside of
 freed 2048-byte region [ffff888136335000, ffff888136335800)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x136330
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
page_type: f5(slab)
raw: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002
raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
head: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002
head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
head: 0017ffffc0000003 ffffea0004d8cc01 ffffffffffffffff 0000000000000000
head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888136335280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888136335300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888136335380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff888136335400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888136335480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management")
Signed-off-by: Luo Qiu 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/4B7BC3E6E291E6F2+20250317101438.25650-1-luoqiu@kylinsec.com.cn
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Apply the link chain quirk on NEC isoc endpoints

2025-04-07T08:09:36+00:00

commit bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 upstream.

Two clearly different specimens of NEC uPD720200 (one with start/stop
bug, one without) were seen to cause IOMMU faults after some Missed
Service Errors. Faulting address is immediately after a transfer ring
segment and patched dynamic debug messages revealed that the MSE was
received when waiting for a TD near the end of that segment:

[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]

It gets even funnier if the next page is a ring segment accessible to
the HC. Below, it reports MSE in segment at ff1e8000, plows through a
zero-filled page at ff1e9000 and starts reporting events for TRBs in
page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.

[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820

At some point completion events change from Isoch Buffer Overrun to
Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.

[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2

It's possible that data from the isochronous device were written to
random buffers of pending TDs on other endpoints (either IN or OUT),
other devices or even other HCs in the same IOMMU domain.

Lastly, an error from a different USB device on another HC. Was it
caused by the above? I don't know, but it may have been. The disk
was working without any other issues and generated PCIe traffic to
starve the NEC of upstream BW and trigger those MSEs. The two HCs
shared one x1 slot by means of a commercial "PCIe splitter" board.

[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0

Fortunately, it appears that this ridiculous bug is avoided by setting
the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
known which also expect the bit to be set and they ignore Link TRBs if
it's not. Reportedly, 0.95 spec guaranteed that the bit is set.

The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
tens of MSEs per second and runs into the bug within seconds. Chaining
Link TRBs allows the same workload to run for many minutes, many times.

No negative side effects seen in UVC recording and UAC playback with a
few devices at full speed, high speed and SuperSpeed.

The problem doesn't reproduce on the newer Renesas uPD720201/uPD720202
and on old Etron EJ168 and VIA VL805 (but the VL805 has other bug).

[shorten line length of log snippets in commit messge -Mathias]

Signed-off-by: Michal Pecio 
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Don't skip on Stopped - Length Invalid

2025-04-07T08:09:36+00:00

commit 58d0a3fab5f4fdc112c16a4c6d382f62097afd1c upstream.

Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are
returned when isoc ring is stopped") in v6.11, the driver didn't skip
missed isochronous TDs when handling Stoppend and Stopped - Length
Invalid events. Instead, it erroneously cleared the skip flag, which
would cause the ring to get stuck, as future events won't match the
missed TD which is never removed from the queue until it's cancelled.

This buggy logic seems to have been in place substantially unchanged
since the 3.x series over 10 years ago, which probably speaks first
and foremost about relative rarity of this case in normal usage, but
by the spec I see no reason why it shouldn't be possible.

After d56b0b2ab142, TDs are immediately skipped when handling those
Stopped events. This poses a potential problem in case of Stopped -
Length Invalid, which occurs either on completed TDs (likely already
given back) or Link and No-Op TRBs. Such event won't be recognized
as matching any TD (unless it's the rare Link TRB inside a TD) and
will result in skipping all pending TDs, giving them back possibly
before they are done, risking isoc data loss and maybe UAF by HW.

As a compromise, don't skip and don't clear the skip flag on this
kind of event. Then the next event will skip missed TDs. A downside
of not handling Stopped - Length Invalid on a Link inside a TD is
that if the TD is cancelled, its actual length will not be updated
to account for TRBs (silently) completed before the TD was stopped.

I had no luck producing this sequence of completion events so there
is no compelling demonstration of any resulting disaster. It may be
a very rare, obscure condition. The sole motivation for this patch
is that if such unlikely event does occur, I'd rather risk reporting
a cancelled partially done isoc frame as empty than gamble with UAF.

This will be fixed more properly by looking at Stopped event's TRB
pointer when making skipping decisions, but such rework is unlikely
to be backported to v6.12, which will stay around for a few years.

Fixes: d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped")
Cc: stable@vger.kernel.org
Signed-off-by: Michal Pecio 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20250306144954.3507700-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

net: usb: usbnet: restore usb%d name exception for local mac addresses

2025-04-07T08:09:36+00:00

commit 2ea396448f26d0d7d66224cb56500a6789c7ed07 upstream.

commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") assumed
that local addresses always came from the kernel, but some devices hand
out local mac addresses so we ended up with point-to-point devices with
a mac set by the driver, renaming to eth%d when they used to be named
usb%d.

Userspace should not rely on device name, but for the sake of stability
restore the local mac address check portion of the naming exception:
point to point devices which either have no mac set by the driver or
have a local mac handed out by the driver will keep the usb%d name.

(some USB LTE modems are known to hand out a stable mac from the locally
administered range; that mac appears to be random (different for
mulitple devices) and can be reset with device-specific commands, so
while such devices would benefit from getting a OUI reserved, we have
to deal with these and might as well preserve the existing behavior
to avoid breaking fragile openwrt configurations and such on upgrade.)

Link: https://lkml.kernel.org/r/20241203130457.904325-1-asmadeus@codewreck.org
Fixes: 8a7d12d674ac ("net: usb: usbnet: fix name regression")
Cc: stable@vger.kernel.org
Tested-by: Ahmed Naseef 
Signed-off-by: Dominique Martinet 
Acked-by: Oliver Neukum 
Link: https://patch.msgid.link/20250326-usbnet_rename-v2-1-57eb21fcff26@atmark-techno.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: usb: qmi_wwan: add Telit Cinterion FE990B composition

2025-04-07T08:09:36+00:00

commit e8cdd91926aac2c53a23925c538ad4c44be4201f upstream.

Add the following Telit Cinterion FE990B composition:
0x10b0: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) +
        tty (diag) + DPL + QDSS (Qualcomm Debug SubSystem) + adb

usb-devices:
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1bc7 ProdID=10b0 Rev=05.15
S:  Manufacturer=Telit Cinterion
S:  Product=FE990
S:  SerialNumber=28c2595e
C:  #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Cc: stable@vger.kernel.org
Signed-off-by: Fabio Porcedda 
Link: https://patch.msgid.link/20250227112441.3653819-2-fabio.porcedda@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman