Re: Explicit status phase for DWC3

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Thu, Jan 26, 2023, Dan Scally wrote:
> 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?
> 

My concern is from the documentation note[*] added from this commit:
579c2b46f74 ("USB Gadget: documentation update")

It should be fine with dwc3 controllers. Did you look into
delayed_status?

BR,
Thinh

[*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/udc/core.c#n255