On Thu, 15 Jul 2010, Sarah Sharp wrote: > > I really don't like the approach taken by this patch. IMO it would be > > much better to fix xhci-hcd, to make it register both a high-speed root > > hub and a SuperSpeed root hub. That should be the first step. > > > > Then this work would be simpler. All those tests for root hubs could > > be removed, because now you would support external hubs too. > > Yes, this is true. The dual USB 3.0/2.0 roothub was just a hack. How much work would be involved in fixing this? It doesn't seem like it would have to be all that big. The driver would need to register two usb_hcd structures and store pointers from one to the other. And of course the various hub callback routines would have to be aware of all this. But not much else has to change. > > > - if (!hub->error) > > > + if (!hub->error && !hub_is_superspeed(hub->hdev)) > > > ret = clear_port_feature(hdev, port1, USB_PORT_FEAT_ENABLE); > > > > What's the reason for this? Can't we disable SuperSpeed ports? What > > if we _need_ to disable the port? > > Disabling a USB 3.0 port just turns off the SuperSpeed terminations. > Since the USB 3.0 hub silicon and the USB 2.0 hub silicon are separate > in external USB 3.0 hubs, and disabling the USB 3.0 port does not turn > off the USB 2.0 port. The device will then attempt to enumerate as a > High Speed device. Disabling the USB 3.0 port doesn't have the same > effect as disabling a USB 2.0 port. You're just going to kick the > misbehaving device down to the USB 2.0 hub. > > Plus, once a SuperSpeed device is enumerated as a high speed device, it > won't check for a SuperSpeed connection until it gets a port reset on > the USB 2.0 port. I think that when a port reset fails, the USB core > tries to disable the port, and then re-enable it. But if the SuperSpeed > device switches to High speed when the port is disabled, and it is > enumerated before the SuperSpeed terminations are enabled, it will stay > as a High Speed device instead of being kicked over to SuperSpeed. > > So it's a bit complicated, and I'm not quite sure how to fix it. A > start would be to have code to match the two parts of the USB 3.0 hub > (the USB 3.0 hub "device" to its related USB 2.0 hub counterpart). > Fortunately the hub provides a "Container ID" in a binary object store > descriptor that must be the same for the USB 3.0 hub silicon and the USB > 2.0 hub silicon. It's required to be globally unique across all hubs, > but I'm not sure if the certification tests are going to look for this > (and thus if the Container ID will be ignored like the serial number in > the device descriptor). > > So, given that disabling the port will just kick the device into High > Speed, is that really what the hub code wants to do? Let's see. The hub driver calls hub_port_disable() under several different circumstances: When device initialization fails (the end of hub_port_init); After any other failure related to device initialization (e.g., unable to allocate memory for a usb_device structure); When a bus-powered hub is detected beneath another bus-powered hub; When a newly-detected device can't be registered with the driver core; If a suspended port gets a remote-wakeup request but there is no device registered beneath the port (probably can't ever happen in real life); When the "remove" (safely remove hardware) sysfs attribute is written to; When a suspended device can't be resumed; When a device is reset and it can't be reinitialized or its descriptors are found to have changed. I guess you could summarize these as: A device is physically attached to the port but we want to pretend it's not there. As far as I can see, in almost all of these cases we don't want the device falling back to high speed. About the only case where we _would_ want it is if the device can't operate properly at SuperSpeed, and there's already a special callback for that (relinquish_port -- although it applies only to root hubs). I don't know the best way to implement this. Do you have any suggestions? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
