From: "Michał Pecio" <michal.pecio@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: How are halted endpoints supposed to be handled in Linux?
Date: Sat, 23 Nov 2024 00:25:35 +0100 [thread overview]
Message-ID: <20241123002535.368f1d72@foxbook> (raw)
In-Reply-To: <eb3bae13-dd89-4c84-a4c9-4fb49348928c@rowland.harvard.edu>
On Fri, 22 Nov 2024 14:28:58 -0500, Alan Stern wrote:
> Bypassing the BH might not be a good idea, because driver's
> completion handlers expect to be called in order of URB completion.
> It probably wouldn't make any difference, but it's hard to be sure.
Valid point. Expecting drivers to deal with reordered completions would
be quite unintuitive, potentially laborious and bug-prone.
> > > Note that some class drivers treat -EPROTO as a fatal error. That
> > > is, they don't retry and their completion-resubmission loop breaks
> > > down.
> >
> > Well, that's on EHCI.
>
> No, it's the behavior of the class driver and is independent of the
> type of host controller.
xHCI has been doing things differently for over a decade as far as I
see, and it seems to implement the usb_unlink_urb() rules absolutely
literally (restart when everything is given back), except for the BH
delay problem added later.
Maybe it was a common "idiom" before xHCI, but it seems to rely on
undocumented behavior, and other undocumented behaviors exist today
that sloppy drivers might depend on.
So I don't know, it seems risky either way.
Regards,
Michal
next prev parent reply other threads:[~2024-11-22 23:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 23:11 How are halted endpoints supposed to be handled in Linux? Michał Pecio
2024-11-21 0:02 ` Thinh Nguyen
2024-11-21 2:31 ` Alan Stern
2024-11-21 10:26 ` Michał Pecio
2024-11-21 14:08 ` Mathias Nyman
2024-11-22 11:54 ` Michał Pecio
2024-11-21 15:06 ` Alan Stern
2024-11-22 12:57 ` Michał Pecio
2024-11-22 19:28 ` Alan Stern
2024-11-22 23:25 ` Michał Pecio [this message]
2024-11-23 2:39 ` 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=20241123002535.368f1d72@foxbook \
--to=michal.pecio@gmail.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.