From: Dan Scally <dan.scally@ideasonboard.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: Explicit status phase for DWC3
Date: Thu, 26 Jan 2023 10:30:20 +0000 [thread overview]
Message-ID: <dda24f8e-8d74-c6c1-ae7c-e423bc50a143@ideasonboard.com> (raw)
In-Reply-To: <20230126002017.tbxc3j6xdgplncfs@synopsys.com>
Hi Thinh
On 26/01/2023 00:20, Thinh Nguyen wrote:
> On Tue, Jan 24, 2023, Dan Scally wrote:
>> Hi Thinh
>>
>>
>> I'm trying to update the DWC3 driver to allow the status phase of a
>> transaction to be explicit; meaning the gadget driver has the choice to
>> either Ack or Stall _after_ the data phase so that the contents of the data
>> phase can be validated. I thought that I should be able to achieve this by
>> preventing dwc3_ep0_xfernotready() from calling dwc3_ep0_do_control_status()
>> (relying on an "explicit_status" flag added to the usb_request to decide
>> whether or not to do so) and then calling it manually later once the data
>> phase was validated by the gadget driver (or indeed userspace). A very
>> barebones version of my attempt to do that looks like this:
>>
> We shouldn't do this. At the protocol level, there must be better ways
> to do handshake than relying on protocol STALL _after_ the data stage.
> Note that not all controllers support this.
Maybe I'm misunderstanding, but isn't this how the USB spec expects it
to work? Reading "Reporting Status Results (8.5.3.1)" in the USB 2.0
spec for the status stage in a control write it says "The function
responds with either a handshake or a zero-length data packet to
indicate its current status", and the handshake can be either STALL or
NAK. If we can't do this, how else can we indicate to the host that the
data sent during a control out transfer is in some way invalid?
Thanks
Dan
>
> Thanks,
> Thinh
next prev parent reply other threads:[~2023-01-26 10:30 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 [this message]
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
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=dda24f8e-8d74-c6c1-ae7c-e423bc50a143@ideasonboard.com \
--to=dan.scally@ideasonboard.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=linux-usb@vger.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