> Hi Everyone, > > (Pinging Mathias regarding xHCI support of the USB 2.0 test modes) > > On Mon, Aug 05, 2019 at 02:07:23PM +0800, Peter Chen wrote: > > On Sun, Aug 4, 2019 at 10:45 AM Evan Gates <evan@xxxxxxxxxxx> wrote: > > > > > > I'm trying to get my device to pass the EHSET tests. I found the > > > thread "Using EHSET module" from March. I'm having similar issues. > > > > > > I don't have access to the PID VID board that the lab uses. Instead > > > I'm using another computer setup as a mass storage gadget but set > > > the VID:PID to 1a0a:0102 (TEST_J). If that sounds like a problem or > > > there is another, better way to do this please let me know. > > > > > > > The usb-storage driver bound to your device first. Try building a > > > > kernel without that driver and then it shoudl bind to the other driver. > > > > > > > > Or manually bind the ehset driver to your device through sysfs. > > > > Read up on the documentation for the "new_id" and "bind" and > > > > "unbind" sysfs files for how to do that. > > > > > > I did this. I was able to unbind from usb-storage but binding to > > > usb_ehset_test failed with error -32 (AFAICT EPIPE). I tried both > > > the usb_ehset_test/bind and usb_ehset_test/new_id methods. In both > > > cases I got the same error. > > > > > > I did another build without usb-storage. Now I don't have to go > > > through the unbind step but I still get the same error while probing. > > > > > > [ 296.089877] usb 1-1: new high-speed USB device number 2 using > xhci_hcd > > > [ 296.271081] usb_ehset_test: probe of 1-1:1.0 failed with > > > error -32 > > > > > > I notice that it says "using xhci_hcd." Is that a problem? Does it > > > need to be ehci? I tried a build without xhci but that caused other > > > problems for me. > > > > > > 1) Can I use a computer in device mode to present a VID:PID to get > > > into EHSET mode? If so how should I do that? > > > > > > > Afaik, you can't. No Host computer will act as USB device. You may try > > to configure your box as USB device mode, for gadget driver, you could > > using legacy g_zero module, or source_sink function using configfs. > > > > > 2) What else do I need to do in order to get my box into EHSET mode? > > Only thing is your box need to be at host mode. For testing USB2 for > > xHCI, the mainline code should not support > > TEST_SINGLE_STEP_SET_FEATURE at my last access. > > Today I was able to get access to a PID/VID test fixture that is used in USB 2.0 > EHSET testing. Some of the major findings include: > > 1. The only test mode that works properly is > TEST_HS_HOST_PORT_SUSPEND_RESUME. All other probes of the ehset > module > fail with errno -32 as shown above. This test mode is likely the only > one to work because it does not set the PORT_FEAT_TEST feature for the > appropriate port, but rather sets and clears the PORT_FEAT_SUSPEND feature. > > 2. The same issue was observed on not only our custom hardware, but also > a Dell XPS 13 running Ubuntu 18.04 with kernel version 4.15. I've > attached the dmesg logs with xhci_hcd dynamic debug enabled for both > hosts. The logs were captured while testing the TEST_PACKET test > mode, but the logs looked similar for every other rest mode besides > HS_HOST_PORT_SUSPEND_RESUME. > > > Mathias, I would appreciate your feedback on the attached dmesg logs with > xhci_hcd dynamic debug enabled. If you have a moment, could you please take a > look at the logs and let me know if there are any clues as to why the test mode is > not working with xhci_hcd? I've also attached the lsusb output for this particular > EHSET test fixture made by Allion. > > I've been digging into the xHCI specification to see what details it might contain > about the USB 2.0 test modes we are trying to use. > Section 4.19.6 describes the proper sequence for enabling the USB 2.0 port test > modes. This requires setting the appropriate bits in the USB > 2.0 PORTPMSC register, which is described in full detail in section 5.4.9.2. It's clear > that xHCI should support the EHSET test modes, but we're not able to set the > appropriate port features for some reason. > > My next thought is to double-check the logic of the ehset driver as it relates to > xhci_hcd. I would like to make sure that we are enabling the USB 2.0 test modes > according to the xHCI spec. I'm concerned that we might be experiencing an error > because we aren't setting the test mode acording to section 4.19.6 of the xHCI > specification. > > Thanks in advance for reviewing the logs, Mathias! I appreciate any time and > feedback you may be able to provide. Let me know if you have any further > questions or need more information from me. I look forward to hearing from you > soon! > You may not enter test mode at all. Check flow: xhci_hub_control->xhci_enter_test_mode. Peter
