On Wed, 21 Jul 2010, Sarah Sharp wrote: > > Looks like you're right. (And it _really_ looks like the USB 3.0 spec > > is wayyyy over-complicated...) > > Yeah. I just closed my ears and went "la la la" whenever the link > chapter folks started talking. They would go on for ages. I know the feeling. In those situations I usually end up falling asleep, or wishing I could. > > > 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. > > > > Of course, it would be necessary to insure that we never send any > > request other than Set-Address to a device using address 0, unless that > > request also uses the route string. What about the possibility of > > multiple devices using some address other than 0? > > All transfers are routed over the USB 3.0 bus, so they could do link > power management properly. In looking over the link section, the only > headers that don't contain routing info are link management packets, and > those are only sent directly between an upstream and a downstream port > (and are consumed by the recipient). There's no routing for the > isochronous timestamp packet, but that's routed through all links that > aren't in a low power state, not to a particular device. > > So a transfer is always routed to a particular device based on the route > string. Okay, good. Could we put the link into a low-power state instead of disabling it? Ideally, a state from which it won't return to full power until there's a disconnect or a reset? > > Reset alone would be enough. The port doesn't have to be disabled, > > _provided_ you don't mind the idea of a live device using an address > > the kernel has forgotten about. With USB-2 we _do_ mind. > > In the cases where the kernel wants to ignore the device, does it > deallocate the device structure? Yes. > If so, the USB core will call the host > controller's free_dev() function, and xHCI host controller will mark > that device address as being free. The next device that gets plugged > in might get that address. But the route string should be different, so > the misbehaving device should never see packets for its old address. > I think we're fine if USB 3.0 ports never get disabled. Right. As long as we know what we're doing and have a good reason for it, that's acceptable. 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
