* EHSET with hub and PCIe root hub
@ 2019-09-10 22:01 Allen Blaylock
2019-09-11 2:57 ` Peter Chen
0 siblings, 1 reply; 11+ messages in thread
From: Allen Blaylock @ 2019-09-10 22:01 UTC (permalink / raw)
To: linux-usb
I am trying to validate the USB on an embedded platform based on the NXP i.MX7.
So far I have only been able to validate root ports on the board but also have a
PCIe xhci controller and a microchip USB3503 hub off of the HSIC port on the
SoC which I would like to run the tests on.
I have reviewed the mailing list archives and found another discussion of using
the EHSET driver to validate a driver and they reference the same issue I am
seeing. When I plug in the device I see
usb_ehset_test: probe of <port path> failed with error -32
for either the PCIe root hub or the USB3503 HSIC hub.
Further down in the mailing list chain Peter Chen states
> Besides, do not connect HUB between your host board and emulation board
> (for sending VID/PID).
but there is no additional information regarding this statement. Looking around
it looks like the hubs have some mechanism for being tested[0] and the HSETT
application for Windows supports testing of hubs according to the
documentation.[1]
Is this something there exists a module for or are either of these cases
unexpected behavior for the EHSET kernel module?
Allen
[0] http://www.testusb.com/Hub_test.html
[1] https://usb.org/sites/default/files/HSETT_Instruction_0_4_1.pdf
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: EHSET with hub and PCIe root hub 2019-09-10 22:01 EHSET with hub and PCIe root hub Allen Blaylock @ 2019-09-11 2:57 ` Peter Chen 2019-09-11 3:54 ` Manu Gautam 0 siblings, 1 reply; 11+ messages in thread From: Peter Chen @ 2019-09-11 2:57 UTC (permalink / raw) To: Allen Blaylock; +Cc: linux-usb On 19-09-10 22:01:58, Allen Blaylock wrote: > I am trying to validate the USB on an embedded platform based on the NXP i.MX7. > So far I have only been able to validate root ports on the board but also have a > PCIe xhci controller and a microchip USB3503 hub off of the HSIC port on the > SoC which I would like to run the tests on. > > I have reviewed the mailing list archives and found another discussion of using > the EHSET driver to validate a driver and they reference the same issue I am > seeing. When I plug in the device I see > usb_ehset_test: probe of <port path> failed with error -32 > for either the PCIe root hub or the USB3503 HSIC hub. > > Further down in the mailing list chain Peter Chen states > > Besides, do not connect HUB between your host board and emulation board > > (for sending VID/PID). > but there is no additional information regarding this statement. EHSET is used to test embedded host electrical signal required by USB IF Compliance Test, not test the signal for USB HUB, since the EHSET module could only let embedded host controller enter test mode by writing TEST MODE registers follows EHCI or xHCI spec. Maybe the USB HUB could let its port enter test mode, but it needs to use other ways, maybe vendor specific commands. For your PCIe xHCI controller, if it follows xHCI spec, it should work with EHSET, would you please debug it by code and see why return error? Peter > Looking around > it looks like the hubs have some mechanism for being tested[0] and the HSETT > application for Windows supports testing of hubs according to the > documentation.[1] > > Is this something there exists a module for or are either of these cases > unexpected behavior for the EHSET kernel module? > > Allen > > [0] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.testusb.com%2FHub_test.html&data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&sdata=djXerGrLCkeITKRqg4KteuzNn5TMxeOhqif58DWJYUE%3D&reserved=0 > [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fusb.org%2Fsites%2Fdefault%2Ffiles%2FHSETT_Instruction_0_4_1.pdf&data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&sdata=gem9tyxRAWIppDFW%2Fpw08dPKqQQ9NMX%2BhH19V2SloiQ%3D&reserved=0 > -- Thanks, Peter Chen ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: EHSET with hub and PCIe root hub 2019-09-11 2:57 ` Peter Chen @ 2019-09-11 3:54 ` Manu Gautam 2019-09-11 20:34 ` Allen Blaylock 0 siblings, 1 reply; 11+ messages in thread From: Manu Gautam @ 2019-09-11 3:54 UTC (permalink / raw) To: Peter Chen, Allen Blaylock; +Cc: linux-usb On 9/11/2019 8:27 AM, Peter Chen wrote: > On 19-09-10 22:01:58, Allen Blaylock wrote: >> I am trying to validate the USB on an embedded platform based on the NXP i.MX7. >> So far I have only been able to validate root ports on the board but also have a >> PCIe xhci controller and a microchip USB3503 hub off of the HSIC port on the >> SoC which I would like to run the tests on. >> >> I have reviewed the mailing list archives and found another discussion of using >> the EHSET driver to validate a driver and they reference the same issue I am >> seeing. When I plug in the device I see >> usb_ehset_test: probe of <port path> failed with error -32 >> for either the PCIe root hub or the USB3503 HSIC hub. I remember seeing some HUBs which fail to enter compliance mode (STALL SetFeature request) if a device is connected to the port. You can check usbmon logs if SetFeature request was sent to HUB. >> >> Further down in the mailing list chain Peter Chen states >>> Besides, do not connect HUB between your host board and emulation board >>> (for sending VID/PID). >> but there is no additional information regarding this statement. > EHSET is used to test embedded host electrical signal required by > USB IF Compliance Test, not test the signal for USB HUB, since the > EHSET module could only let embedded host controller enter test mode > by writing TEST MODE registers follows EHCI or xHCI spec. Maybe the > USB HUB could let its port enter test mode, but it needs to use other > ways, maybe vendor specific commands. IMO ehset should work with external HUB as well since all it takes to put a HUB's port in compliance mode is sending a SetFeature request which I believe driver already does. If HUB is sending stall then you can try putting a different port in compliance which is not connected. > > For your PCIe xHCI controller, if it follows xHCI spec, it should work > with EHSET, would you please debug it by code and see why return error? > > Peter >> Looking around >> it looks like the hubs have some mechanism for being tested[0] and the HSETT >> application for Windows supports testing of hubs according to the >> documentation.[1] >> >> Is this something there exists a module for or are either of these cases >> unexpected behavior for the EHSET kernel module? >> >> Allen >> >> [0] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.testusb.com%2FHub_test.html&data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&sdata=djXerGrLCkeITKRqg4KteuzNn5TMxeOhqif58DWJYUE%3D&reserved=0 >> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fusb.org%2Fsites%2Fdefault%2Ffiles%2FHSETT_Instruction_0_4_1.pdf&data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&sdata=gem9tyxRAWIppDFW%2Fpw08dPKqQQ9NMX%2BhH19V2SloiQ%3D&reserved=0 >> -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-11 3:54 ` Manu Gautam @ 2019-09-11 20:34 ` Allen Blaylock 2019-09-12 0:49 ` Peter Chen 2019-09-12 14:20 ` Alan Stern 0 siblings, 2 replies; 11+ messages in thread From: Allen Blaylock @ 2019-09-11 20:34 UTC (permalink / raw) To: Manu Gautam, Peter Chen; +Cc: linux-usb > >On 9/11/2019 8:27 AM, Peter Chen wrote: >> On 19-09-10 22:01:58, Allen Blaylock wrote: >>> I am trying to validate the USB on an embedded platform based on the NXP i.MX7. >>> So far I have only been able to validate root ports on the board but >>> also have a PCIe xhci controller and a microchip USB3503 hub off of >>> the HSIC port on the SoC which I would like to run the tests on. >>> >>> I have reviewed the mailing list archives and found another >>> discussion of using the EHSET driver to validate a driver and they >>> reference the same issue I am seeing. When I plug in the device I see >>> usb_ehset_test: probe of <port path> failed with error -32 for either >>> the PCIe root hub or the USB3503 HSIC hub. > > >I remember seeing some HUBs which fail to enter compliance mode (STALL SetFeature request) if a device is connected to the port. >You can check usbmon logs if SetFeature request was sent to HUB. So I do see the PORT_TEST SetFeature Request and Response when I use tcpdump to make a capture using usbmon. Unfortunately I am not as familiar with the raw usbmon output or some of the diagnostics output by usbmon so I may be missing something. Here is a capture from the sysfs usbmon file: a52efe00 268933702 C Ii:002:01 0 1 = 08 a52efe00 268933736 S Ii:002:01 -115 1 < a546b700 268934005 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b700 268934303 C Ci:002:00 0 4 = 01010100 a546b700 268934327 S Co:002:00 s 23 01 0010 0003 0000 0 a546b700 268934384 C Co:002:00 0 0 a546b700 268934438 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b700 268934520 C Ci:002:00 0 4 = 01010000 a546b700 268980085 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b700 268980332 C Ci:002:00 0 4 = 01010000 a546b700 269030091 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b700 269030333 C Ci:002:00 0 4 = 01010000 a546b700 269080082 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b700 269080335 C Ci:002:00 0 4 = 01010000 a546b280 269130094 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546b280 269130339 C Ci:002:00 0 4 = 01010000 a546b280 269130376 S Co:002:00 s 23 03 0004 0003 0000 0 a546b280 269130577 C Co:002:00 0 0 a546be00 269160091 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546be00 269160344 C Ci:002:00 0 4 = 03051000 a546be00 269160361 S Co:002:00 s 23 01 0014 0003 0000 0 a546be00 269160416 C Co:002:00 0 0 a546be00 269230118 S Ci:000:00 s 80 06 0100 0000 0040 64 < a546be00 269230341 C Ci:000:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 a546be00 269230358 S Co:002:00 s 23 03 0004 0003 0000 0 a546be00 269230425 C Co:002:00 0 0 a546be00 269260104 S Ci:002:00 s a3 00 0000 0003 0004 4 < a546be00 269260354 C Ci:002:00 0 4 = 03051000 a546be00 269260374 S Co:002:00 s 23 01 0014 0003 0000 0 a546be00 269260430 C Co:002:00 0 0 a546be00 269330097 S Co:000:00 s 00 05 0004 0000 0000 0 a546be00 269330372 C Co:000:00 0 0 a546b700 269380050 S Ci:004:00 s 80 06 0100 0000 0012 18 < a546b700 269380327 C Ci:004:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 a546b700 269380360 S Ci:004:00 s 80 06 0200 0000 0009 9 < a546b700 269380453 C Ci:004:00 0 9 = 09022e00 01010080 32 a546b700 269380468 S Ci:004:00 s 80 06 0200 0000 002e 46 < a546b700 269380574 C Ci:004:00 0 46 = 09022e00 01010080 32090400 0004ff00 00000705 02020002 00070504 02000200 a546b700 269380608 S Ci:004:00 s 80 06 0300 0000 00ff 255 < a546b700 269380701 C Ci:004:00 0 4 = 04030904 a546b700 269380717 S Ci:004:00 s 80 06 0302 0409 00ff 255 < a546b700 269380824 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 a546b700 269380845 S Ci:004:00 s 80 06 0301 0409 00ff 255 < a546b700 269380949 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 a546b700 269380968 S Ci:004:00 s 80 06 0303 0409 00ff 255 < a546b700 269381074 C Ci:004:00 0 10 = 0a034900 4f005600 3300 a546b280 269381564 S Co:004:00 s 00 09 0001 0000 0000 0 a546b280 269381704 C Co:004:00 0 0 a560a000 269407637 S Co:002:00 s 23 03 0015 0403 0000 0 a560a000 269407869 C Co:002:00 -32 0 I was unable to make sense of it with the help of the usbmon.txt documentation and will need some more time using wireshark and the output of tcpdump to get familiar with decoding the raw usbmon output. >>> >>> Further down in the mailing list chain Peter Chen states >>>> Besides, do not connect HUB between your host board and emulation >>>> board (for sending VID/PID). >>> but there is no additional information regarding this statement. >> EHSET is used to test embedded host electrical signal required by USB >> IF Compliance Test, not test the signal for USB HUB, since the EHSET >> module could only let embedded host controller enter test mode by >> writing TEST MODE registers follows EHCI or xHCI spec. Maybe the USB >> HUB could let its port enter test mode, but it needs to use other >> ways, maybe vendor specific commands. > >IMO ehset should work with external HUB as well since all it takes to put a HUB's port in compliance mode is sending a SetFeature request which I believe driver already does. If HUB is sending stall then you can try putting a different port in compliance which is not connected. How do I specify which port I put in compliance? The way I have been doing it was using a PIDVID from testusb.com which, as I understand it, turns into the correct device by setting its VID and PID so by nature of how it works I must have a "device" connected. Allen ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-11 20:34 ` Allen Blaylock @ 2019-09-12 0:49 ` Peter Chen 2019-09-12 14:20 ` Alan Stern 1 sibling, 0 replies; 11+ messages in thread From: Peter Chen @ 2019-09-12 0:49 UTC (permalink / raw) To: Allen Blaylock, Manu Gautam; +Cc: linux-usb > >>> > >>> Further down in the mailing list chain Peter Chen states > >>>> Besides, do not connect HUB between your host board and emulation > >>>> board (for sending VID/PID). > >>> but there is no additional information regarding this statement. > >> EHSET is used to test embedded host electrical signal required by USB > >> IF Compliance Test, not test the signal for USB HUB, since the EHSET > >> module could only let embedded host controller enter test mode by > >> writing TEST MODE registers follows EHCI or xHCI spec. Maybe the USB > >> HUB could let its port enter test mode, but it needs to use other > >> ways, maybe vendor specific commands. > > > >IMO ehset should work with external HUB as well since all it takes to put a HUB's > port in compliance mode is sending a SetFeature request which I believe driver > already does. If HUB is sending stall then you can try putting a different port in > compliance which is not connected. > > How do I specify which port I put in compliance? The way I have been doing it was > using a PIDVID from testusb.com which, as I understand it, turns into the correct > device by setting its VID and PID so by nature of how it works I must have a > "device" connected. > Which port your test device is connected, then which port will enter test mode, it is controlled by EHSET. The test device's VID/PID must be the same with ehset_id_table in ehset.c. For external HUB, I have never done since I only test USB controller on SoC. As Manu said, if it supports the commands in EHSET in its firmware, it should support put its downstream port in test mode. Peter ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-11 20:34 ` Allen Blaylock 2019-09-12 0:49 ` Peter Chen @ 2019-09-12 14:20 ` Alan Stern 2019-09-12 14:28 ` Alan Stern 2019-09-12 14:29 ` Allen Blaylock 1 sibling, 2 replies; 11+ messages in thread From: Alan Stern @ 2019-09-12 14:20 UTC (permalink / raw) To: Allen Blaylock; +Cc: Manu Gautam, Peter Chen, linux-usb On Wed, 11 Sep 2019, Allen Blaylock wrote: > So I do see the PORT_TEST SetFeature Request and Response when I use tcpdump to > make a capture using usbmon. Unfortunately I am not as familiar with the raw > usbmon output or some of the diagnostics output by usbmon so I may be missing > something. Here is a capture from the sysfs usbmon file: > > a52efe00 268933702 C Ii:002:01 0 1 = 08 > a52efe00 268933736 S Ii:002:01 -115 1 < > a546b700 268934005 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b700 268934303 C Ci:002:00 0 4 = 01010100 > a546b700 268934327 S Co:002:00 s 23 01 0010 0003 0000 0 > a546b700 268934384 C Co:002:00 0 0 > a546b700 268934438 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b700 268934520 C Ci:002:00 0 4 = 01010000 > a546b700 268980085 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b700 268980332 C Ci:002:00 0 4 = 01010000 > a546b700 269030091 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b700 269030333 C Ci:002:00 0 4 = 01010000 > a546b700 269080082 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b700 269080335 C Ci:002:00 0 4 = 01010000 > a546b280 269130094 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546b280 269130339 C Ci:002:00 0 4 = 01010000 > a546b280 269130376 S Co:002:00 s 23 03 0004 0003 0000 0 > a546b280 269130577 C Co:002:00 0 0 > a546be00 269160091 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546be00 269160344 C Ci:002:00 0 4 = 03051000 > a546be00 269160361 S Co:002:00 s 23 01 0014 0003 0000 0 > a546be00 269160416 C Co:002:00 0 0 > a546be00 269230118 S Ci:000:00 s 80 06 0100 0000 0040 64 < > a546be00 269230341 C Ci:000:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 > a546be00 269230358 S Co:002:00 s 23 03 0004 0003 0000 0 > a546be00 269230425 C Co:002:00 0 0 > a546be00 269260104 S Ci:002:00 s a3 00 0000 0003 0004 4 < > a546be00 269260354 C Ci:002:00 0 4 = 03051000 > a546be00 269260374 S Co:002:00 s 23 01 0014 0003 0000 0 > a546be00 269260430 C Co:002:00 0 0 > a546be00 269330097 S Co:000:00 s 00 05 0004 0000 0000 0 > a546be00 269330372 C Co:000:00 0 0 > a546b700 269380050 S Ci:004:00 s 80 06 0100 0000 0012 18 < > a546b700 269380327 C Ci:004:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 > a546b700 269380360 S Ci:004:00 s 80 06 0200 0000 0009 9 < > a546b700 269380453 C Ci:004:00 0 9 = 09022e00 01010080 32 > a546b700 269380468 S Ci:004:00 s 80 06 0200 0000 002e 46 < > a546b700 269380574 C Ci:004:00 0 46 = 09022e00 01010080 32090400 0004ff00 00000705 02020002 00070504 02000200 > a546b700 269380608 S Ci:004:00 s 80 06 0300 0000 00ff 255 < > a546b700 269380701 C Ci:004:00 0 4 = 04030904 > a546b700 269380717 S Ci:004:00 s 80 06 0302 0409 00ff 255 < > a546b700 269380824 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 > a546b700 269380845 S Ci:004:00 s 80 06 0301 0409 00ff 255 < > a546b700 269380949 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 > a546b700 269380968 S Ci:004:00 s 80 06 0303 0409 00ff 255 < > a546b700 269381074 C Ci:004:00 0 10 = 0a034900 4f005600 3300 > a546b280 269381564 S Co:004:00 s 00 09 0001 0000 0000 0 > a546b280 269381704 C Co:004:00 0 0 > a560a000 269407637 S Co:002:00 s 23 03 0015 0403 0000 0 > a560a000 269407869 C Co:002:00 -32 0 > > I was unable to make sense of it with the help of the usbmon.txt documentation > and will need some more time using wireshark and the output of tcpdump to get > familiar with decoding the raw usbmon output. Most of the usbmon output shows that a device was attached to port 3 of hub 2 and enumerated as usual over the course of about half a second. The very last two lines show the computer sending the hub a Set-Port-Test request on port 3 for test mode 4, which is Test Packet. The hub's response is a STALL, indicating that the hub doesn't understand or doesn't implement this request. Alan Stern ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-12 14:20 ` Alan Stern @ 2019-09-12 14:28 ` Alan Stern 2019-09-12 20:32 ` Allen Blaylock 2019-09-12 14:29 ` Allen Blaylock 1 sibling, 1 reply; 11+ messages in thread From: Alan Stern @ 2019-09-12 14:28 UTC (permalink / raw) To: Allen Blaylock; +Cc: Manu Gautam, Peter Chen, linux-usb On Thu, 12 Sep 2019, Alan Stern wrote: > On Wed, 11 Sep 2019, Allen Blaylock wrote: > > > So I do see the PORT_TEST SetFeature Request and Response when I use tcpdump to > > make a capture using usbmon. Unfortunately I am not as familiar with the raw > > usbmon output or some of the diagnostics output by usbmon so I may be missing > > something. Here is a capture from the sysfs usbmon file: > > > > a52efe00 268933702 C Ii:002:01 0 1 = 08 > > a52efe00 268933736 S Ii:002:01 -115 1 < > > a546b700 268934005 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b700 268934303 C Ci:002:00 0 4 = 01010100 > > a546b700 268934327 S Co:002:00 s 23 01 0010 0003 0000 0 > > a546b700 268934384 C Co:002:00 0 0 > > a546b700 268934438 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b700 268934520 C Ci:002:00 0 4 = 01010000 > > a546b700 268980085 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b700 268980332 C Ci:002:00 0 4 = 01010000 > > a546b700 269030091 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b700 269030333 C Ci:002:00 0 4 = 01010000 > > a546b700 269080082 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b700 269080335 C Ci:002:00 0 4 = 01010000 > > a546b280 269130094 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546b280 269130339 C Ci:002:00 0 4 = 01010000 > > a546b280 269130376 S Co:002:00 s 23 03 0004 0003 0000 0 > > a546b280 269130577 C Co:002:00 0 0 > > a546be00 269160091 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546be00 269160344 C Ci:002:00 0 4 = 03051000 > > a546be00 269160361 S Co:002:00 s 23 01 0014 0003 0000 0 > > a546be00 269160416 C Co:002:00 0 0 > > a546be00 269230118 S Ci:000:00 s 80 06 0100 0000 0040 64 < > > a546be00 269230341 C Ci:000:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 > > a546be00 269230358 S Co:002:00 s 23 03 0004 0003 0000 0 > > a546be00 269230425 C Co:002:00 0 0 > > a546be00 269260104 S Ci:002:00 s a3 00 0000 0003 0004 4 < > > a546be00 269260354 C Ci:002:00 0 4 = 03051000 > > a546be00 269260374 S Co:002:00 s 23 01 0014 0003 0000 0 > > a546be00 269260430 C Co:002:00 0 0 > > a546be00 269330097 S Co:000:00 s 00 05 0004 0000 0000 0 > > a546be00 269330372 C Co:000:00 0 0 > > a546b700 269380050 S Ci:004:00 s 80 06 0100 0000 0012 18 < > > a546b700 269380327 C Ci:004:00 0 18 = 12010002 00000040 0a1a0401 00010102 0301 > > a546b700 269380360 S Ci:004:00 s 80 06 0200 0000 0009 9 < > > a546b700 269380453 C Ci:004:00 0 9 = 09022e00 01010080 32 > > a546b700 269380468 S Ci:004:00 s 80 06 0200 0000 002e 46 < > > a546b700 269380574 C Ci:004:00 0 46 = 09022e00 01010080 32090400 0004ff00 00000705 02020002 00070504 02000200 > > a546b700 269380608 S Ci:004:00 s 80 06 0300 0000 00ff 255 < > > a546b700 269380701 C Ci:004:00 0 4 = 04030904 > > a546b700 269380717 S Ci:004:00 s 80 06 0302 0409 00ff 255 < > > a546b700 269380824 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 > > a546b700 269380845 S Ci:004:00 s 80 06 0301 0409 00ff 255 < > > a546b700 269380949 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 53005400 20005400 45005300 54004500 > > a546b700 269380968 S Ci:004:00 s 80 06 0303 0409 00ff 255 < > > a546b700 269381074 C Ci:004:00 0 10 = 0a034900 4f005600 3300 > > a546b280 269381564 S Co:004:00 s 00 09 0001 0000 0000 0 > > a546b280 269381704 C Co:004:00 0 0 > > a560a000 269407637 S Co:002:00 s 23 03 0015 0403 0000 0 > > a560a000 269407869 C Co:002:00 -32 0 > > > > I was unable to make sense of it with the help of the usbmon.txt documentation > > and will need some more time using wireshark and the output of tcpdump to get > > familiar with decoding the raw usbmon output. > > Most of the usbmon output shows that a device was attached to port 3 of > hub 2 and enumerated as usual over the course of about half a second. > > The very last two lines show the computer sending the hub a > Set-Port-Test request on port 3 for test mode 4, which is Test Packet. > The hub's response is a STALL, indicating that the hub doesn't > understand or doesn't implement this request. I should add that the USB 2.0 spec includes the following text (from section 11.24.2.13): Test mode of a downstream facing port can only be used in a well defined sequence of hub states. This sequence is defined as follows: 1) All enabled downstream facing ports of the hub containing the port to be tested must be (selectively) suspended via the SetPortFeature(PORT_SUSPEND) request. Each downstream facing port of the hub must be in the disabled, disconnected, or suspended state (see Figure 11-9). So you can see the hub probably failed the request because a non-suspended device was connected to port 3. (And who knows what was attached to the other ports -- the usbmon trace doesn't say.) Alan Stern ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-12 14:28 ` Alan Stern @ 2019-09-12 20:32 ` Allen Blaylock 2019-09-12 20:51 ` Alan Stern 0 siblings, 1 reply; 11+ messages in thread From: Allen Blaylock @ 2019-09-12 20:32 UTC (permalink / raw) To: Alan Stern; +Cc: Manu Gautam, Peter Chen, linux-usb >I should add that the USB 2.0 spec includes the following text (from section 11.24.2.13): > > Test mode of a downstream facing port can only be used in > a well defined sequence of hub states. This sequence is > defined as follows: > > 1) All enabled downstream facing ports of the hub containing > the port to be tested must be (selectively) suspended via > the SetPortFeature(PORT_SUSPEND) request. Each downstream > facing port of the hub must be in the disabled, > disconnected, or suspended state (see Figure 11-9). > >So you can see the hub probably failed the request because a non-suspended device was connected to port 3. (And who knows what was attached to the other ports -- the usbmon trace doesn't say.) > >Alan Stern This was very helpful. I was able to get the USB3503 to generate test packets by adding a SetPortFeature(PORT_SUSPEND) request to suspend the port before setting the PORT_TEST feature. Is there a way to tell that a device is a hub but not a root hub so ports on root hub ports aren't suspended prior to calling SetPortFeature(PORT_TEST)? I tried to use hub_udev->maxchild to determine if something was a hub but this appears misguided since root hubs can have multiple children, nothing else in the usb_device structure jumped out as being directly related to a hub. --- a/drivers/usb/misc/ehset.c +++ b/drivers/usb/misc/ehset.c @@ -62,6 +62,16 @@ static int ehset_probe(struct usb_interface *intf, NULL, 0, 1000); break; case TEST_PACKET_PID: + if(hub_udev->maxchild) + { + ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0), + USB_REQ_SET_FEATURE, USB_RT_PORT, + USB_PORT_FEAT_SUSPEND, portnum, + NULL, 0, 1000); + if (ret < 0) + break; + + } ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0), USB_REQ_SET_FEATURE, USB_RT_PORT, USB_PORT_FEAT_TEST, ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-12 20:32 ` Allen Blaylock @ 2019-09-12 20:51 ` Alan Stern 2019-09-16 1:11 ` Peter Chen 0 siblings, 1 reply; 11+ messages in thread From: Alan Stern @ 2019-09-12 20:51 UTC (permalink / raw) To: Allen Blaylock; +Cc: Manu Gautam, Peter Chen, linux-usb On Thu, 12 Sep 2019, Allen Blaylock wrote: > >I should add that the USB 2.0 spec includes the following text (from section 11.24.2.13): > > > > Test mode of a downstream facing port can only be used in > > a well defined sequence of hub states. This sequence is > > defined as follows: > > > > 1) All enabled downstream facing ports of the hub containing > > the port to be tested must be (selectively) suspended via > > the SetPortFeature(PORT_SUSPEND) request. Each downstream > > facing port of the hub must be in the disabled, > > disconnected, or suspended state (see Figure 11-9). > > > >So you can see the hub probably failed the request because a non-suspended device was connected to port 3. (And who knows what was attached to the other ports -- the usbmon trace doesn't say.) > > > >Alan Stern > > This was very helpful. > > I was able to get the USB3503 to generate test packets by adding a SetPortFeature(PORT_SUSPEND) request to suspend the port before setting the PORT_TEST feature. Is there a way to tell that a device is a hub but not a root hub so ports on root hub ports aren't suspended prior to calling SetPortFeature(PORT_TEST)? > > I tried to use hub_udev->maxchild to determine if something was a hub but this appears misguided since root hubs can have multiple children, nothing else in the usb_device structure jumped out as being directly related to a hub. That's a perfectly good way to see that the device really is a hub. In addition, if hub_udev->parent == NULL then hub_udev is a root hub, otherwise it isn't. Alan Stern ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-12 20:51 ` Alan Stern @ 2019-09-16 1:11 ` Peter Chen 0 siblings, 0 replies; 11+ messages in thread From: Peter Chen @ 2019-09-16 1:11 UTC (permalink / raw) To: Alan Stern, Allen Blaylock; +Cc: Manu Gautam, linux-usb > > >I should add that the USB 2.0 spec includes the following text (from section > 11.24.2.13): > > > > > > Test mode of a downstream facing port can only be used in > > > a well defined sequence of hub states. This sequence is > > > defined as follows: > > > > > > 1) All enabled downstream facing ports of the hub containing > > > the port to be tested must be (selectively) suspended via > > > the SetPortFeature(PORT_SUSPEND) request. Each downstream > > > facing port of the hub must be in the disabled, > > > disconnected, or suspended state (see Figure 11-9). > > > > > >So you can see the hub probably failed the request because a > > >non-suspended device was connected to port 3. (And who knows what > > >was attached to the other ports -- the usbmon trace doesn't say.) > > > > > >Alan Stern > > > > This was very helpful. > > > > I was able to get the USB3503 to generate test packets by adding a > SetPortFeature(PORT_SUSPEND) request to suspend the port before setting the > PORT_TEST feature. Is there a way to tell that a device is a hub but not a root hub > so ports on root hub ports aren't suspended prior to calling > SetPortFeature(PORT_TEST)? > > > > I tried to use hub_udev->maxchild to determine if something was a hub but this > appears misguided since root hubs can have multiple children, nothing else in the > usb_device structure jumped out as being directly related to a hub. > > That's a perfectly good way to see that the device really is a hub. In addition, if > hub_udev->parent == NULL then hub_udev is a root hub, otherwise it isn't. > Hi Allen & Alan, Good finding. Besides, if you would like to generate a formal patch, per 7.1.20 Test Mode Support, you may support Test_SE0_NAK/Test_J/Test_K/Test_Packet all for non-root hub. The other three test modes should be embedded host required. Peter ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: EHSET with hub and PCIe root hub 2019-09-12 14:20 ` Alan Stern 2019-09-12 14:28 ` Alan Stern @ 2019-09-12 14:29 ` Allen Blaylock 1 sibling, 0 replies; 11+ messages in thread From: Allen Blaylock @ 2019-09-12 14:29 UTC (permalink / raw) To: Alan Stern; +Cc: Manu Gautam, Peter Chen, linux-usb Thank you Alan, I am still working through understanding the usbmon and this is a helpful hint. I will contact the device manufacturer and see if there is some alternative method they recommend for testing. >Most of the usbmon output shows that a device was attached to port 3 of hub 2 and enumerated as usual over the course of about half a second. > >The very last two lines show the computer sending the hub a Set-Port-Test request on port 3 for test mode 4, which is Test Packet. >The hub's response is a STALL, indicating that the hub doesn't understand or doesn't implement this request. > >Alan Stern > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-09-16 1:11 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-10 22:01 EHSET with hub and PCIe root hub Allen Blaylock 2019-09-11 2:57 ` Peter Chen 2019-09-11 3:54 ` Manu Gautam 2019-09-11 20:34 ` Allen Blaylock 2019-09-12 0:49 ` Peter Chen 2019-09-12 14:20 ` Alan Stern 2019-09-12 14:28 ` Alan Stern 2019-09-12 20:32 ` Allen Blaylock 2019-09-12 20:51 ` Alan Stern 2019-09-16 1:11 ` Peter Chen 2019-09-12 14:29 ` Allen Blaylock
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).