linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Elder <paul.elder@ideasonboard.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: laurent.pinchart@ideasonboard.com,
	kieran.bingham@ideasonboard.com, b-liu@ti.com, rogerq@ti.com,
	balbi@kernel.org, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/6] usb: gadget: add mechanism to asynchronously validate data stage of ctrl out request
Date: Fri, 11 Jan 2019 03:43:46 -0500	[thread overview]
Message-ID: <20190111084346.GC32268@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1901101520090.1206-100000@iolanthe.rowland.org>

On Thu, Jan 10, 2019 at 03:39:25PM -0500, Alan Stern wrote:
> On Wed, 9 Jan 2019, Paul Elder wrote:
> 
> > This patch series adds a mechanism to allow asynchronously validating
> > the data stage of a control OUT request, and for stalling or suceeding
> > the request accordingly.
> 
> One thing we haven't mentioned explicitly: What should happen when the 
> time for the status stage rolls around if the gadget driver queues a 
> non-zero length request?

Ah, yeah, I missed that.

> This can happen in a few different ways.  One obvious possibility is
> that the gadget driver sets the explicit_status flag and then submits a
> non-zero length request.  Another is that the gadget driver submits
> _two_ requests during the data stage (the second would be interpreted
> as the status-stage request).  A third is that the gadget driver
> submits a data-stage request that is too long and the excess portion is
> used for the status stage.
> 
> My feeling is that the behavior in these cases should officially be
> undefined.  Almost anything could happen: the status stage could STALL,
> it could succeed, it could NAK, or it could send a non-zero packet to
> the host.  The request could return with 0 status or an error status,
> and req->actual could take on any reasonable value.
> 
> Alternatively, the UDC driver could detect these errors and report them 
> somehow.  Maybe STALL the status stage and complete the request with 
> -EPIPE status or some such thing.
> 
> Any preferences or other ideas?

I think error detection and reporting would be useful. The question is
what action to take after that; either leave it undefined or STALL. I
think STALL would be fine, since if a non-zero length request is
submitted for a status stage, intentionally or not, it isn't part of
proper behavior and should count as an error.

> One other thing: Some UDC drivers may assume that the data stage of a 
> control transfer never spans more than a single usb_request.  Should 
> this become an official requirement?

Would the data stage of a control transfer ever need more space than a
single usb_request can contain? I know UVC doesn't; that's why we pack
it together with the setup stage data in 3/6. If so, I would think we
can make it a requirement.


Paul

  reply	other threads:[~2019-01-11  8:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09  7:08 [PATCH v5 0/6] usb: gadget: add mechanism to asynchronously validate data stage of ctrl out request Paul Elder
2019-01-09  7:08 ` [PATCH v5 1/6] usb: uvc: include videodev2.h in g_uvc.h Paul Elder
2019-01-09  7:08 ` [PATCH v5 2/6] usb: gadget: uvc: enqueue usb request in setup handler for control OUT Paul Elder
2019-01-09  7:08 ` [PATCH v5 3/6] usb: gadget: uvc: package setup and data for control OUT requests Paul Elder
2019-01-09  7:08 ` [PATCH v5 4/6] usb: gadget: add mechanism to specify an explicit status stage Paul Elder
2019-01-09 19:06   ` Alan Stern
2019-01-11  8:23     ` Paul Elder
2019-01-11 15:50       ` Alan Stern
2019-01-14  5:11         ` Paul Elder
2019-01-14 15:24           ` Alan Stern
2019-01-16  5:00             ` Paul Elder
2019-01-16 15:06               ` Alan Stern
2019-01-18 16:31                 ` Paul Elder
2019-01-18 16:52                   ` Alan Stern
2019-01-20 17:59                     ` Paul Elder
2019-01-23 21:10           ` Alan Stern
2019-01-24  2:48             ` Paul Elder
2019-01-09  7:08 ` [PATCH v5 5/6] usb: musb: gadget: implement optional " Paul Elder
2019-01-09  7:08 ` [PATCH v5 6/6] usb: gadget: uvc: allow ioctl to send response in " Paul Elder
2019-01-10 20:39 ` [PATCH v5 0/6] usb: gadget: add mechanism to asynchronously validate data stage of ctrl out request Alan Stern
2019-01-11  8:43   ` Paul Elder [this message]
2019-01-11 18:32     ` 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=20190111084346.GC32268@localhost.localdomain \
    --to=paul.elder@ideasonboard.com \
    --cc=b-liu@ti.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@ti.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;
as well as URLs for NNTP newsgroup(s).