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
next prev parent reply other threads:[~2019-01-11 8:43 UTC|newest]
Thread overview: 40+ 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-10 20:39 ` Alan Stern
2019-01-11 8:43 ` Paul Elder [this message]
2019-01-11 18:32 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2019-01-09 7:08 [v5,1/6] usb: uvc: include videodev2.h in g_uvc.h Paul Elder
2019-01-09 7:08 ` [PATCH v5 1/6] " Paul Elder
2019-01-09 7:08 [v5,2/6] usb: gadget: uvc: enqueue usb request in setup handler for control OUT Paul Elder
2019-01-09 7:08 ` [PATCH v5 2/6] " Paul Elder
2019-01-09 7:08 [v5,3/6] usb: gadget: uvc: package setup and data for control OUT requests Paul Elder
2019-01-09 7:08 ` [PATCH v5 3/6] " Paul Elder
2019-01-09 7:08 [v5,4/6] usb: gadget: add mechanism to specify an explicit status stage Paul Elder
2019-01-09 7:08 ` [PATCH v5 4/6] " Paul Elder
2019-01-09 7:08 [v5,5/6] usb: musb: gadget: implement optional " Paul Elder
2019-01-09 7:08 ` [PATCH v5 5/6] " Paul Elder
2019-01-09 7:08 [v5,6/6] usb: gadget: uvc: allow ioctl to send response in " Paul Elder
2019-01-09 7:08 ` [PATCH v5 6/6] " Paul Elder
2019-01-09 19:06 [v5,4/6] usb: gadget: add mechanism to specify an explicit " Alan Stern
2019-01-09 19:06 ` [PATCH v5 4/6] " Alan Stern
2019-01-11 8:23 [v5,4/6] " Paul Elder
2019-01-11 8:23 ` [PATCH v5 4/6] " Paul Elder
2019-01-11 15:50 [v5,4/6] " Alan Stern
2019-01-11 15:50 ` [PATCH v5 4/6] " Alan Stern
2019-01-14 5:11 [v5,4/6] " Paul Elder
2019-01-14 5:11 ` [PATCH v5 4/6] " Paul Elder
2019-01-14 15:24 [v5,4/6] " Alan Stern
2019-01-14 15:24 ` [PATCH v5 4/6] " Alan Stern
2019-01-16 5:00 [v5,4/6] " Paul Elder
2019-01-16 5:00 ` [PATCH v5 4/6] " Paul Elder
2019-01-16 15:06 [v5,4/6] " Alan Stern
2019-01-16 15:06 ` [PATCH v5 4/6] " Alan Stern
2019-01-18 16:31 [v5,4/6] " Paul Elder
2019-01-18 16:31 ` [PATCH v5 4/6] " Paul Elder
2019-01-18 16:52 [v5,4/6] " Alan Stern
2019-01-18 16:52 ` [PATCH v5 4/6] " Alan Stern
2019-01-20 17:59 [v5,4/6] " Paul Elder
2019-01-20 17:59 ` [PATCH v5 4/6] " Paul Elder
2019-01-23 21:10 [v5,4/6] " Alan Stern
2019-01-23 21:10 ` [PATCH v5 4/6] " Alan Stern
2019-01-24 2:48 [v5,4/6] " Paul Elder
2019-01-24 2:48 ` [PATCH v5 4/6] " Paul Elder
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 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.