* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-06 0:40 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #3 from Morgwai Kotarbinski (foss@morgwai.pl) ---
Created attachment 309828
--> https://bugzilla.kernel.org/attachment.cgi?id=309828&action=edit
dmesg log from the boot after a deg2-induced reboot
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Andrew Lunn @ 2026-04-05 23:38 UTC (permalink / raw)
To: Petko Manolov
Cc: Simon Horman, Morduan Zang, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-usb, netdev,
linux-kernel, syzbot+9db6c624635564ad813c
In-Reply-To: <20260405085212.GA8491@cabron.k.g>
> > - get_registers(dev, CSCR, 2, &tmp);
> > + if (get_registers(dev, CSCR, 2, &tmp) < 0)
> > + tmp = 0;
> > if (tmp & CSCR_LINK_STATUS)
> > netif_carrier_on(netdev);
> > else
>
> I was wondering if calling netif_carrier_off() is the right thing to do in case
> get_registers() fail.
>
> There are multiple get_registers() calls that don't check the error and if we do
> this in set_carrier() maybe we should do the same thing across the whole driver?
What does it actually mean if get_registers() fails? The device is
gone? Hot unplugged? If so, you are going to get a cascade of errors,
and then hopefully the USB core code removes the device?
Are there any legitimate reasons for get_registers() to fail if the
device is still plugged in?
It seems netif_carrier_off() is unnecessary?
Andrew
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Doug Anderson @ 2026-04-05 22:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J . Wysocki, Danilo Krummrich, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <2026040539-sponge-publisher-2b42@gregkh>
Hi,
On Sat, Apr 4, 2026 at 10:28 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Apr 03, 2026 at 05:04:54PM -0700, Douglas Anderson wrote:
> > NOTE: one potentially "controversial" choice I made in some patches
> > was to always reserve a flag ID even if a flag is only used under
> > certain CONFIG_ settings. This is a change from how things were
> > before. Keeping the numbering consistent and allowing easy
> > compile-testing of both CONFIG settings seemed worth it, especially
> > since it won't take up any extra space until we've added a lot more
> > flags.
>
> Nah, this is fine, I don't see any problems with this as the original
> code kind of was doing the same thing with the "hole" in the structure
> if those options were not enabled.
>
> > I only marked the first patch as a "Fix" since it is the only one
> > fixing observed problems. Other patches could be considered fixes too
> > if folks want.
> >
> > I tested the first patch in the series backported to kernel 6.6 on the
> > Pixel phone that was experiencing the race. I added extra printouts to
> > make sure that the problem was hitting / addressed. The rest of the
> > patches are tested with allmodconfig with arm32, arm64, ppc, and
> > x86. I boot tested on an arm64 Chromebook running mainline.
>
> I'm guessing your tests passed? :)
Yup, all the tests that I've run have passed. I also threw in an
"allnoconfig" compile test just for good measure.
> Anyway, this looks great, unless there are any objections, other than
> the "needs to be undefined", which a follow-on patch can handle, I'll
> queue them up next week for 7.1-rc1.
Thanks. As per the other thread, I'm happy if you or Danilo want to
apply it, and I'm happy if you want to make minor fixups when
applying.
When I see the patches applied, I'll send a followup patch to address
the "needs to be undefined" comment, unless Danilo makes that change
himself when applying.
-Doug
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-05 22:44 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #10 from manauer.uel@gmail.com ---
Correction to my previous comment:
I said I could not rule out that the device disconnected on its own. Looking at
the new log more carefully, the mouse was already working with the rule active
when I started capturing. When I manually unplugged it, a split transaction
error appears right at the moment of disconnect. So that error is a consequence
of pulling the cable.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-05 22:37 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #9 from manauer.uel@gmail.com ---
> Can you check what's making this noise?
> cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
$ sudo cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
2-3
That would be bus 2, port 3 on the Intel controller, right? Checking sysfs says
it is the Apple Internal Memory Card Reader (05ac:8406), the SD card slot built
into the MacBook.
$ lsusb | grep "Bus 002"
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05ac:8406 Apple, Inc. Internal Memory Card Reader
$ cat /sys/bus/usb/devices/2-3/manufacturer
Apple
$ cat /sys/bus/usb/devices/2-3/product
Card Reader
$ cat /sys/bus/usb/devices/2-3/idVendor
05ac
$ cat /sys/bus/usb/devices/2-3/idProduct
8406
> Does this cancellation go away when you enable the udev rule or ALWAYS_POLL?
> Maybe something goes wrong here.
I captured a new log with the rule enabled and replugged the mouse. I think
with the udev rule active the cancellation disappears as far as I can see. The
enumeration looks the same as before up to the point where the mouse is
recognized and the hidraw nodes are created. After that, the ASMedia controller
goes completely silent. No Cancel URB on ep 0x81, no split transaction error,
nothing. Just the Intel slot 2 ep 2 stalls in the background as usual. The
mouse works.
> Does it mean that the device kept disconnecting by itself and it wasn't you
> doing it?
Some were definitely me replugging. But I cannot rule out that the device also
disconnected on its own at some point before I pulled the cable. The split
transaction error appeared very shortly before one of the disconnects, so it is
possible both happened. I definitely followed your instruction, if I remember
it correctly:
> > Then connect the mouse with your udev rule, make a few clicks, disconnect,
> remove the udev rule, connect again, make a few clicks.
> Do you have some other USB 2.0/3.0 hub you could put between the monitor and
> the mouse?
> Does it make any difference?
I already tried this with two different USB hub dongles placed between the
monitor and the mouse. The behavior was identical. The problem persists
regardless of which hub is in between, which made me think the issue is maybe
with the ASMedia controller itself rather than the LG hub specifically.
One observation that might or might not be related I already mentioned in my
initial report is that plugging in an unrelated wireless Logitech USB dongle
into the monitor makes the wired mouse start working after replugging. The
dongle itself has nothing to do with the wired mouse. I have no good
explanation for why a second device being present would change anything, but it
seemed worth mentioning in case it points at something on the hub or controller
side.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-05 22:09 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #8 from manauer.uel@gmail.com ---
Created attachment 309827
--> https://bugzilla.kernel.org/attachment.cgi?id=309827&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule on only
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [GIT PULL] USB driver fixes for 7.0-rc7
From: pr-tracker-bot @ 2026-04-05 17:13 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-usb
In-Reply-To: <adIdzbVtDh2g5Ofo@kroah.com>
The pull request you sent on Sun, 5 Apr 2026 10:31:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-7.0-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aea7c84f28f1117653f7443806905d7aeef13ba8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Danilo Krummrich @ 2026-04-05 12:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Douglas Anderson, Rafael J . Wysocki, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <2026040539-sponge-publisher-2b42@gregkh>
On Sun Apr 5, 2026 at 7:27 AM CEST, Greg Kroah-Hartman wrote:
> Anyway, this looks great, unless there are any objections, other than
> the "needs to be undefined", which a follow-on patch can handle, I'll
> queue them up next week for 7.1-rc1.
Sounds good, for the series:
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-05 11:58 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #2 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Can you check the log from the kernel on the boot AFTER this happened? There
will be a log event indicating the last reboot reason.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Petko Manolov @ 2026-04-05 8:52 UTC (permalink / raw)
To: Simon Horman
Cc: Morduan Zang, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-usb, netdev, linux-kernel,
syzbot+9db6c624635564ad813c
In-Reply-To: <20260403154538.GA187715@horms.kernel.org>
On 26-04-03 16:45:38, Simon Horman wrote:
> On Thu, Apr 02, 2026 at 03:07:43PM +0800, Morduan Zang wrote:
> > Check get_registers() when reading CSCR in set_carrier().
> > If the control transfer fails, don't use the stack value.
> >
> > Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
> > ---
> > drivers/net/usb/rtl8150.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> > index 4cda0643afb6..7e32726d3e6f 100644
> > --- a/drivers/net/usb/rtl8150.c
> > +++ b/drivers/net/usb/rtl8150.c
> > @@ -722,7 +722,11 @@ static void set_carrier(struct net_device *netdev)
> > rtl8150_t *dev = netdev_priv(netdev);
> > short tmp;
> >
> > - get_registers(dev, CSCR, 2, &tmp);
> > + if (get_registers(dev, CSCR, 2, &tmp) < 0) {
> > + netif_carrier_off(netdev);
> > + return;
> > + }
> > +
> > if (tmp & CSCR_LINK_STATUS)
> > netif_carrier_on(netdev);
> > else
>
> I wonder if we can handle this a bit more succinctly,
> while still making it clear that the error is handled.
> Something like this:
>
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 4cda0643afb6..816759ced56c 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -722,7 +722,8 @@ static void set_carrier(struct net_device *netdev)
> rtl8150_t *dev = netdev_priv(netdev);
> short tmp;
>
> - get_registers(dev, CSCR, 2, &tmp);
> + if (get_registers(dev, CSCR, 2, &tmp) < 0)
> + tmp = 0;
> if (tmp & CSCR_LINK_STATUS)
> netif_carrier_on(netdev);
> else
I was wondering if calling netif_carrier_off() is the right thing to do in case
get_registers() fail.
There are multiple get_registers() calls that don't check the error and if we do
this in set_carrier() maybe we should do the same thing across the whole driver?
cheers,
Petko
^ permalink raw reply
* [GIT PULL] USB driver fixes for 7.0-rc7
From: Greg KH @ 2026-04-05 8:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-usb
The following changes since commit f338e77383789c0cae23ca3d48adcc5e9e137e3c:
Linux 7.0-rc4 (2026-03-15 13:52:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-7.0-rc7
for you to fetch changes up to bf3781a35c27978341c31f59f1460dcaabf2e726:
Merge tag 'usb-serial-7.0-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus (2026-04-02 13:28:22 +0200)
----------------------------------------------------------------
USB/Thunderbolt fixes for 7.0-rc7
Here are a bunch of USB and Thunderbolt fixes (most all are USB) for
7.0-rc7. More than I normally like this late in the release cycle,
partly due to my recent travels, and partly due to people banging away
on the USB gadget interfaces and apis more than normal (big shoutout to
Android for getting the vendors to actually work upstream on this,
that's a huge win overall for everyone here.)
Included in here are:
- Small thunderbolt fix
- new USB serial driver ids added
- typec driver fixes
- gadget driver fixes for some disconnect issues
- other usb gadget driver fixes for reported problems with binding and
unbinding devices as happens when a gadget device connects /
disconnects from a system it is plugged into (or it switches device
mode at a user's request, these things are complex little beasts...)
- usb offload fixes (where USB audio tunnels through the controller
while the main CPU is asleep) for when EMP spikes hit the system
causing disconnects to happen (as often happens with static
electricity in the winter months). This has been much reported by
at least one vendor, and resolves the issues they have been seeing
with this codepath. Can't wait for the "formal methods are the
answer!" people to try to model that one properly...
- Other small usb driver fixes for issues reported.
All of these have been in linux-next this week, and before, with no
reported issues, and I've personally been stressing these harder than
normal on my systems here with no problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Alan Stern (2):
USB: dummy-hcd: Fix locking/synchronization error
USB: dummy-hcd: Fix interrupt synchronization error
Andrei Kuchynski (2):
usb: typec: Remove alt->adev.dev.class assignment
usb: typec: thunderbolt: Set enter_vdo during initialization
Ernestas Kulik (1):
USB: serial: option: add MeiG Smart SRM825WN
Felix Gu (2):
dwc3: google: Fix PM domain leak in dwc3_google_probe()
usb: misc: usbio: Fix URB memory leak on submit failure
Frej Drejhammar (1):
USB: serial: io_edgeport: add support for Blackbox IC135A
Gabor Juhos (1):
usb: core: phy: avoid double use of 'usb3-phy'
Greg Kroah-Hartman (2):
Merge tag 'thunderbolt-for-v7.0-rc5' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus
Merge tag 'usb-serial-7.0-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Guan-Yu Lin (2):
usb: core: use dedicated spinlock for offload state
usb: host: xhci-sideband: delegate offload_usage tracking to class drivers
Guangshuo Li (1):
usb: ulpi: fix double free in ulpi_register_interface() error path
Heitor Alves de Siqueira (1):
usb: usbtmc: Flush anchored URBs in usbtmc_release
JP Hein (1):
USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
Jimmy Hu (1):
usb: gadget: uvc: fix NULL pointer dereference during unbind race
Juno Choi (1):
usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()
Justin Chen (1):
usb: ehci-brcm: fix sleep during atomic
Konrad Dybcio (1):
thunderbolt: Fix property read in nhi_wake_supported()
Kuen-Han Tsai (9):
usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop
usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo
usb: gadget: f_subset: Fix unbalanced refcnt in geth_free
usb: gadget: f_rndis: Protect RNDIS options with mutex
usb: gadget: u_ncm: Add kernel-doc comments for struct f_ncm_opts
usb: gadget: f_ecm: Fix net_device lifecycle with device_move
usb: gadget: f_eem: Fix net_device lifecycle with device_move
usb: gadget: f_subset: Fix net_device lifecycle with device_move
usb: gadget: f_rndis: Fix net_device lifecycle with device_move
Miao Li (1):
usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive
Michael Zimmermann (1):
usb: gadget: f_hid: move list and spinlock inits from bind to alloc
Nathan Rebello (1):
usb: typec: ucsi: validate connector number in ucsi_notify_common()
Oliver Neukum (1):
cdc-acm: new quirk for EPSON HMD
Sebastian Urban (1):
usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows partial transfer
Taegu Ha (1):
usb: gadget: f_uac1_legacy: validate control request size
Wanquan Zhong (1):
USB: serial: option: add support for Rolling Wireless RW135R-GL
Xiaolei Wang (1):
usb: dwc3: imx8mp: fix memory leak on probe failure path
Xu Yang (2):
usb: hcd: queue wakeup_work to system_freezable_wq workqueue
dt-bindings: connector: add pd-disable dependency
Yongchao Wu (2):
usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
usb: cdns3: gadget: fix state inconsistency on gadget init failure
.../bindings/connector/usb-connector.yaml | 1 +
drivers/thunderbolt/nhi.c | 2 +-
drivers/usb/cdns3/cdns3-gadget.c | 4 +
drivers/usb/class/cdc-acm.c | 9 ++
drivers/usb/class/cdc-acm.h | 1 +
drivers/usb/class/usbtmc.c | 3 +
drivers/usb/common/ulpi.c | 5 +-
drivers/usb/core/driver.c | 23 +++--
drivers/usb/core/hcd.c | 2 +-
drivers/usb/core/offload.c | 102 ++++++++++++---------
drivers/usb/core/phy.c | 12 ++-
drivers/usb/core/quirks.c | 3 +
drivers/usb/core/usb.c | 1 +
drivers/usb/dwc2/gadget.c | 2 +
drivers/usb/dwc3/dwc3-google.c | 5 +-
drivers/usb/dwc3/dwc3-imx8mp.c | 2 +-
drivers/usb/gadget/function/f_ecm.c | 35 ++++---
drivers/usb/gadget/function/f_eem.c | 59 ++++++------
drivers/usb/gadget/function/f_hid.c | 19 ++--
drivers/usb/gadget/function/f_rndis.c | 49 ++++++----
drivers/usb/gadget/function/f_subset.c | 63 +++++++------
drivers/usb/gadget/function/f_uac1_legacy.c | 47 ++++++++--
drivers/usb/gadget/function/f_uvc.c | 39 +++++++-
drivers/usb/gadget/function/u_ecm.h | 21 +++--
drivers/usb/gadget/function/u_eem.h | 21 +++--
drivers/usb/gadget/function/u_ether.c | 16 ++--
drivers/usb/gadget/function/u_gether.h | 22 +++--
drivers/usb/gadget/function/u_ncm.h | 21 +++--
drivers/usb/gadget/function/u_rndis.h | 31 +++++--
drivers/usb/gadget/function/uvc.h | 3 +
drivers/usb/gadget/function/uvc_v4l2.c | 5 +-
drivers/usb/gadget/udc/dummy_hcd.c | 42 +++++----
drivers/usb/host/ehci-brcm.c | 4 +-
drivers/usb/host/xhci-sideband.c | 18 +---
drivers/usb/misc/usbio.c | 7 +-
drivers/usb/serial/io_edgeport.c | 3 +
drivers/usb/serial/io_usbvend.h | 1 +
drivers/usb/serial/option.c | 4 +
drivers/usb/typec/altmodes/thunderbolt.c | 44 ++++-----
drivers/usb/typec/class.c | 4 -
drivers/usb/typec/ucsi/ucsi.c | 9 +-
include/linux/usb.h | 10 +-
sound/usb/qcom/qc_audio_offload.c | 10 +-
43 files changed, 507 insertions(+), 277 deletions(-)
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Greg Kroah-Hartman @ 2026-04-05 5:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Rafael J . Wysocki, Danilo Krummrich, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>
On Fri, Apr 03, 2026 at 05:04:54PM -0700, Douglas Anderson wrote:
> NOTE: one potentially "controversial" choice I made in some patches
> was to always reserve a flag ID even if a flag is only used under
> certain CONFIG_ settings. This is a change from how things were
> before. Keeping the numbering consistent and allowing easy
> compile-testing of both CONFIG settings seemed worth it, especially
> since it won't take up any extra space until we've added a lot more
> flags.
Nah, this is fine, I don't see any problems with this as the original
code kind of was doing the same thing with the "hole" in the structure
if those options were not enabled.
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
I'm guessing your tests passed? :)
Anyway, this looks great, unless there are any objections, other than
the "needs to be undefined", which a follow-on patch can handle, I'll
queue them up next week for 7.1-rc1.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-05 3:10 UTC (permalink / raw)
To: Alan Stern
Cc: Thinh Nguyen, Mathias Nyman, linux-usb@vger.kernel.org,
michal.pecio@gmail.com, oneukum@suse.com,
niklas.neronin@linux.intel.com
In-Reply-To: <b4e2edd9-2616-4cfe-90a5-438fb6625706@rowland.harvard.edu>
On Sat, Apr 04, 2026, Alan Stern wrote:
> On Sat, Apr 04, 2026 at 10:28:24PM +0000, Thinh Nguyen wrote:
> > On Sat, Apr 04, 2026, Thinh Nguyen wrote:
> > > On Sat, Apr 04, 2026, Alan Stern wrote:
> > > > If the class driver wants to take some other action (like submitting
> > > > URBs to a different endpoint) before using the endpoint that stopped,
> > > > it's free to do so. It only has to make sure that it doesn't submit any
> > > > URBs to the stopped endpoint until after the other action is finished --
> > > > which is what it would do anyway. (And maybe it has to unlink any URBs
> > > > that are already queued, which can be done with a simple function call.)
> > > >
> > >
> > > Then the xhci must make sure that it should not ring the doorbell to
> > > restart the endpoint when giving back the canceled URBs. It should only
> > > do so on newly submitted URBs.
> >
> > Ignore this comment, it's not restarting the endpoint in the case of
> > unlinking.
>
> I was going to say that xhci-hcd shouldn't restart the endpoint until
> the usb_reset_endpoint() call is made. Whether or not it rings the
> doorbell at that time may depend on whether there are any URBs on the
> queue; that's a relatively unimportant implementation detail.
>
> > > We can add a requirement such that if the class driver submitted the
> > > recovery URBs prior to completing the usb_reset_endpoint (which should
> > > be done after clear-halt), then the HCD may keep those URBs on a queue
> > > and only process those URBs and restart the endpoint afterward.
> > >
> >
> > Actually, adding this new requirement would be tricky because we don't
> > know whether it's recovery URBs or not.
>
> The purpose of the submitted URBs doesn't matter. The HCD shouldn't
> restart the endpoint until the usb_reset_endpoint() call occurs.
>
> Also, I should point out that usbcore will call usb_clear_halt() and
> usb_reset_endpoint(), presumably using a work queue for the calls. The
> class driver doesn't need to do it -- in fact, doing those things could
> lead to errors because the endpoint may already be running (the core may
> already have made the calls).
>
That's good. This is what I wanted to confirm.
May need to update how xhci handles usb_reset_endpoint() because I
believe it's expected the endpoint transfer ring to be drained prior (by
the class driver unlinking URBs).
Thanks for the clarifications,
Thinh
ps. Have a good weekend! I'll be back a week after.
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Alan Stern @ 2026-04-05 1:30 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Mathias Nyman, linux-usb@vger.kernel.org, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <20260404222818.t5y52gnd2gvalvp5@synopsys.com>
On Sat, Apr 04, 2026 at 10:28:24PM +0000, Thinh Nguyen wrote:
> On Sat, Apr 04, 2026, Thinh Nguyen wrote:
> > On Sat, Apr 04, 2026, Alan Stern wrote:
> > > If the class driver wants to take some other action (like submitting
> > > URBs to a different endpoint) before using the endpoint that stopped,
> > > it's free to do so. It only has to make sure that it doesn't submit any
> > > URBs to the stopped endpoint until after the other action is finished --
> > > which is what it would do anyway. (And maybe it has to unlink any URBs
> > > that are already queued, which can be done with a simple function call.)
> > >
> >
> > Then the xhci must make sure that it should not ring the doorbell to
> > restart the endpoint when giving back the canceled URBs. It should only
> > do so on newly submitted URBs.
>
> Ignore this comment, it's not restarting the endpoint in the case of
> unlinking.
I was going to say that xhci-hcd shouldn't restart the endpoint until
the usb_reset_endpoint() call is made. Whether or not it rings the
doorbell at that time may depend on whether there are any URBs on the
queue; that's a relatively unimportant implementation detail.
> > We can add a requirement such that if the class driver submitted the
> > recovery URBs prior to completing the usb_reset_endpoint (which should
> > be done after clear-halt), then the HCD may keep those URBs on a queue
> > and only process those URBs and restart the endpoint afterward.
> >
>
> Actually, adding this new requirement would be tricky because we don't
> know whether it's recovery URBs or not.
The purpose of the submitted URBs doesn't matter. The HCD shouldn't
restart the endpoint until the usb_reset_endpoint() call occurs.
Also, I should point out that usbcore will call usb_clear_halt() and
usb_reset_endpoint(), presumably using a work queue for the calls. The
class driver doesn't need to do it -- in fact, doing those things could
lead to errors because the endpoint may already be running (the core may
already have made the calls).
Alan Stern
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-04 22:28 UTC (permalink / raw)
To: Alan Stern
Cc: Mathias Nyman, linux-usb@vger.kernel.org, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <20260404221533.woepax7jxwefy3fq@synopsys.com>
On Sat, Apr 04, 2026, Thinh Nguyen wrote:
> On Sat, Apr 04, 2026, Alan Stern wrote:
> > On Sat, Apr 04, 2026 at 08:41:36PM +0000, Thinh Nguyen wrote:
> > > On Fri, Apr 03, 2026, stern@rowland.harvard.edu wrote:
> > > > Summarizing:
> > > >
> > > > If the class driver wants to unlink queued URBs when a transaction error
> > > > occurs, it has to do so itself in the failed URB's completion handler.
> > > > We can make this easier by adding a usb_flush_endpoint_queue() routine
> > > > to the core. In the meantime, the HCD ensures that the queue is stopped
> > > > before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
> > > > -EREMOTEIO aren't considered to be transaction errors.)
> > > >
> > > > When the completion handler returns, the core will automatically call
> > > > usb_clear_halt(), which will also reset the endpoint on the host side
> > > > and will restart the queue. This also happens after SetConfiguration
> > > > and SetInterface, either explicitly or implicitly.
> > >
> > > I like that the core will handle this automatically. But one concern:
> > > How will the class driver know when the clear-halt complete so it can
> > > perform the recovery? (ie. it shouldn't perform recovery immediately
> > > after seeing -EPROTO)
> >
> > It doesn't know, and it doesn't need to know. Any recovery URBs the
> > class driver wants to send can be submitted as usual, and they will be
> > added onto the queue. When the core resets the endpoint, the queue will
> > start going again and the URBs will run.
> >
> > If the class driver wants to take some other action (like submitting
> > URBs to a different endpoint) before using the endpoint that stopped,
> > it's free to do so. It only has to make sure that it doesn't submit any
> > URBs to the stopped endpoint until after the other action is finished --
> > which is what it would do anyway. (And maybe it has to unlink any URBs
> > that are already queued, which can be done with a simple function call.)
> >
>
> Then the xhci must make sure that it should not ring the doorbell to
> restart the endpoint when giving back the canceled URBs. It should only
> do so on newly submitted URBs.
Ignore this comment, it's not restarting the endpoint in the case of
unlinking.
>
> We can add a requirement such that if the class driver submitted the
> recovery URBs prior to completing the usb_reset_endpoint (which should
> be done after clear-halt), then the HCD may keep those URBs on a queue
> and only process those URBs and restart the endpoint afterward.
>
Actually, adding this new requirement would be tricky because we don't
know whether it's recovery URBs or not.
BR,
Thinh
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-04 22:15 UTC (permalink / raw)
To: Alan Stern
Cc: Thinh Nguyen, Mathias Nyman, linux-usb@vger.kernel.org,
michal.pecio@gmail.com, oneukum@suse.com,
niklas.neronin@linux.intel.com
In-Reply-To: <243af5f2-3925-4960-be7b-8d0c273ae629@rowland.harvard.edu>
On Sat, Apr 04, 2026, Alan Stern wrote:
> On Sat, Apr 04, 2026 at 08:41:36PM +0000, Thinh Nguyen wrote:
> > On Fri, Apr 03, 2026, stern@rowland.harvard.edu wrote:
> > > Summarizing:
> > >
> > > If the class driver wants to unlink queued URBs when a transaction error
> > > occurs, it has to do so itself in the failed URB's completion handler.
> > > We can make this easier by adding a usb_flush_endpoint_queue() routine
> > > to the core. In the meantime, the HCD ensures that the queue is stopped
> > > before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
> > > -EREMOTEIO aren't considered to be transaction errors.)
> > >
> > > When the completion handler returns, the core will automatically call
> > > usb_clear_halt(), which will also reset the endpoint on the host side
> > > and will restart the queue. This also happens after SetConfiguration
> > > and SetInterface, either explicitly or implicitly.
> >
> > I like that the core will handle this automatically. But one concern:
> > How will the class driver know when the clear-halt complete so it can
> > perform the recovery? (ie. it shouldn't perform recovery immediately
> > after seeing -EPROTO)
>
> It doesn't know, and it doesn't need to know. Any recovery URBs the
> class driver wants to send can be submitted as usual, and they will be
> added onto the queue. When the core resets the endpoint, the queue will
> start going again and the URBs will run.
>
> If the class driver wants to take some other action (like submitting
> URBs to a different endpoint) before using the endpoint that stopped,
> it's free to do so. It only has to make sure that it doesn't submit any
> URBs to the stopped endpoint until after the other action is finished --
> which is what it would do anyway. (And maybe it has to unlink any URBs
> that are already queued, which can be done with a simple function call.)
>
Then the xhci must make sure that it should not ring the doorbell to
restart the endpoint when giving back the canceled URBs. It should only
do so on newly submitted URBs.
We can add a requirement such that if the class driver submitted the
recovery URBs prior to completing the usb_reset_endpoint (which should
be done after clear-halt), then the HCD may keep those URBs on a queue
and only process those URBs and restart the endpoint afterward.
BR,
Thinh
> > > For -EPIPE (device sent a STALL token), the class driver has to clear
> > > the halt itself. This is because stalls aren't errors; they are an
> > > intentional part of the USB protocol.
> > >
> > > -ENOENT and -ECONNRESET (URB was unlinked) and -EREMOTEIO (short packet
> > > received with URB_SHORT_NOT_OK set) are a little trickier. The HCD may
> > > or may not need to stop the queue for an unlink, possibly depending on
> > > whether the URB being unlinked is the active one. When a short packet
> > > is received, the HC hardware may or may not stop its queue. Either way,
> > > the class driver shouldn't need to take any special recovery action; any
> > > necessary actions should be taken automatically by the HCD and the core.
> > >
> > > All of this applies only to bulk and interrupt endpoints. Control
> > > endpoints generally need error recovery only on the host side, because
> > > the device resets automatically when it gets a new SETUP packet, and so
> > > the HCD should handle whatever is needed. Isochronous endpoints don't
> > > ever halt and they shouldn't need to be reset when an error occurs.
> > >
> > > Overall, this seems simpler than anything else we have discussed.
> > >
> >
> > The rest sounds good to me!
>
> Good! Let's wait to hear from Michal, Mathias, and Oliver.
>
> Alan
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Alan Stern @ 2026-04-04 21:54 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Mathias Nyman, linux-usb@vger.kernel.org, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <20260404204133.3mcizeeokw3ln5r4@synopsys.com>
On Sat, Apr 04, 2026 at 08:41:36PM +0000, Thinh Nguyen wrote:
> On Fri, Apr 03, 2026, stern@rowland.harvard.edu wrote:
> > Summarizing:
> >
> > If the class driver wants to unlink queued URBs when a transaction error
> > occurs, it has to do so itself in the failed URB's completion handler.
> > We can make this easier by adding a usb_flush_endpoint_queue() routine
> > to the core. In the meantime, the HCD ensures that the queue is stopped
> > before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
> > -EREMOTEIO aren't considered to be transaction errors.)
> >
> > When the completion handler returns, the core will automatically call
> > usb_clear_halt(), which will also reset the endpoint on the host side
> > and will restart the queue. This also happens after SetConfiguration
> > and SetInterface, either explicitly or implicitly.
>
> I like that the core will handle this automatically. But one concern:
> How will the class driver know when the clear-halt complete so it can
> perform the recovery? (ie. it shouldn't perform recovery immediately
> after seeing -EPROTO)
It doesn't know, and it doesn't need to know. Any recovery URBs the
class driver wants to send can be submitted as usual, and they will be
added onto the queue. When the core resets the endpoint, the queue will
start going again and the URBs will run.
If the class driver wants to take some other action (like submitting
URBs to a different endpoint) before using the endpoint that stopped,
it's free to do so. It only has to make sure that it doesn't submit any
URBs to the stopped endpoint until after the other action is finished --
which is what it would do anyway. (And maybe it has to unlink any URBs
that are already queued, which can be done with a simple function call.)
> > For -EPIPE (device sent a STALL token), the class driver has to clear
> > the halt itself. This is because stalls aren't errors; they are an
> > intentional part of the USB protocol.
> >
> > -ENOENT and -ECONNRESET (URB was unlinked) and -EREMOTEIO (short packet
> > received with URB_SHORT_NOT_OK set) are a little trickier. The HCD may
> > or may not need to stop the queue for an unlink, possibly depending on
> > whether the URB being unlinked is the active one. When a short packet
> > is received, the HC hardware may or may not stop its queue. Either way,
> > the class driver shouldn't need to take any special recovery action; any
> > necessary actions should be taken automatically by the HCD and the core.
> >
> > All of this applies only to bulk and interrupt endpoints. Control
> > endpoints generally need error recovery only on the host side, because
> > the device resets automatically when it gets a new SETUP packet, and so
> > the HCD should handle whatever is needed. Isochronous endpoints don't
> > ever halt and they shouldn't need to be reset when an error occurs.
> >
> > Overall, this seems simpler than anything else we have discussed.
> >
>
> The rest sounds good to me!
Good! Let's wait to hear from Michal, Mathias, and Oliver.
Alan
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 21:02 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #7 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #6)
> The Thunderbolt log contains two controllers: Intel (0000:00:14.0) and
> ASMedia (0000:0a:00.0). The Intel slot 2 ep 2 stalls that repeat every two
> seconds or so throughout the log are from a different device
Unrelated, though a little odd. Can you check what's making this noise?
cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
> The ASMedia side is where things go wrong. During each enumeration attempt
> of the mouse (slot 3), ep 0 stalls repeatedly while the device is being
> configured. That part eventually completes and the mouse is recognized.
Same thing on the good bus. EP 0 stall is just some control request unsupported
by the device. More interesting is interrupt endpoint 0x81 aka "ep 2".
But little happens here. The initial Stopped events on ep 2 and 4 are probably
xhci_endpoint_reset(), then EP 0 stalls twice more and then usbhid cancels some
URB from the interrupt endpoint.
Does this cancellation go away when you enable the udev rule or ALWAYS_POLL?
Maybe something goes wrong here.
Then there is nothing, which means that URBs are completing successfully or not
at all (as the mouse doesn't work, probably the latter). At some point
disconnection and cancellation again, which proves that there was some URB on
the endpoint at the time.
> But then this appears:
> > xhci_hcd 0000:0a:00.0: Split transaction error for slot 3 ep 2
> > xhci_hcd 0000:0a:00.0: Hard-reset ep 2, slot 3
>
> Shortly after, the mouse disconnects:
> > usb 3-1.1: USB disconnect, device number 5
I/O errors aren't entirely uncommon when a device disconnects. Does it mean
that the device kept disconnecting by itself and it wasn't you doing it?
Do you have some other USB 2.0/3.0 hub you could put between the monitor and
the mouse? Does it make any difference?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-04 20:41 UTC (permalink / raw)
To: stern@rowland.harvard.edu
Cc: Thinh Nguyen, Mathias Nyman, linux-usb@vger.kernel.org,
michal.pecio@gmail.com, oneukum@suse.com,
niklas.neronin@linux.intel.com
In-Reply-To: <616e2a64-6feb-4ee6-bf39-a6284549f18f@rowland.harvard.edu>
On Fri, Apr 03, 2026, stern@rowland.harvard.edu wrote:
> On Sat, Apr 04, 2026 at 01:15:52AM +0000, Thinh Nguyen wrote:
> > > > How about this:
> > > >
> > > > Introduce a halted flag the following conditions:
> > > >
> > > > * Introduce the halted flag in usb_host_endpoint
> > > > * The halted flag must be implemented as a bit in a unsigned long so
> > > > we can use atomic bit operation
> > >
> > > I don't see why it needs to use atomic operations. Unless you're
> > > thinking that we might want to add other bitflags into the same unsigned
> > > long?
> >
> > Now that I think about it again, it's not needed if we have the
> > requirement for clearing the flag only after usb_reset_endpoint.
> >
> > >
> > > > * Only the HCD may set the halted flag, and only upon checking the
> > > > first URB completing with a halted status
> > >
> > > Every status other than 0 should mean that the endpoint's queue is
> > > halted. But not all statuses require a clear-halt or reset-endpoint to
> > > recover. For instance, a short transfer when the URB_SHORT_NOT_OK flag
> > > is set.
> >
> > It seems we're using the "halted" flag for different things. The halted
> > flag to me is the endpoint's state and rather than the endpoint queue
> > state. That is, if the endpoint is halted, there's an error that was
> > reported on the pipe. So, an -ECONNRESET would not cause a halted
> > endpoint.
> >
> > >
> > > Why do you want the HCD to set the flag instead of
> > > usb_hcd_giveback_urb()? Just one central place is simpler than in every
> > > HCD.
> >
> > I'm just thinking in term of whose role to return the pending URBs.
> > Typically the HCD handles when to give back URBs. If the HCD were to
> > handle giving back pending URBs due to halted endpoint, then it should
> > be the one to set the halted flag. However, if the core tracks and does
> > both setting and clearing of the halted flag, then the core should
> > handle canceling the URBs. As you said, if we can shift the burden to
> > the core, that would help keep the flow consistent and centralized.
> >
> > >
> > > > * Only the USB core may clear the halted flag, and only after
> > > > usb_reset_endpoint returns (this makes sure the HCD drained and reset
> > > > the endpoint before the flag is cleared and new URBs are accepted)
> > > > * The usb_reset_endpoint must be called after clear-halt, SetInterface,
> > > > and SetConfiguration.
> > >
> > > That's easy to do just by adding it into the appropriate core routines.
> >
> > Yes.
> >
> > >
> > > > * The USB core will not attempt to unlink pending URBs due to halted
> > > > condition
> > > > * The HCD is responsible for completing or canceling queued URBs
> > > > when the halted flag is set. Cancelled and newly submitted URBs will
> > > > be returned with -EPIPE as long as the halted flag is set
> > >
> > > Why make the HCD responsible for draining the queue? It's like setting
> > > the halted flag; one central place is simpler and less error-prone than
> > > lots of separate places.
> > >
> > > For newly submitted URBs, should the submission fail with -EPIPE, or
> > > should the submission succeed and then the URB complete with -EPIPE?
> > > The first is simpler, but drivers probably aren't prepared for it -- it
> > > would mean adding error handling to the submission code as well as to
> > > the completion handler code.
> > >
> > > (Actually, that wouldn't matter unless the driver was queuing up
> > > multiple URBs, in which case it should be prepared to handle submission
> > > errors in the middle.)
> >
> > I didn't think about failing immediately on submission because we would
> > need to audit every class driver for that. Perhaps the core can
> > intercept the URBs and immediately schedule a completion handler with
> > the updated URB's status?
> >
> > >
> > > > * The class driver is responsible to check the halted flag to
> > > > determine whether to initiate error recovery via usb_clear_halt
> > > >
> > > > I'm trying to keep a clear separation of responsibilities between HCD
> > > > and the USB core. Also, I try to keep the halted flag more closely match
> > > > the state of the endpoint.
> > > >
> > > > Let me know what you think?
> > >
> > > Making the flag match the endpoint state is a good idea. But there is
> > > some ambiguity: Do you mean the state in the device, or the state in the
> > > HC hardware, or the state in the HCD? After all, these aren't always
> > > the same. For instance, unlinking an URB won't affect the device's
> > > state but it will affect the state on the host side.
> > >
> >
> > The HCD state. If we can let the core manage the halted state, then here
> > are the points where the halted state is updated (hopefully I didn't
> > miss any other ones):
> >
> > Endpoint is halted (reported by HCD):
> > * URB returned with -EPROTO or -EPIPE
> >
> > Endpoint is active (updated by the core):
> > * SetConfiguration, SetInterface, clear-halt
>
> Hmmm. What did you think of my recent proposal in a message to Michal?
> Summarizing:
>
> If the class driver wants to unlink queued URBs when a transaction error
> occurs, it has to do so itself in the failed URB's completion handler.
> We can make this easier by adding a usb_flush_endpoint_queue() routine
> to the core. In the meantime, the HCD ensures that the queue is stopped
> before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
> -EREMOTEIO aren't considered to be transaction errors.)
>
> When the completion handler returns, the core will automatically call
> usb_clear_halt(), which will also reset the endpoint on the host side
> and will restart the queue. This also happens after SetConfiguration
> and SetInterface, either explicitly or implicitly.
I like that the core will handle this automatically. But one concern:
How will the class driver know when the clear-halt complete so it can
perform the recovery? (ie. it shouldn't perform recovery immediately
after seeing -EPROTO)
>
> For -EPIPE (device sent a STALL token), the class driver has to clear
> the halt itself. This is because stalls aren't errors; they are an
> intentional part of the USB protocol.
>
> -ENOENT and -ECONNRESET (URB was unlinked) and -EREMOTEIO (short packet
> received with URB_SHORT_NOT_OK set) are a little trickier. The HCD may
> or may not need to stop the queue for an unlink, possibly depending on
> whether the URB being unlinked is the active one. When a short packet
> is received, the HC hardware may or may not stop its queue. Either way,
> the class driver shouldn't need to take any special recovery action; any
> necessary actions should be taken automatically by the HCD and the core.
>
> All of this applies only to bulk and interrupt endpoints. Control
> endpoints generally need error recovery only on the host side, because
> the device resets automatically when it gets a new SETUP packet, and so
> the HCD should handle whatever is needed. Isochronous endpoints don't
> ever halt and they shouldn't need to be reset when an error occurs.
>
> Overall, this seems simpler than anything else we have discussed.
>
The rest sounds good to me!
Thanks Alan,
Thinh
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 17:39 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #6 from manauer.uel@gmail.com ---
Thanks for the hint! You are right, the ASM1042A is the host controller. The
actual hub inside the monitor is 043e:9a10 I think, and it shows up in both
connection variants. The difference is just which xHCI controller ends up
hosting it.
The Thunderbolt log contains two controllers: Intel (0000:00:14.0) and ASMedia
(0000:0a:00.0). The Intel slot 2 ep 2 stalls that repeat every two seconds or
so throughout the log are from a different device (i think) and are not related
to the mouse. The same stall pattern appears in the USB-only log as well.
The ASMedia side is where things go wrong. During each enumeration attempt of
the mouse (slot 3), ep 0 stalls repeatedly while the device is being
configured. That part eventually completes and the mouse is recognized. But
then this appears:
> xhci_hcd 0000:0a:00.0: Split transaction error for slot 3 ep 2
> xhci_hcd 0000:0a:00.0: Hard-reset ep 2, slot 3
Shortly after, the mouse disconnects:
> usb 3-1.1: USB disconnect, device number 5
It then re-enumerates, and the same cycle starts over.
The split transaction error message is maybe the thing we are hunting for,
since split transactions are the mechanism the hubs Transaction Translator uses
to bridge full-speed traffic to the high-speed controller, right?. I do not
know enough about xhci_hcd to say whether this means the TT itself is failing
or whether the ASMedia controller is mishandling the response. But it seems
worth looking at.
For completeness, the USB log shows no disconnect or split transaction errors
for the mouse. The stalls on slot 2 ep 2 that are present in that log are the
same unrelated device I think.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 17:35 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #5 from manauer.uel@gmail.com ---
Created attachment 309818
--> https://bugzilla.kernel.org/attachment.cgi?id=309818&action=edit
dmesg -W with connection through USB
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 17:34 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #4 from manauer.uel@gmail.com ---
Created attachment 309817
--> https://bugzilla.kernel.org/attachment.cgi?id=309817&action=edit
dmesg -W with connection through Thunderbolt 2
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 17:33 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #3 from manauer.uel@gmail.com ---
Created attachment 309816
--> https://bugzilla.kernel.org/attachment.cgi?id=309816&action=edit
lsusb -tv with monitor connected via Thunderbolt 2
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 17:32 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #2 from manauer.uel@gmail.com ---
Created attachment 309815
--> https://bugzilla.kernel.org/attachment.cgi?id=309815&action=edit
lsusb -tv with monitor connected via USB
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Rafael J. Wysocki @ 2026-04-04 17:11 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Saravana Kannan, Christoph Hellwig, Eric Dumazet,
Johan Hovold, Leon Romanovsky, Alexander Lobakin,
Alexey Kardashevskiy, Robin Murphy, Andrew Morton, Frank.Li,
Jason Gunthorpe, alex, alexander.stein, andre.przywara, andrew,
andrew, andriy.shevchenko, aou, ardb, bhelgaas, brgl, broonie,
catalin.marinas, chleroy, davem, david, devicetree, dmaengine,
driver-core, gbatra, gregory.clement, hkallweit1, iommu,
jirislaby, joel, joro, kees, kevin.brodsky, kuba, lenb, lgirdwood,
linux-acpi, linux-arm-kernel, linux-aspeed, linux-cxl,
linux-kernel, linux-mips, linux-mm, linux-pci, linux-riscv,
linux-serial, linux-snps-arc, linux-usb, linux, linuxppc-dev,
m.szyprowski, maddy, mani, maz, miko.lenczewski, mpe, netdev,
npiggin, osalvador, oupton, pabeni, palmer, peter.ujfalusi,
peterz, pjw, robh, sebastian.hesselbarth, tglx, tsbogend, vgupta,
vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>
On Sat, Apr 4, 2026 at 2:07 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> The main goal of this series is to fix the observed bug talked about
> in the first patch ("driver core: Don't let a device probe until it's
> ready"). That patch fixes a problem that has been observed in the real
> world and could land even if the rest of the patches are found
> unacceptable or need to be spun.
>
> That said, during patch review Danilo correctly pointed out that many
> of the bitfield accesses in "struct device" are unsafe. I added a
> bunch of patches in the series to address each one.
>
> Danilo said he's most worried about "can_match", so I put that one
> first. After that, I tried to transition bitfields to flags in reverse
> order to when the bitfield was added.
>
> Even if transitioning from bitfields to flags isn't truly needed for
> correctness, it seems silly (and wasteful of space in struct device)
> to have some in bitfields and some as flags. Thus I didn't spend time
> for each bitfield showing that it's truly needed for correctness.
>
> Transition was done semi manually. Presumably someone skilled at
> coccinelle could do a better job, but I just used sed in a heavy-
> handed manner and then reviewed/fixed the results, undoing anything my
> script got wrong. My terrible/ugly script was:
>
> var=can_match
> caps="${var^^}"
> for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
> echo $f
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
> done
>
> From v3 to v4, I transitioned to accessor functions with another ugly
> sed script. I had git format the old patches, then transformed them
> with:
>
> for f in *.patch; do
> echo $f
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> done
>
> ...and then did a few manual touchups for spacing.
>
> NOTE: one potentially "controversial" choice I made in some patches
> was to always reserve a flag ID even if a flag is only used under
> certain CONFIG_ settings. This is a change from how things were
> before. Keeping the numbering consistent and allowing easy
> compile-testing of both CONFIG settings seemed worth it, especially
> since it won't take up any extra space until we've added a lot more
> flags.
>
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - Use a new "flags" bitfield
> - Add missing \n in probe error message
>
> Changes in v2:
> - Instead of adjusting the ordering, use "ready_to_probe" flag
>
> Douglas Anderson (9):
> driver core: Don't let a device probe until it's ready
> driver core: Replace dev->can_match with dev_can_match()
> driver core: Replace dev->dma_iommu with dev_dma_iommu()
> driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
> driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
> driver core: Replace dev->state_synced with dev_state_synced()
> driver core: Replace dev->dma_coherent with dev_dma_coherent()
> driver core: Replace dev->of_node_reused with dev_of_node_reused()
> driver core: Replace dev->offline + ->offline_disabled with accessors
>
> arch/arc/mm/dma.c | 4 +-
> arch/arm/mach-highbank/highbank.c | 2 +-
> arch/arm/mach-mvebu/coherency.c | 2 +-
> arch/arm/mm/dma-mapping-nommu.c | 4 +-
> arch/arm/mm/dma-mapping.c | 28 ++--
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/mm/dma-mapping.c | 2 +-
> arch/mips/mm/dma-noncoherent.c | 2 +-
> arch/powerpc/kernel/dma-iommu.c | 8 +-
> .../platforms/pseries/hotplug-memory.c | 4 +-
> arch/riscv/mm/dma-noncoherent.c | 2 +-
> drivers/acpi/scan.c | 2 +-
> drivers/base/core.c | 53 +++++---
> drivers/base/cpu.c | 4 +-
> drivers/base/dd.c | 28 ++--
> drivers/base/memory.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/dma/ti/k3-udma-glue.c | 6 +-
> drivers/dma/ti/k3-udma.c | 6 +-
> drivers/iommu/dma-iommu.c | 9 +-
> drivers/iommu/iommu.c | 5 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +-
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 120 ++++++++++++------
> include/linux/dma-map-ops.h | 6 +-
> include/linux/dma-mapping.h | 2 +-
> include/linux/iommu-dma.h | 3 +-
> kernel/cpu.c | 4 +-
> kernel/dma/mapping.c | 12 +-
> mm/hmm.c | 2 +-
> 37 files changed, 206 insertions(+), 142 deletions(-)
>
> --
For the whole set
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox