Linux USB
 help / color / mirror / Atom feed
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

  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