On Thu, Jul 15, 2010 at 07:39:37PM -0400, Alan Stern wrote: > On Thu, 15 Jul 2010, John Youn wrote: > > > Made some changes to work with superspeed hubs: > > - Added new constants in header > > - Changes for new superspeed hub descriptor > > - Set the hub depth after enumeration > > - Modify the port status bits from the hub > > > > Signed-off-by: John Youn <johnyoun@xxxxxxxxxxxx> > > --- > > Hi Sarah, > > This is our latest patch for 3.0 Hubs. Now applies to 2.6.35. > > 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. > > + } > > + > > ret = 0; > > } > > mutex_unlock(&hub->status_mutex); > > @@ -607,7 +629,7 @@ static int hub_port_disable(struct usb_hub *hub, int port1, int set_state) > > if (hdev->children[port1-1] && set_state) > > usb_set_device_state(hdev->children[port1-1], > > USB_STATE_NOTATTACHED); > > - 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? Sarah Sharp -- 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
