On Tue, Jul 20, 2010 at 03:47:12PM -0400, Alan Stern wrote: > On Tue, 20 Jul 2010, Sarah Sharp wrote: > > > 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? It seems to cause the device to start using the USB 2.0 bus. Section 7.5 says, "SS.Disabled is a link state where SuperSpeed connectivity is disabled and the link may operate under USB 2.0 mode." and section 10.3.1.9 says "DSPORT.Disabled A port transitions to this state when the port receives a SetPortFeature(PORT_LINK_STATE) SS.Disabled request. In this state, the port’s link shall be in the SS.Disabled state." But I'm trying to figure out if it's equivalent to disabling a USB 2.0 port. Figure 10-19 shows that the only way for a downstream port on a hub to come out of SS.Disabled is for the hub to receive a SetPortFeature(PORT_LINK_STATE) = Rx.Detect request. Section 7.5.1.2 also says "Exit from SS.Disabled: • A downstream port shall transition to Rx.Detect when directed. • An upstream port shall transition to Rx.Detect only when VBUS transitions to valid or a USB 2.0 bus reset is detected." So that sounds like the only way to re-enable a USB 3.0 port is for software to manually enable it. I'm trying to see how that fits in with the statement you made about what happens when a USB 2.0 port is disabled and then a new device is connected to it: "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." By "the host", do you mean the host controller or the operating system? Which initiates the port reset? I'm confused about how the re-connect works with a USB 3.0 hub, since section 7.4.2 says that warm or hot reset is not allowed when the port is in the SS.Disabled state. Perhaps John or someone working on a USB 3.0 hub can help clear up this confusion? > > 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. When a USB 3.0 device is issued a set address command, the route string is used. So it's fine to have multiple USB 3.0 devices using address 0, because the route string is unique per device. (Unless the roothub has more than 15 ports on it, which is unlikely.) So I think it's ok to not disable the port when we want to ignore the device. > 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. In this case, can you just reset the device? Is the device expecting the port to be disabled? > What's the best way to achieve these goals? I have no good answers yet. 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
