Re: [PATCH] usb: dwc3: ep0: Add implementation of ep0_dequeue separately

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

Hi Udipto,

On Fri, Nov 18, 2022, Udipto Goswami wrote:
> Hi Thinh
> 
> On 11/18/22 7:31 AM, Thinh Nguyen wrote:
> > On Thu, Nov 17, 2022, Udipto Goswami wrote:
> > > A dequeue for ep0 need to adjust the handling based on the
> > > data stage and status stage. Currently if ep0 is in data/status
> > > stage the handling isn't that different, driver will try giveback
> > > as part of dequeue process which might potentially lead to the
> > > controller accessing invalid trbs.
> > > 
> > > Also for ep0 the requests aren't moved into the started_list,
> > > which might potentially lead to the un-mapping of the request
> > > buffers without sending endxfer.
> > 
> > Maybe we need to track started_list for control endpoint? If the request
> > isn't prepared yet or that the transfer had completed, then there's no
> > need to issue End Tranfer command.
> > 
> > But I believe sending End Transfer for inactive endpoint should be fine
> > also. Then we maybe able to get away without checking the started list.
> > If you're planning to do that, please test and note it somewhere.
> > 
> > > 
> thanks for the suggestion, sure i'll do some more experiments and confirm
> it.
> 

Just curious, how do you hit/test this scenario?

For other endpoint types, I can see possible scenarios where a dequeue
may be needed, but I don't see one for control transfer.

The host can cancel the control transfer, and the controller will see
"setup_packet_pending" and handle accordingly. If there's a disconnect,
that's also handled separately by the controller driver also. So, where
does ep0_dequeue come into play here?

Thanks,
Thinh