testusb: epipe errors on test 9 and 10

testusb: epipe errors on test 9 and 10

[Angelo Dureghello]

Hi all,

looking for some help on testusb tool tests 9,10 always failing with
-EPIPE, kind of ep stall. Peripheral side has g_zero loaded.

Devices under test are custom boards, have same qualcomm 8 cores cpu, and
kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
Anyway, connection under tests is 2.0 microusb connector on both side.

/dev/bus/usb/001/007 test 9 --> 5 (I/O error)
/dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)

usbmon shows for both cases some EPIPE:

ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
/dev/bus/usb/001/007 test 9 --> 5 (I/O error)

ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 
2505a0a4 04050102 0302
ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
ffffff85bb5b4500 3778249493 C Ci:1:007:0 -104 0
ffffff85bb5b3500 3778249519 C Ci:1:007:0 -104 0
ffffff85bb5b3900 3778249544 C Ci:1:007:0 -104 0
ffffff85bb5b6500 3778249569 C Co:1:007:0 -104 0
ffffff85bb5b6900 3778249602 C Ci:1:007:0 -104 0
ffffff85c5b6e100 3778249631 C Ci:1:007:0 -104 0
ffffff85c5b6ed00 3778249653 C Ci:1:007:0 -104 0
ffffff85c5b6dd00 3778249674 C Ci:1:007:0 -104 0
ffffff85c5b6d500 3778249697 C Ci:1:007:0 -104 0
ffffff85c5b6b500 3778249727 C Ci:1:007:0 -104 0
ffffff85c5b6fd00 3778249755 C Ci:1:007:0 -104 0
ffffff85c5b6a900 3778249775 C Ci:1:007:0 -104 0
ffffff85c5b6ad00 3778249795 C Ci:1:007:0 -104 0
ffffff85c5b6b100 3778249815 C Ci:1:007:0 -104 0
ffffff85c5b6c500 3778249844 C Ci:1:007:0 -104 0
ffffff85c5b6d900 3778249869 C Ci:1:007:0 -104 0
/dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)

Any help on how to debug this issue is really appreciated.

Thanks a lot.

angelo

Re: testusb: epipe errors on test 9 and 10

[Greg KH]

On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
> Hi all,
> 
> looking for some help on testusb tool tests 9,10 always failing with
> -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
> 
> Devices under test are custom boards, have same qualcomm 8 cores cpu, and
> kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
> Anyway, connection under tests is 2.0 microusb connector on both side.

5.4 is _very_ old and obsolete and odds are you are paying for support
for that kernel from a company if you are stuck with it (hint, it is
going to go end-of-life in 3 days).  Please contact them as you are
paying for this kind of thing from your vendor.

If you can reproduce this with the latest release (6.17), please let us
know.

> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)
> 
> usbmon shows for both cases some EPIPE:
> 
> ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
> ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
> ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
> ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> 
> ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 2505a0a4
> 04050102 0302
> ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
> ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
> ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
> ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
> ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
> ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
> ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
> ffffff85bb5b4500 3778249493 C Ci:1:007:0 -104 0
> ffffff85bb5b3500 3778249519 C Ci:1:007:0 -104 0
> ffffff85bb5b3900 3778249544 C Ci:1:007:0 -104 0
> ffffff85bb5b6500 3778249569 C Co:1:007:0 -104 0
> ffffff85bb5b6900 3778249602 C Ci:1:007:0 -104 0
> ffffff85c5b6e100 3778249631 C Ci:1:007:0 -104 0
> ffffff85c5b6ed00 3778249653 C Ci:1:007:0 -104 0
> ffffff85c5b6dd00 3778249674 C Ci:1:007:0 -104 0
> ffffff85c5b6d500 3778249697 C Ci:1:007:0 -104 0
> ffffff85c5b6b500 3778249727 C Ci:1:007:0 -104 0
> ffffff85c5b6fd00 3778249755 C Ci:1:007:0 -104 0
> ffffff85c5b6a900 3778249775 C Ci:1:007:0 -104 0
> ffffff85c5b6ad00 3778249795 C Ci:1:007:0 -104 0
> ffffff85c5b6b100 3778249815 C Ci:1:007:0 -104 0
> ffffff85c5b6c500 3778249844 C Ci:1:007:0 -104 0
> ffffff85c5b6d900 3778249869 C Ci:1:007:0 -104 0
> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)

Any hints on logs from the device side as to what is happening?  Any
debug logs?  If this is an i/o error, the controller might be logging
something that went wrong.

thanks,

greg k-h

Re: testusb: epipe errors on test 9 and 10

[Angelo Dureghello]

Hi Greg,

thanks a lot,

On 11/27/25 09:22, Greg KH wrote:
> On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
>> Hi all,
>>
>> looking for some help on testusb tool tests 9,10 always failing with
>> -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
>>
>> Devices under test are custom boards, have same qualcomm 8 cores cpu, and
>> kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
>> Anyway, connection under tests is 2.0 microusb connector on both side.
> 5.4 is _very_ old and obsolete and odds are you are paying for support
> for that kernel from a company if you are stuck with it (hint, it is
> going to go end-of-life in 3 days).  Please contact them as you are
> paying for this kind of thing from your vendor.
>
> If you can reproduce this with the latest release (6.17), please let us
> know.
it's an android kernel msm-5.4, actually updated from google with critical
fixes, at least i can see some xhci endpoint stall issues applied to it, 
even
if of course all the usb core stuff is that old (5.4).

>> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
>> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)
>>
>> usbmon shows for both cases some EPIPE:
>>
>> ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
>> ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
>> ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
>> ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
>> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
>>
>> ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 2505a0a4
>> 04050102 0302
>> ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
>> ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
>> ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
>> ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
>> ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
>> ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
>> ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
>> ffffff85bb5b4500 3778249493 C Ci:1:007:0 -104 0
>> ffffff85bb5b3500 3778249519 C Ci:1:007:0 -104 0
>> ffffff85bb5b3900 3778249544 C Ci:1:007:0 -104 0
>> ffffff85bb5b6500 3778249569 C Co:1:007:0 -104 0
>> ffffff85bb5b6900 3778249602 C Ci:1:007:0 -104 0
>> ffffff85c5b6e100 3778249631 C Ci:1:007:0 -104 0
>> ffffff85c5b6ed00 3778249653 C Ci:1:007:0 -104 0
>> ffffff85c5b6dd00 3778249674 C Ci:1:007:0 -104 0
>> ffffff85c5b6d500 3778249697 C Ci:1:007:0 -104 0
>> ffffff85c5b6b500 3778249727 C Ci:1:007:0 -104 0
>> ffffff85c5b6fd00 3778249755 C Ci:1:007:0 -104 0
>> ffffff85c5b6a900 3778249775 C Ci:1:007:0 -104 0
>> ffffff85c5b6ad00 3778249795 C Ci:1:007:0 -104 0
>> ffffff85c5b6b100 3778249815 C Ci:1:007:0 -104 0
>> ffffff85c5b6c500 3778249844 C Ci:1:007:0 -104 0
>> ffffff85c5b6d900 3778249869 C Ci:1:007:0 -104 0
>> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)
> Any hints on logs from the device side as to what is happening?  Any
> debug logs?  If this is an i/o error, the controller might be logging
> something that went wrong.
Absolutely nothing useful in dmesg at peripheral device side.

Well, i can try to use mainline "testusb" tool, and compare 5.4 g_zero
with mainline, maybe some recent improvement fixes the issue. Will write
back here.

> thanks,
>
> greg k-h

Thanks a lot for now.
angelo

Re: testusb: epipe errors on test 9 and 10

[Greg KH]

On Thu, Nov 27, 2025 at 01:53:32PM +0100, Angelo Dureghello wrote:
> Hi Greg,
> 
> thanks a lot,
> 
> On 11/27/25 09:22, Greg KH wrote:
> > On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
> > > Hi all,
> > > 
> > > looking for some help on testusb tool tests 9,10 always failing with
> > > -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
> > > 
> > > Devices under test are custom boards, have same qualcomm 8 cores cpu, and
> > > kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
> > > Anyway, connection under tests is 2.0 microusb connector on both side.
> > 5.4 is _very_ old and obsolete and odds are you are paying for support
> > for that kernel from a company if you are stuck with it (hint, it is
> > going to go end-of-life in 3 days).  Please contact them as you are
> > paying for this kind of thing from your vendor.
> > 
> > If you can reproduce this with the latest release (6.17), please let us
> > know.
> it's an android kernel msm-5.4, actually updated from google with critical
> fixes, at least i can see some xhci endpoint stall issues applied to it,
> even
> if of course all the usb core stuff is that old (5.4).

Again, that kernel tree will go out of support in 3 days from us, so not
much we can do here, you should seriously consider upgrading as you are
going to have a very insecure system soon (not to mention that the
latest 5.4.y release, 5.4.301, currently has 1541 unfixed CVEs in it...)

thanks,

greg k-h

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
> Hi all,
> 
> looking for some help on testusb tool tests 9,10 always failing with
> -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
> 
> Devices under test are custom boards, have same qualcomm 8 cores cpu, and
> kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
> Anyway, connection under tests is 2.0 microusb connector on both side.

It seems quite likely that the problem is on the gadget side.  That's 
what you need to debug.

> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)

Did you look for error messages in the host's kernel log?

> usbmon shows for both cases some EPIPE:
> 
> ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
> ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
> ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
> ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)

I think this is the expected behavior; g_zero does not support 
Get-Interface-Status.

> ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 2505a0a4
> 04050102 0302
> ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
> ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
> ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
> ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
> ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
> ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
> ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET

I don't know what's going on here.  The usbmon data doesn't match the 
source code in the current kernel version.  It might have helped if you 
had sent more of the usbmon trace, enough to include the request that 
caused the -EPIPE error.  (That is, the most recent preceding line 
starting with "ffffff85bb5b4100", which should contain "S Ci:1:007:0".)

The -ECONNRESET errors are a normal response to the -EPIPE error.

Alan Stern

Re: testusb: epipe errors on test 9 and 10

[Angelo Dureghello]

Hi Alan,

thanks a lot,

On 11/28/25 04:23, Alan Stern wrote:
> On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
>> Hi all,
>>
>> looking for some help on testusb tool tests 9,10 always failing with
>> -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
>>
>> Devices under test are custom boards, have same qualcomm 8 cores cpu, and
>> kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
>> Anyway, connection under tests is 2.0 microusb connector on both side.
> It seems quite likely that the problem is on the gadget side.  That's
> what you need to debug.
>
>> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
>> /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)
> Did you look for error messages in the host's kernel log?
>
1-28 06:14:23.716  3913  3913 I usbtest 1-1.1: 3.0: TEST 9:  ch9 
(subset) control tests, 1000 times
11-28 06:14:23.758  3913  3913 E usbtest 1-1.1: 3.0: get interface 
status --> -5
11-28 06:14:23.758  3913  3913 E usbtest 1-1.1: 3.0: ch9 subset failed, 
iterations left 999
11-28 06:14:23.781  3913  3913 I usbtest 1-1.1: 3.0: TEST 10: queue 32 
control calls, 1000 times
11-28 06:14:23.787     0     0 E         : [    C1] usbtest 1-1.1:3.0: 
subtest 3 error, status -32
11-28 06:14:23.787     0     0 E         : [    C1] usbtest 1-1.1:3.0: 
control queue 81.00, err -32, 31996 left, subcase 3, len 0/2

>> usbmon shows for both cases some EPIPE:
>>
>> ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
>> ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
>> ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
>> ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
>> /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> I think this is the expected behavior; g_zero does not support
> Get-Interface-Status.
ok, good to know. Btw, on this article seems all tests are passing

https://bootlin.com/blog/test-a-linux-kernel-usb-device-controller-driver-with-testusb/

but not really clear what what "test must pass" is.

>
>> ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 2505a0a4
>> 04050102 0302
>> ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
>> ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
>> ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
>> ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
>> ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
>> ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
>> ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
> I don't know what's going on here.  The usbmon data doesn't match the
> source code in the current kernel version.  It might have helped if you
> had sent more of the usbmon trace, enough to include the request that
> caused the -EPIPE error.  (That is, the most recent preceding line
> starting with "ffffff85bb5b4100", which should contain "S Ci:1:007:0".)
Below the full log of the transactions of test 10

ffffff85bb5b5d00 3778175803 C Ci:1:005:0 0 4 = 00010000
ffffff863e053900 3778176320 S Ii:1:005:1 -115:2048 1 <
ffffff85bb5b5d00 3778176410 S Ci:1:003:0 s a3 00 0000 0005 0004 4 <
ffffff85bb5b5d00 3778176657 C Ci:1:003:0 0 4 = 03050000
ffffff863e053900 3778177246 C Ii:1:005:1 -2:2048 0
ffffff85bb5b5d00 3778177442 S Co:1:005:0 s 00 03 0001 0000 0000 0
ffffff85bb5b5d00 3778177561 C Co:1:005:0 0 0
ffffff85bb5b5d00 3778178034 S Co:1:003:0 s 23 03 0002 0005 0000 0
ffffff85bb5b5d00 3778178227 C Co:1:003:0 0 0
high speed      /dev/bus/usb/001/007    0
ffffff85bb5b0500 3778229608 S Co:1:007:0 s 01 0b 0000 0000 0000 0
ffffff85bb5b0500 3778231291 C Co:1:007:0 0 0
ffffff85bb5b2100 3778241217 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
ffffff85bb5b0100 3778241294 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
ffffff85bb5b1500 3778241325 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
ffffff85bb5b4100 3778241355 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
ffffff85bb5b7100 3778241387 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
ffffff85bb5b4500 3778241427 S Ci:1:007:0 s 80 06 0600 0000 000a 10 <
ffffff85bb5b3500 3778241463 S Ci:1:007:0 s 80 06 0200 0000 0012 18 <
ffffff85bb5b3900 3778241491 S Ci:1:007:0 s 80 06 0400 0000 0009 9 <
ffffff85bb5b6500 3778241519 S Co:1:007:0 s 02 01 0000 0000 0000 0
ffffff85bb5b6900 3778241548 S Ci:1:007:0 s 82 00 0000 0000 0002 2 <
ffffff85c5b6e100 3778241585 S Ci:1:007:0 s 80 06 0200 0000 0400 1024 <
ffffff85c5b6ed00 3778241616 S Ci:1:007:0 s 80 06 0500 0000 0009 9 <
ffffff85c5b6dd00 3778241641 S Ci:1:007:0 s 80 06 0300 0000 0009 9 <
ffffff85c5b6d500 3778241666 S Ci:1:007:0 s 80 06 0200 0000 03c0 960 <
ffffff85c5b6b500 3778241695 S Ci:1:007:0 s 80 06 0100 0000 0040 64 <
ffffff85c5b6fd00 3778241725 S Ci:1:007:0 s 80 06 0f00 0000 0005 5 <
ffffff85c5b6a900 3778241754 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
ffffff85c5b6ad00 3778241780 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
ffffff85c5b6b100 3778241817 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
ffffff85c5b6c500 3778241850 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
ffffff85c5b6d900 3778241875 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
ffffff85c5b68100 3778241905 S Ci:1:007:0 s 80 06 0600 0000 000a 10 <
ffffff85c5b6c900 3778241930 S Ci:1:007:0 s 80 06 0200 0000 0012 18 <
ffffff85c5b68d00 3778241953 S Ci:1:007:0 s 80 06 0400 0000 0009 9 <
ffffff85c5b6c100 3778241980 S Co:1:007:0 s 02 01 0000 0000 0000 0
ffffff85c5b6f100 3778242002 S Ci:1:007:0 s 82 00 0000 0000 0002 2 <
ffffff85c5b6cd00 3778242034 S Ci:1:007:0 s 80 06 0200 0000 0400 1024 <
ffffff85c5b69d00 3778242061 S Ci:1:007:0 s 80 06 0500 0000 0009 9 <
ffffff85c5b6f500 3778242083 S Ci:1:007:0 s 80 06 0300 0000 0009 9 <
ffffff85c5b6a500 3778242106 S Ci:1:007:0 s 80 06 0200 0000 03c0 960 <
ffffff8643257d00 3778242130 S Ci:1:007:0 s 80 06 0100 0000 0040 64 <
ffffff86236bf900 3778242151 S Ci:1:007:0 s 80 06 0f00 0000 0005 5 <
ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 
2505a0a4 04050102 0302
ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
ffffff85bb5b4500 3778249493 C Ci:1:007:0 -104 0
ffffff85bb5b3500 3778249519 C Ci:1:007:0 -104 0
ffffff85bb5b3900 3778249544 C Ci:1:007:0 -104 0
ffffff85bb5b6500 3778249569 C Co:1:007:0 -104 0
ffffff85bb5b6900 3778249602 C Ci:1:007:0 -104 0
ffffff85c5b6e100 3778249631 C Ci:1:007:0 -104 0
ffffff85c5b6ed00 3778249653 C Ci:1:007:0 -104 0
ffffff85c5b6dd00 3778249674 C Ci:1:007:0 -104 0
ffffff85c5b6d500 3778249697 C Ci:1:007:0 -104 0
ffffff85c5b6b500 3778249727 C Ci:1:007:0 -104 0
ffffff85c5b6fd00 3778249755 C Ci:1:007:0 -104 0
ffffff85c5b6a900 3778249775 C Ci:1:007:0 -104 0
ffffff85c5b6ad00 3778249795 C Ci:1:007:0 -104 0
ffffff85c5b6b100 3778249815 C Ci:1:007:0 -104 0
ffffff85c5b6c500 3778249844 C Ci:1:007:0 -104 0
ffffff85c5b6d900 3778249869 C Ci:1:007:0 -104 0
/dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)


> The -ECONNRESET errors are a normal response to the -EPIPE error.
>
> Alan Stern

Thanks a lot
angelo

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

On Fri, Nov 28, 2025 at 03:20:35PM +0100, Angelo Dureghello wrote:
> Hi Alan,
> 
> thanks a lot,
> 
> On 11/28/25 04:23, Alan Stern wrote:
> > On Thu, Nov 27, 2025 at 09:06:24AM +0100, Angelo Dureghello wrote:
> > > Hi all,
> > > 
> > > looking for some help on testusb tool tests 9,10 always failing with
> > > -EPIPE, kind of ep stall. Peripheral side has g_zero loaded.
> > > 
> > > Devices under test are custom boards, have same qualcomm 8 cores cpu, and
> > > kernel is android 5.4. Involved drivers in both devices are xhci and dwc3.
> > > Anyway, connection under tests is 2.0 microusb connector on both side.
> > It seems quite likely that the problem is on the gadget side.  That's
> > what you need to debug.
> > 
> > > /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> > > /dev/bus/usb/001/007 test 10 --> 32 (Broken pipe)
> > Did you look for error messages in the host's kernel log?
> > 
> 1-28 06:14:23.716  3913  3913 I usbtest 1-1.1: 3.0: TEST 9:  ch9 (subset)
> control tests, 1000 times
> 11-28 06:14:23.758  3913  3913 E usbtest 1-1.1: 3.0: get interface status
> --> -5
> 11-28 06:14:23.758  3913  3913 E usbtest 1-1.1: 3.0: ch9 subset failed,
> iterations left 999

Okay, this confirms that the Get-Interface-Status request is the one 
that failed.

> 11-28 06:14:23.781  3913  3913 I usbtest 1-1.1: 3.0: TEST 10: queue 32
> control calls, 1000 times
> 11-28 06:14:23.787     0     0 E         : [    C1] usbtest 1-1.1:3.0:
> subtest 3 error, status -32

And again, subtest 3 of test 10 is Get-Interface-Status.

> 11-28 06:14:23.787     0     0 E         : [    C1] usbtest 1-1.1:3.0:
> control queue 81.00, err -32, 31996 left, subcase 3, len 0/2
> 
> > > usbmon shows for both cases some EPIPE:
> > > 
> > > ffffff85bf04b100 1951528285 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
> > > ffffff85bf04b100 1951528785 C Ci:1:007:0 0 2 = 0100
> > > ffffff85bf04b100 1951529102 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <
> > > ffffff85bf04b100 1951529554 C Ci:1:007:0 -32 0   <== EPIPE
> > > /dev/bus/usb/001/007 test 9 --> 5 (I/O error)
> > I think this is the expected behavior; g_zero does not support
> > Get-Interface-Status.
> ok, good to know. Btw, on this article seems all tests are passing
> 
> https://bootlin.com/blog/test-a-linux-kernel-usb-device-controller-driver-with-testusb/
> 
> but not really clear what what "test must pass" is.

It looks like something may have changed between the time when that 
article was written and now.  I would expect g-zero to support 
Get-Interface-Status, since it is a standard request.

> > > ffffff85bb5b2100 3778244155 C Ci:1:007:0 0 18 = 12010002 ff000040 2505a0a4
> > > 04050102 0302
> > > ffffff85bb5b2100 3778244178 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
> > > ffffff85bb5b0100 3778245631 C Ci:1:007:0 0 9 = 09024500 010304c0 00
> > > ffffff85bb5b0100 3778245693 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
> > > ffffff85bb5b1500 3778247900 C Ci:1:007:0 0 1 = 00
> > > ffffff85bb5b1500 3778247964 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
> > > ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE
> > > ffffff85bb5b7100 3778249432 C Ci:1:007:0 -104 0   ECONNRESET
> > I don't know what's going on here.  The usbmon data doesn't match the
> > source code in the current kernel version.  It might have helped if you
> > had sent more of the usbmon trace, enough to include the request that
> > caused the -EPIPE error.  (That is, the most recent preceding line
> > starting with "ffffff85bb5b4100", which should contain "S Ci:1:007:0".)
> Below the full log of the transactions of test 10

...
> high speed      /dev/bus/usb/001/007    0
> ffffff85bb5b0500 3778229608 S Co:1:007:0 s 01 0b 0000 0000 0000 0
> ffffff85bb5b0500 3778231291 C Co:1:007:0 0 0
> ffffff85bb5b2100 3778241217 S Ci:1:007:0 s 80 06 0100 0000 0012 18 <
> ffffff85bb5b0100 3778241294 S Ci:1:007:0 s 80 06 0200 0000 0009 9 <
> ffffff85bb5b1500 3778241325 S Ci:1:007:0 s 81 0a 0000 0000 0001 1 <
> ffffff85bb5b4100 3778241355 S Ci:1:007:0 s 81 00 0000 0000 0002 2 <

That's the request which failed.  Comparing it to the first trace above, 
you can see that it is the same request: 81 00 0000 0000 0002.

...
> ffffff85bb5b4100 3778249094 C Ci:1:007:0 -32 0    EPIPE

And that's where the failure was reported.

Alan Stern

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

On Fri, Nov 28, 2025 at 10:20:25AM -0500, Alan Stern wrote:
> On Fri, Nov 28, 2025 at 03:20:35PM +0100, Angelo Dureghello wrote:
> > Hi Alan,
> > 
> > thanks a lot,
> > 
> > On 11/28/25 04:23, Alan Stern wrote:

> > > I think this is the expected behavior; g_zero does not support
> > > Get-Interface-Status.
> > ok, good to know. Btw, on this article seems all tests are passing
> > 
> > https://bootlin.com/blog/test-a-linux-kernel-usb-device-controller-driver-with-testusb/
> > 
> > but not really clear what what "test must pass" is.
> 
> It looks like something may have changed between the time when that 
> article was written and now.  I would expect g-zero to support 
> Get-Interface-Status, since it is a standard request.

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.

Alan Stern

Re: testusb: epipe errors on test 9 and 10

[Angelo Dureghello]

Hi Alan,

On 11/28/25 17:10, Alan Stern wrote:
> On Fri, Nov 28, 2025 at 10:20:25AM -0500, Alan Stern wrote:
>> On Fri, Nov 28, 2025 at 03:20:35PM +0100, Angelo Dureghello wrote:
>>> Hi Alan,
>>>
>>> thanks a lot,
>>>
>>> On 11/28/25 04:23, Alan Stern wrote:
>>>> I think this is the expected behavior; g_zero does not support
>>>> Get-Interface-Status.
>>> ok, good to know. Btw, on this article seems all tests are passing
>>>
>>> https://bootlin.com/blog/test-a-linux-kernel-usb-device-controller-driver-with-testusb/
>>>
>>> but not really clear what what "test must pass" is.
>> It looks like something may have changed between the time when that
>> article was written and now.  I would expect g-zero to support
>> Get-Interface-Status, since it is a standard request.
> 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.
Thanks a lot, really, will look this direction so.

> Alan Stern
angelo

Re: testusb: epipe errors on test 9 and 10

[Thinh Nguyen]

On Fri, Nov 28, 2025, Alan Stern wrote:
> On Fri, Nov 28, 2025 at 10:20:25AM -0500, Alan Stern wrote:
> > On Fri, Nov 28, 2025 at 03:20:35PM +0100, Angelo Dureghello wrote:
> > > Hi Alan,
> > > 
> > > thanks a lot,
> > > 
> > > On 11/28/25 04:23, Alan Stern wrote:
> 
> > > > I think this is the expected behavior; g_zero does not support
> > > > Get-Interface-Status.
> > > ok, good to know. Btw, on this article seems all tests are passing
> > > 
> > > https://urldefense.com/v3/__https://bootlin.com/blog/test-a-linux-kernel-usb-device-controller-driver-with-testusb/__;!!A4F2R9G_pg!YMFc3ErIaiY58L8keZGYW51XlaPRcmGt7H3GElOEKTcuI2vq_gkoEd309SJNr0rOoLs_N2XZJsVTAUSbnfi_sXatVaNC$ 
> > > 
> > > but not really clear what what "test must pass" is.
> > 
> > It looks like something may have changed between the time when that 
> > article was written and now.  I would expect g-zero to support 
> > Get-Interface-Status, since it is a standard request.
> 
> 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).

This is on my TODO list to fix. To fix this, I would also need to fix
our Linux UASP driver to handle this properly.

BR,
Thinh

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

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.

Alan Stern

Re: testusb: epipe errors on test 9 and 10

[Thinh Nguyen]

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

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

On Tue, Dec 02, 2025 at 04:23:13AM +0000, Thinh Nguyen wrote:
> On Mon, Dec 01, 2025, Alan Stern wrote:
> > 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.

For USB-2 devices, Get-Interface-Status is always supposed to return two 
bytes of 0.  For USB-3 devices, it returns information about Function 
Remote Wakeup and Function Remote Wakeup Capable, which is handled 
already by the composite core.

So for SuperSpeed and above, the request should be delegated.  For high 
speed and below, it could be done either way.  (dummy-hcd makes the 
opposite mistake; it always returns zeros for Get-Interface-Status and 
never delegates.)

If you think it's best always to delegate the request then composite.c 
needs to be changed; it should handle the reply for non-SuperSpeed 
connections.  A simple change; I can do it.  What do you prefer?

Alan Stern

Re: testusb: epipe errors on test 9 and 10

[Thinh Nguyen]

On Tue, Dec 02, 2025, Alan Stern wrote:
> On Tue, Dec 02, 2025 at 04:23:13AM +0000, Thinh Nguyen wrote:
> > On Mon, Dec 01, 2025, Alan Stern wrote:
> > > 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.
> 
> For USB-2 devices, Get-Interface-Status is always supposed to return two 
> bytes of 0.  For USB-3 devices, it returns information about Function 
> Remote Wakeup and Function Remote Wakeup Capable, which is handled 
> already by the composite core.
> 
> So for SuperSpeed and above, the request should be delegated.  For high 
> speed and below, it could be done either way.  (dummy-hcd makes the 
> opposite mistake; it always returns zeros for Get-Interface-Status and 
> never delegates.)
> 
> If you think it's best always to delegate the request then composite.c 
> needs to be changed; it should handle the reply for non-SuperSpeed 
> connections.  A simple change; I can do it.  What do you prefer?
> 

Right this change is simple. I think it's probably easier to delegate
and enforce this in the composite library instead of auditing all the
UDC drivers.

Thanks!
Thinh

Re: testusb: epipe errors on test 9 and 10

[Alan Stern]

On Tue, Dec 02, 2025 at 11:22:38PM +0000, Thinh Nguyen wrote:
> On Tue, Dec 02, 2025, Alan Stern wrote:
> > On Tue, Dec 02, 2025 at 04:23:13AM +0000, Thinh Nguyen wrote:
> > > On Mon, Dec 01, 2025, Alan Stern wrote:
> > > > 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.
> > 
> > For USB-2 devices, Get-Interface-Status is always supposed to return two 
> > bytes of 0.  For USB-3 devices, it returns information about Function 
> > Remote Wakeup and Function Remote Wakeup Capable, which is handled 
> > already by the composite core.
> > 
> > So for SuperSpeed and above, the request should be delegated.  For high 
> > speed and below, it could be done either way.  (dummy-hcd makes the 
> > opposite mistake; it always returns zeros for Get-Interface-Status and 
> > never delegates.)
> > 
> > If you think it's best always to delegate the request then composite.c 
> > needs to be changed; it should handle the reply for non-SuperSpeed 
> > connections.  A simple change; I can do it.  What do you prefer?
> > 
> 
> Right this change is simple. I think it's probably easier to delegate
> and enforce this in the composite library instead of auditing all the
> UDC drivers.

Here's a patch to try.  Angelo, can you test this?

Alan Stern



Index: usb-devel/drivers/usb/gadget/composite.c
===================================================================
--- usb-devel.orig/drivers/usb/gadget/composite.c
+++ usb-devel/drivers/usb/gadget/composite.c
@@ -1966,25 +1966,27 @@ composite_setup(struct usb_gadget *gadge
 			break;
 		}
 
-		/*
-		 * USB 3.0 additions:
-		 * Function driver should handle get_status request. If such cb
-		 * wasn't supplied we respond with default value = 0
-		 * Note: function driver should supply such cb only for the
-		 * first interface of the function
-		 */
-		if (!gadget_is_superspeed(gadget))
-			goto unknown;
+		/* UDC driver should handle device and endpoint recipients */
 		if (ctrl->bRequestType != (USB_DIR_IN | USB_RECIP_INTERFACE))
 			goto unknown;
-		value = 2;	/* This is the length of the get_status reply */
-		put_unaligned_le16(0, req->buf);
 		if (!cdev->config || intf >= MAX_CONFIG_INTERFACES)
 			break;
 		f = cdev->config->interface[intf];
 		if (!f)
 			break;
 
+		value = 2;	/* This is the length of the get_status reply */
+		put_unaligned_le16(0, req->buf);
+		if (!gadget_is_superspeed(gadget))
+			break;	/* USB-2 always returns zeros */
+
+		/*
+		 * USB 3.0 additions:
+		 * Function driver should handle get_status request. If such cb
+		 * wasn't supplied we respond with default value = 0
+		 * Note: function driver should supply such cb only for the
+		 * first interface of the function
+		 */
 		if (f->get_status) {
 			status = f->get_status(f);
 

Re: testusb: epipe errors on test 9 and 10

[Angelo Dureghello]

Hi Alan,

On 12/4/25 23:26, Alan Stern wrote:
> On Tue, Dec 02, 2025 at 11:22:38PM +0000, Thinh Nguyen wrote:
>> On Tue, Dec 02, 2025, Alan Stern wrote:
>>> On Tue, Dec 02, 2025 at 04:23:13AM +0000, Thinh Nguyen wrote:
>>>> On Mon, Dec 01, 2025, Alan Stern wrote:
>>>>> 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.
>>> For USB-2 devices, Get-Interface-Status is always supposed to return two
>>> bytes of 0.  For USB-3 devices, it returns information about Function
>>> Remote Wakeup and Function Remote Wakeup Capable, which is handled
>>> already by the composite core.
>>>
>>> So for SuperSpeed and above, the request should be delegated.  For high
>>> speed and below, it could be done either way.  (dummy-hcd makes the
>>> opposite mistake; it always returns zeros for Get-Interface-Status and
>>> never delegates.)
>>>
>>> If you think it's best always to delegate the request then composite.c
>>> needs to be changed; it should handle the reply for non-SuperSpeed
>>> connections.  A simple change; I can do it.  What do you prefer?
>>>
>> Right this change is simple. I think it's probably easier to delegate
>> and enforce this in the composite library instead of auditing all the
>> UDC drivers.
> Here's a patch to try.  Angelo, can you test this?
>
> Alan Stern
>
>
>
> Index: usb-devel/drivers/usb/gadget/composite.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/gadget/composite.c
> +++ usb-devel/drivers/usb/gadget/composite.c
> @@ -1966,25 +1966,27 @@ composite_setup(struct usb_gadget *gadge
>   			break;
>   		}
>   
> -		/*
> -		 * USB 3.0 additions:
> -		 * Function driver should handle get_status request. If such cb
> -		 * wasn't supplied we respond with default value = 0
> -		 * Note: function driver should supply such cb only for the
> -		 * first interface of the function
> -		 */
> -		if (!gadget_is_superspeed(gadget))
> -			goto unknown;
> +		/* UDC driver should handle device and endpoint recipients */
>   		if (ctrl->bRequestType != (USB_DIR_IN | USB_RECIP_INTERFACE))
>   			goto unknown;
> -		value = 2;	/* This is the length of the get_status reply */
> -		put_unaligned_le16(0, req->buf);
>   		if (!cdev->config || intf >= MAX_CONFIG_INTERFACES)
>   			break;
>   		f = cdev->config->interface[intf];
>   		if (!f)
>   			break;
>   
> +		value = 2;	/* This is the length of the get_status reply */
> +		put_unaligned_le16(0, req->buf);
> +		if (!gadget_is_superspeed(gadget))
> +			break;	/* USB-2 always returns zeros */
> +
> +		/*
> +		 * USB 3.0 additions:
> +		 * Function driver should handle get_status request. If such cb
> +		 * wasn't supplied we respond with default value = 0
> +		 * Note: function driver should supply such cb only for the
> +		 * first interface of the function
> +		 */
>   		if (f->get_status) {
>   			status = f->get_status(f);
>   
thanks a lot.

I am actually stuck working in 5-4 kernel, where the issue was detected, 
but will do my best to test this
as soon as i can .

Regards,
angelo