Re: testusb: epipe errors on test 9 and 10

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

On Mon, Dec 01, 2025, Alan Stern wrote:
> On Mon, Dec 01, 2025 at 11:29:14PM +0000, Thinh Nguyen wrote:
> > On Fri, Nov 28, 2025, Alan Stern wrote:
> > > This was wrong; I had forgotten that Get-Status requests are mostly 
> > > handled by the UDC driver, not by the gadget drivers.  In your case, I 
> > > guess that's dwc3?
> > > 
> > > In the current kernel, these requests are handled in 
> > > drivers/usb/dwc3/ep0.c:dwc3_ep0_handle_status().  The problem is that 
> > > this routine doesn't handle Get-Interface-Status requests at all; 
> > > instead it passes them through to the composite core, which doesn't 
> > > handle many of them either.  Other UDC drivers do a better job.
> > > 
> > > Fixing this should be pretty easy, but I'm not not an expert on dwc3.
> > > The maintainer, Thinh Nguyen, will know what to do.
> > > 
> > 
> > This is a known issue. Often, hosts don't send ClearFeature(halt_ep)
> > unless there's a problem with a transfer. Back then, I had implemented
> > such that ClearFeature request would trigger a dequeue outstanding
> > requests from dwc3. It was to inter-op with Windows drivers for their
> > handling of transaction errors. This was the wrong way to go about it. I
> > recall after discussion with Alan and reviewing further that the
> > recovery mechanism Windows UASP driver uses was forcing an overlapping
> > command failure to trigger the function driver to dequeue requests (not
> > coming from ClearFeature and dwc3).
> 
> Are we talking about the same thing?  Clear-Feature is different from 
> Get-Interface-Status.
> 

Ah... I just saw the subject line testusb -EPIPE and assumed that it's
related to ClearFeature(halt_ep)..

The Get-Interface-Status should be hand-off and handled by gzero right?
The gadget driver knows about the status of the interface, not UDC
driver.

BR,
Thinh