* testusb: epipe errors on test 9 and 10 @ 2025-11-27 8:06 Angelo Dureghello 2025-11-27 8:22 ` Greg KH 2025-11-28 3:23 ` Alan Stern 0 siblings, 2 replies; 16+ messages in thread From: Angelo Dureghello @ 2025-11-27 8:06 UTC (permalink / raw) To: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-27 8:06 testusb: epipe errors on test 9 and 10 Angelo Dureghello @ 2025-11-27 8:22 ` Greg KH 2025-11-27 12:53 ` Angelo Dureghello 2025-11-28 3:23 ` Alan Stern 1 sibling, 1 reply; 16+ messages in thread From: Greg KH @ 2025-11-27 8:22 UTC (permalink / raw) To: Angelo Dureghello; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-27 8:22 ` Greg KH @ 2025-11-27 12:53 ` Angelo Dureghello 2025-11-27 13:21 ` Greg KH 0 siblings, 1 reply; 16+ messages in thread From: Angelo Dureghello @ 2025-11-27 12:53 UTC (permalink / raw) To: Greg KH; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-27 12:53 ` Angelo Dureghello @ 2025-11-27 13:21 ` Greg KH 0 siblings, 0 replies; 16+ messages in thread From: Greg KH @ 2025-11-27 13:21 UTC (permalink / raw) To: Angelo Dureghello; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-27 8:06 testusb: epipe errors on test 9 and 10 Angelo Dureghello 2025-11-27 8:22 ` Greg KH @ 2025-11-28 3:23 ` Alan Stern 2025-11-28 14:20 ` Angelo Dureghello 1 sibling, 1 reply; 16+ messages in thread From: Alan Stern @ 2025-11-28 3:23 UTC (permalink / raw) To: Angelo Dureghello; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-28 3:23 ` Alan Stern @ 2025-11-28 14:20 ` Angelo Dureghello 2025-11-28 15:20 ` Alan Stern 0 siblings, 1 reply; 16+ messages in thread From: Angelo Dureghello @ 2025-11-28 14:20 UTC (permalink / raw) To: Alan Stern; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-28 14:20 ` Angelo Dureghello @ 2025-11-28 15:20 ` Alan Stern 2025-11-28 16:10 ` Alan Stern 0 siblings, 1 reply; 16+ messages in thread From: Alan Stern @ 2025-11-28 15:20 UTC (permalink / raw) To: Angelo Dureghello; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-28 15:20 ` Alan Stern @ 2025-11-28 16:10 ` Alan Stern 2025-11-28 21:21 ` Angelo Dureghello 2025-12-01 23:29 ` Thinh Nguyen 0 siblings, 2 replies; 16+ messages in thread From: Alan Stern @ 2025-11-28 16:10 UTC (permalink / raw) To: Angelo Dureghello, Thinh Nguyen; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-28 16:10 ` Alan Stern @ 2025-11-28 21:21 ` Angelo Dureghello 2025-12-01 23:29 ` Thinh Nguyen 1 sibling, 0 replies; 16+ messages in thread From: Angelo Dureghello @ 2025-11-28 21:21 UTC (permalink / raw) To: Alan Stern, Thinh Nguyen; +Cc: linux-usb 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-11-28 16:10 ` Alan Stern 2025-11-28 21:21 ` Angelo Dureghello @ 2025-12-01 23:29 ` Thinh Nguyen 2025-12-02 3:09 ` Alan Stern 1 sibling, 1 reply; 16+ messages in thread From: Thinh Nguyen @ 2025-12-01 23:29 UTC (permalink / raw) To: Alan Stern; +Cc: Angelo Dureghello, Thinh Nguyen, linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-01 23:29 ` Thinh Nguyen @ 2025-12-02 3:09 ` Alan Stern 2025-12-02 4:23 ` Thinh Nguyen 0 siblings, 1 reply; 16+ messages in thread From: Alan Stern @ 2025-12-02 3:09 UTC (permalink / raw) To: Thinh Nguyen; +Cc: Angelo Dureghello, linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-02 3:09 ` Alan Stern @ 2025-12-02 4:23 ` Thinh Nguyen 2025-12-02 16:25 ` Alan Stern 0 siblings, 1 reply; 16+ messages in thread From: Thinh Nguyen @ 2025-12-02 4:23 UTC (permalink / raw) To: Alan Stern; +Cc: Thinh Nguyen, Angelo Dureghello, linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-02 4:23 ` Thinh Nguyen @ 2025-12-02 16:25 ` Alan Stern 2025-12-02 23:22 ` Thinh Nguyen 0 siblings, 1 reply; 16+ messages in thread From: Alan Stern @ 2025-12-02 16:25 UTC (permalink / raw) To: Thinh Nguyen; +Cc: Angelo Dureghello, linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-02 16:25 ` Alan Stern @ 2025-12-02 23:22 ` Thinh Nguyen 2025-12-04 22:26 ` Alan Stern 0 siblings, 1 reply; 16+ messages in thread From: Thinh Nguyen @ 2025-12-02 23:22 UTC (permalink / raw) To: Alan Stern; +Cc: Thinh Nguyen, Angelo Dureghello, linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-02 23:22 ` Thinh Nguyen @ 2025-12-04 22:26 ` Alan Stern 2025-12-10 14:20 ` Angelo Dureghello 0 siblings, 1 reply; 16+ messages in thread From: Alan Stern @ 2025-12-04 22:26 UTC (permalink / raw) To: Thinh Nguyen; +Cc: Angelo Dureghello, linux-usb@vger.kernel.org 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); ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: testusb: epipe errors on test 9 and 10 2025-12-04 22:26 ` Alan Stern @ 2025-12-10 14:20 ` Angelo Dureghello 0 siblings, 0 replies; 16+ messages in thread From: Angelo Dureghello @ 2025-12-10 14:20 UTC (permalink / raw) To: Alan Stern, Thinh Nguyen; +Cc: linux-usb@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2025-12-10 14:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-27 8:06 testusb: epipe errors on test 9 and 10 Angelo Dureghello 2025-11-27 8:22 ` Greg KH 2025-11-27 12:53 ` Angelo Dureghello 2025-11-27 13:21 ` Greg KH 2025-11-28 3:23 ` Alan Stern 2025-11-28 14:20 ` Angelo Dureghello 2025-11-28 15:20 ` Alan Stern 2025-11-28 16:10 ` Alan Stern 2025-11-28 21:21 ` Angelo Dureghello 2025-12-01 23:29 ` Thinh Nguyen 2025-12-02 3:09 ` Alan Stern 2025-12-02 4:23 ` Thinh Nguyen 2025-12-02 16:25 ` Alan Stern 2025-12-02 23:22 ` Thinh Nguyen 2025-12-04 22:26 ` Alan Stern 2025-12-10 14:20 ` Angelo Dureghello
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).