> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Wednesday, July 21, 2010 2:54 AM > To: Alan Stern > Cc: John Youn; linux-usb@xxxxxxxxxxxxxxx; Xu, Andiry > Subject: Re: [RFC] USB 3.0 Hub Changes > > 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? > I've no objection. USB3 port should not be disabled, unless you want to transition a USB3 port to USB2 port. Thanks, Andiry -- 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
