EHSET with hub and PCIe root hub

EHSET with hub and PCIe root hub

[Allen Blaylock]

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

Re: EHSET with hub and PCIe root hub

[Peter Chen]

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&amp;data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&amp;sdata=djXerGrLCkeITKRqg4KteuzNn5TMxeOhqif58DWJYUE%3D&amp;reserved=0
> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fusb.org%2Fsites%2Fdefault%2Ffiles%2FHSETT_Instruction_0_4_1.pdf&amp;data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&amp;sdata=gem9tyxRAWIppDFW%2Fpw08dPKqQQ9NMX%2BhH19V2SloiQ%3D&amp;reserved=0
> 

-- 

Thanks,
Peter Chen

Re: EHSET with hub and PCIe root hub

[Manu Gautam]

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&amp;data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&amp;sdata=djXerGrLCkeITKRqg4KteuzNn5TMxeOhqif58DWJYUE%3D&amp;reserved=0
>> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fusb.org%2Fsites%2Fdefault%2Ffiles%2FHSETT_Instruction_0_4_1.pdf&amp;data=02%7C01%7Cpeter.chen%40nxp.com%7C370e9acddb11494ec68008d7363a93fa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637037497528612416&amp;sdata=gem9tyxRAWIppDFW%2Fpw08dPKqQQ9NMX%2BhH19V2SloiQ%3D&amp;reserved=0
>>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: EHSET with hub and PCIe root hub

[Allen Blaylock]

>
>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

RE: EHSET with hub and PCIe root hub

[Peter Chen]

 
> >>>
> >>> 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

RE: EHSET with hub and PCIe root hub

[Alan Stern]

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

RE: EHSET with hub and PCIe root hub

[Alan Stern]

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

RE: EHSET with hub and PCIe root hub

[Allen Blaylock]

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
>

RE: EHSET with hub and PCIe root hub

[Allen Blaylock]

>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,

RE: EHSET with hub and PCIe root hub

[Alan Stern]

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

RE: EHSET with hub and PCIe root hub

[Peter Chen]

 
> > >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