On Wed, Jul 21, 2010 at 05:45:36PM -0400, Alan Stern wrote: > On Wed, 21 Jul 2010, Sarah Sharp wrote: > > > > It's not a big deal, so yes, it can wait. Actually I think we should > > > put the device into suspend, if we can, instead of putting the link > > > into U1 or U2. That would be pretty much equivalent to disabling the > > > port anyway. > > > > Using device suspend in that case is going to need special handling by > > the xHCI driver. Normally, if a device is suspending, the xHCI host > > controller hardware wants to know about it. The xHCI driver has to stop > > all the endpoints on the device with the "Suspend device" bit set. Will > > the device already be deallocated by the time you try to suspend it? Or > > will the struct usb_device still be around when the device is suspended? > > Arggh! Why does everything always turn out to be complicated? When you try to do virtualization in hardware it gets complicated. :) > No, the device structure won't already be deallocated. In fact, it > might not even have been allocated in the first place. One of the > pathways leading to hub_port_disable() is when the memory allocation > for the device structure fails. The xHCI roothub code to suspend a device will just need to have a special case for that. If the struct usb_device isn't allocated, the xHCI host doesn't know about the device and thus won't care if we suspend it. The roothub code should unconditionally suspend the port even if it can't find a slot context that corresponds to that port. 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
