On Sat, Jul 17, 2010 at 11:08:31AM -0400, Alan Stern wrote: > 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. Ok. It's more that writing the raw descriptor values is just a pain to get right. No questions, just a lack of enthusiasm to do the task at hand. :-/ > > > 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)? I haven't seen any USB 3.0 hard drives with the type of display you describe, so it would be hard to check. It's also a moot point, since there isn't an official Windows driver for USB 3.0. There is the NEC Windows driver, but that won't be used whenever the official Microsoft driver gets released. I'd say it's up to us to set that policy, for once. As John pointed out, external USB 3.0 hubs don't support disabling of ports. I checked page 10-69 of the USB 3.0 bus spec, and he's right. So it's probably better to treat all USB 3.0 ports (on roothubs and external hubs) as if they can't be disabled. Andiry, what do you think? 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
