On Tue, 20 Jul 2010, Sarah Sharp wrote: > > 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. :-/ I know what that's like! :-) > > 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. You don't need a device with a display -- just a way to trace the packet contents, like a bus analyzer. Although without a USB-3 driver for Windows, you won't have any packets to trace... > 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. Well, maybe you can determine what the NEC driver does. > 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. What about the Set-Port-Feature(PORT_LINK_STATE) SS.Disabled request mentioned in 10.3.1.9 and 10.14.2.10? Does this cause the device to start using the USB-2 bus? > So it's probably better to treat all USB 3.0 ports (on roothubs and > external hubs) as if they can't be disabled. Undoubtedly. To the greatest extent possible, root hubs should be treated the same as external hubs. This still leaves open some of the other cases. They seem to fall into two categories: We want to ignore a device. Is it okay just to leave the port alone? In USB-2 it isn't, because of the possibility for address conflicts. Isn't this true in USB-3 also? What happens if there's more than one device using address 0? Also, it would be good if whatever we do forces the device to go into a low-power state. We want a device to be re-enumerated because of a firmware change. This is really much the same as the first case, although now we don't care about low-power states since the device is going to accessed again in the near future. What's the best way to achieve these goals? 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
