From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Alan Stern <stern@rowland.harvard.edu>,
Michal Pecio <michal.pecio@gmail.com>
Cc: "Oliver Neukum" <oneukum@suse.com>,
"Thinh Nguyen" <Thinh.Nguyen@synopsys.com>,
"Bjørn Mork" <bjorn@mork.no>,
"USB list" <linux-usb@vger.kernel.org>
Subject: Re: correctly handling EPROTO
Date: Thu, 19 Mar 2026 10:40:31 +0200 [thread overview]
Message-ID: <903fa309-775c-4562-bbf2-01ef8ac88cc7@linux.intel.com> (raw)
In-Reply-To: <4a35e3dc-620a-4596-9bf3-783865f29e8f@rowland.harvard.edu>
On 3/19/26 03:56, Alan Stern wrote:
> Just to be clear, are you saying there's no way for an xHC to restart a
> (host-side) halted non-SuperSpeed endpoint without setting the toggle
> back to 0?
There is.
A reset endpoint command with a TSP flag (transfer state preserve)
clear the host side halt and preserve the toggle state.
It's used for soft-retry purposes, retrying a transfer after
a transaction error. This is also the only use-case described in xHCI specification.
Unclear what happens if we clear the host side halt, preserving the toggle, and
then ask host to move to the next URB
Could be worth giving people a way to try it out somehow.
Maybe option to enable it via debugfs, maybe a quirk, or event just provide a patch.
See how different xHC hosts behave
-Mathias
next prev parent reply other threads:[~2026-03-19 8:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 13:55 correctly handling EPROTO Oliver Neukum
2026-03-12 14:21 ` Alan Stern
2026-03-12 15:57 ` Oliver Neukum
2026-03-13 7:53 ` Michal Pecio
2026-03-13 10:33 ` Oliver Neukum
2026-03-13 15:28 ` Alan Stern
2026-03-13 22:45 ` Thinh Nguyen
2026-03-14 2:39 ` Alan Stern
2026-03-16 12:58 ` Oliver Neukum
2026-03-16 14:02 ` Alan Stern
2026-03-16 14:47 ` Oliver Neukum
2026-03-16 17:33 ` Alan Stern
2026-03-16 19:32 ` Oliver Neukum
2026-03-17 9:05 ` Mathias Nyman
2026-03-17 14:31 ` Alan Stern
2026-03-17 16:20 ` Oliver Neukum
2026-03-17 18:03 ` Alan Stern
2026-03-18 9:54 ` Oliver Neukum
2026-03-18 17:46 ` Alan Stern
2026-03-18 21:38 ` Michal Pecio
2026-03-18 23:59 ` Thinh Nguyen
2026-03-19 2:07 ` Alan Stern
2026-03-19 23:16 ` Thinh Nguyen
2026-03-20 9:58 ` Michal Pecio
2026-03-20 16:20 ` Alan Stern
2026-03-20 17:49 ` Oliver Neukum
2026-03-21 2:14 ` Thinh Nguyen
2026-03-21 5:54 ` Michal Pecio
2026-03-21 15:58 ` Alan Stern
2026-03-28 21:22 ` Michal Pecio
2026-03-29 1:52 ` Alan Stern
2026-03-29 16:46 ` Michal Pecio
2026-03-30 1:32 ` Alan Stern
2026-03-23 10:26 ` Oliver Neukum
2026-03-24 1:06 ` Thinh Nguyen
2026-03-24 9:28 ` Oliver Neukum
2026-03-24 13:25 ` Alan Stern
2026-03-25 1:44 ` Thinh Nguyen
2026-03-19 1:56 ` Alan Stern
2026-03-19 8:40 ` Mathias Nyman [this message]
2026-03-19 23:34 ` Thinh Nguyen
2026-03-19 8:55 ` Michal Pecio
2026-03-19 14:24 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=903fa309-775c-4562-bbf2-01ef8ac88cc7@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=bjorn@mork.no \
--cc=linux-usb@vger.kernel.org \
--cc=michal.pecio@gmail.com \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox