[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230818032607.prgavrozuq6p4r4x@synopsys.com>
Date: Fri, 18 Aug 2023 03:26:10 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Alan Stern <stern@...land.harvard.edu>
CC: Andrey Konovalov <andreyknvl@...il.com>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
USB list <linux-usb@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: dwc3: unusual handling of setup requests with wLength == 0
On Fri, Aug 18, 2023, Thinh Nguyen wrote:
> On Thu, Aug 17, 2023, Alan Stern wrote:
> > (Another design flaw is that this design doesn't specify what should
> > happen if the UDC receives another SETUP packet from the host before the
> > Status stage completes. By sending another SETUP packet, the host is
> > indicating that the earlier control transfer has been aborted.
> > Presumably the UDC driver will complete all the outstanding requests
> > with an error status, but there's a potential race in the gadget driver
> > between queuing a request for the first transfer and executing the
> > ->setup() callback for the second transfer.)
>
> If there's another SETUP packet coming while there's a pending control
> transfer, for dwc3 UDC, the pending control TRB should be completed with
> a Setup_pending status indicating aborted control transfer for dwc3
> driver to handle that.
>
There may be one special case where dwc3 UDC may hit a race is when
there's back-to-back Setup Packet happening faster than the system can
DMA out the SETUP data of the aborted control transfer from the
controller FIFO. But this scenario should be very rare and should only
occur in simulation.
BR,
Thinh
Powered by blists - more mailing lists