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