On Fri, 16 Jul 2010, Sarah Sharp wrote: > > > 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. > > I'm not sure how much work would be involved. I did the hub > registration a long time ago. :) I do remember creating the descriptors > was a big pain, and I couldn't figure out how to add additional > descriptors, like endpoint companion descriptors and BOS descriptors. > Haven't had time to look at it, but it was next on my todo list. If you'd like any questions answered, just ask. > > 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; > > Why in this case? I associate "safely remove hardware" with unmounting > and ejecting a USB hard drive. Why would you want to disable the whole > port in that case? This feature was added at the request of some user-interface people. The idea is that some USB devices have little displays, and when a Windows user clicks on the "Safely Remove Hardware" applet the display shows a message like "Okay to unplug". This is triggered when the port gets disabled. It isn't really necessary -- once the device is unmounted you can unplug it perfectly safely. But people like the reassurance of seeing those messages on their little displays; they are used to it. It's not at all clear that this needs to apply to USB-3. Do you know what Windows does to a SuperSpeed port when you click on "Safely Remove Hardware"? Can you find out (for example, by tracing the packets sent between the host and an external hub to which the USB-3 drive is attached)? > You would never see a new device plugged into the > port in that case. Or are you expecting to re-enable the port on a > device connect status change? That's not how it works. The host can't enable ports in any case. (There is no Set-Port-Feature(PORT_ENABLE) request.) What happens is the hub enables the port automatically at the end of a successful reset, and the host resets the port when a connect change occurs. > > 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. A better way to summarize this is: We disable the port when a device is attached but the kernel is unable or unwilling to handle it. The end effect should be for conforming devices to go into a low-power state and for broken devices not to be able to interfere with normal communications. (For example, devices aren't allowed to transmit across frame boundaries. If a device is still in the middle of sending a packet when a frame boundary occurs, its parent hub is obliged to disable the device's port to prevent further wanted traffic. Also, in USB-2 the host is responsible for assigning device addresses. If some device is attached to an enabled port using an address the kernel doesn't know about, it would cause trouble when another device is assigned the same address. This may not be an issue in USB-3.) > Hmm, ok, it does look like we really want to ignore both the USB 3.0 > port and the USB 2.0 port in all these cases (except the safely remove > hardware one which I don't understand). For one case in particular (the device is reset and its descriptors change) we definitely want the device to continue to be available on the SuperSpeed bus, so that we can discover it again and go through the whole enumeration procedure from the beginning. > > I don't know the best way to implement this. Do you have any > > suggestions? > > I think in the above cases, you want to turn off both the USB 3.0 port > and the USB 2.0 port. Which means we have to keep track of the two > separate portions of a USB 3.0 hub (the USB3 portion and the USB2 > portion). Either portion could be enumerated before the other, but I > think it would be simple enough to check if a hub has the Containter ID > BOS descriptor and set a field in struct usb_hub. Then code at the end > of the hub initialization process could check for a matching hub. > > Now, we could see a USB 2.0 hub with a Container ID and never see its > USB 3.0 hub portion, if the USB 3.0 hub is plugged into EHCI, or if a > USB 2.0 cable is used. For now, we can assume we will never see a USB > 3.0 hub portion without its USB 2.0 hub portion showing up shortly > after. (In the future that might change if they decide to say, remove > the USB 2.0 wires entirely from the host controller. But I think that's > probably not likely to happen anytime soon.) It also could happen if various things go wrong. You can make that assumption if you like, but in the end I think we'll be better off avoiding it if possible. > So we could wait a period of time for the USB 2.0 portion of the USB 3.0 > hub to enumerate before we try to enumerate any devices under the USB > 3.0 hub. If the new roothub code is written properly, it would register > the USB 2.0 portion first, then the USB 3.0 portion, so no waiting on > host controller init would be necessary. > > What do you think? You can't depend on this working out so neatly for external hubs. Which means you need to be flexible anyway, so there's no reason to rely on special treatment for root hubs. In general, I'm not sure it will be necessary to wait for both hubs to show up before we start using either of them. 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
