Re: EHSET USB testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Felipe and Peter,

On Wed, Aug 07, 2019 at 10:47:49AM +0300, Felipe Balbi wrote:
> Peter Chen <peter.chen@xxxxxxx> writes:
> >> (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.
> 
> The thing is that we need to enable certification test as well,
> otherwise we will never have a chance of getting linux products with a
> USB-IF logo out of vanilla mainline tree.

Absolutely. USB-IF testing is important to us and our customers, so we
would definitely like to continue working towards a solution.

Peter - you are saying that it is not possible to enter test mode, but
your explanation is unclear to me. Could you please elaborate as to why
you think this is not possible? The only issue I can see is that I'm
missing a patch that enables SetPortFeature(TEST_MODE) (see below, and
Mathias's response to this thread), but I would like to know if there
are other issues that I am not yet aware of.

> Seems to me that the only thing missing is a way to enter a particular
> test mode based on VID/PID pair.
> 
> All the functionality is already in place, just this little extra hook
> is missing.

Yup! Mathias posted a nice walkthrough of the xhci_hub_control logic
that should respont to SetPortFeature(TEST_MODE), but the kernel I am
using, 4.9.115, is missing a patch.

Cheers,
Rob Weber



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux