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
