From: Alan Stern <stern@rowland.harvard.edu>
To: Dan Scally <dan.scally@ideasonboard.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
rogerq@kernel.org
Subject: Re: Explicit status phase for DWC3
Date: Thu, 2 Feb 2023 09:52:36 -0500 [thread overview]
Message-ID: <Y9vONL8ZyQdEVkr0@rowland.harvard.edu> (raw)
In-Reply-To: <43b077ad-c8cd-bb49-134d-1bd66bed0b84@ideasonboard.com>
On Thu, Feb 02, 2023 at 10:12:45AM +0000, Dan Scally wrote:
> (+CC roger as the author of the USB_GADGET_DELAYED_STATUS mechanism)
>
> On 26/01/2023 23:57, Thinh Nguyen wrote:
> > We should already have this mechanism in place to do protocol STALL.
> > Please look into delayed_status and set halt.
>
>
> Thanks; I tried this by returning USB_GADGET_DELAYED_STATUS from the
> function's .setup() callback and later (after userspace checks the data
> packet) either calling usb_ep_queue() or usb_ep_set_halt() and it does seem
> to be working. This surprises me, as my understanding was that the purpose
> of USB_GADGET_DELAYED_STATUS is to pause all control transfers including
> the data phase to give the function driver enough time to queue a request
> (and possibly only for specific requests). Regardless though I think the
> conclusion from previous discussions on this topic (see [1] for example) was
> that we don't want to rely on USB_GADGET_DELAYED_STATUS to do this which is
> why I had avoided it in the first place. A colleague made a series [2] some
> time ago that adds a flag to usb_request which function drivers can set when
> queuing the data phase request. UDC drivers then read that flag to decide
> whether to delay the status phase until after another usb_ep_queue(), and
> that's what I'm trying to implement here.
>
>
> [1] https://lkml.org/lkml/2018/10/10/138
>
> [2] https://patchwork.kernel.org/project/linux-usb/patch/20190124030228.19840-5-paul.elder@ideasonboard.com/
I'm in favor of the explicit_status approach from [2]. In fact, there
was a whole series of patches impementing this, and I don't think any of
them were merged.
Keep in mind that there are two separate issues here:
Status/data stage for a control-IN or 0-length control-OUT
transfer.
Status stage for a non-0-length control-OUT transfer.
The USB_GADGET_DELAYED_STATUS mechanism was meant to help with the
first, not the second. explicit_status was meant to help with the
second; it may be able to help with both.
Alan Stern
next prev parent reply other threads:[~2023-02-02 14:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 14:27 Explicit status phase for DWC3 Dan Scally
2023-01-26 0:20 ` Thinh Nguyen
2023-01-26 10:30 ` Dan Scally
2023-01-26 19:31 ` Thinh Nguyen
2023-01-26 20:31 ` Alan Stern
2023-01-26 23:57 ` Thinh Nguyen
2023-02-02 10:12 ` Dan Scally
2023-02-02 14:51 ` Roger Quadros
2023-02-02 14:52 ` Alan Stern [this message]
2023-02-02 15:45 ` Dan Scally
2023-02-02 16:37 ` Alan Stern
2023-02-02 19:48 ` Thinh Nguyen
2023-02-02 20:15 ` Alan Stern
2023-04-05 19:35 ` Hans Petter Selasky
2023-02-02 20:01 ` Thinh Nguyen
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=Y9vONL8ZyQdEVkr0@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=Thinh.Nguyen@synopsys.com \
--cc=dan.scally@ideasonboard.com \
--cc=linux-usb@vger.kernel.org \
--cc=rogerq@kernel.org \
/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