On Wed, Jul 21, 2010 at 01:53:05PM -0400, Alan Stern wrote: > On Wed, 21 Jul 2010, Sarah Sharp wrote: > > > > 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? Yes, I think we can. Link PM is designed to be handled by the devices on the bus, not software, but there is commands to force devices into lower power link states. SetPortFeature(PORT_LINK_STATE) = U1 or U2. Figure 7-13 shows that if there's a device removal or a reset, then the link state machine transitions back to Rx.Detect from any other state. However, the SetPortFeature(PORT_LINK_STATE) for U1 or U2 will fail if the link isn't in U0 to start with. So we'd have to force the link into U0 first, and then force it into U2. I think we would also have to disable the U1 and U2 timers too, otherwise the device could transition into U1 from U0 before we could force it into U2. This is starting to sound like something that should wait until link power management is in place, though. > > > 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. Ok. We can still talk to the parent hub (or roothub) in that case, so we should be able to send the SetPortFeature command. > > 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. 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
