On Thu, Dec 30, 2010 at 05:05:34PM -0500, Alan Stern wrote: > On Thu, 30 Dec 2010, Sarah Sharp wrote: > > > On Thu, Dec 30, 2010 at 12:24:16PM -0500, Alan Stern wrote: > > > In the meantime you could disable autosuspend for USB-3 hubs: add a > > > check before the usb_enable_autosuspend() call in hub_probe(). > > > > It seems like I should also disable autosuspend for other USB 3.0 > > devices. > > Or just for SuperSpeed devices. Are there any such devices for which > autosuspend is enabled by default? No, there's not. All the USB 3.0 (SuperSpeed) devices I know of are mass storage devices. Userspace would have to enable autosuspend for those. > > Should I refuse to set the level to auto when power/control is > > written for a USB 3.0 device? > > You can't; that would require modifications to the PM core. Ok. Well, users will see a lot of failed attempts at autosuspend in dmesg if userspace enables it, but it should be harmless if the USB 3.0 devices stall the older PM control transfers. > > Perhaps with a warning in dmesg that USB > > 3.0 device suspend is not supported yet? > > You could put a WARN_ONCE() at an appropriate spot. Be careful not to > trigger the warning when a root hub is suspended. What about system > suspend? Yeah, system suspend might be an issue. It wasn't an issue before, because the xHCI driver would just do the right thing for the USB 3.0 devices connected to the roothub. But system suspend probably won't work when the user has a USB 3.0 device attached to a USB 3.0 hub. However, since USB 3.0 hubs aren't widely available, I don't feel bad about fixing it later. > > > Still, is there any simple way to put the entire device, including all > > > its functions, into a low-power suspend state? > > > > Yes. You can put a device into device suspend (U3) without explicitly > > suspending all its functions, although the mechanisms are slightly > > different than USB 2.0. We could also suspend all the functions and > > then put the device into U3. (Suspending all the functions does not > > trigger the device to go into U3 automatically.) <snip> > > The only tricky part would be if we chose to suspend all the functions > > before putting the device into U3. The functions that didn't signal the > > remote wake would still be in a low power state after the device resume, > > so we would have to wake them up. At this point, I'm not clear whether > > they should be woken up with a SetFeature FUNCTION_SUSPEND > > message, or a Clear Feature FUNCTION_SUSPEND message. The spec is not > > very explicit in section 9.4.1 and 9.4.9. > > For now I think it will be best to avoid suspending individual > functions. Yes, I think so too. 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
