On Tuesday 31 July 2012 09:09:06 Bjørn Mork wrote: > Oliver Neukum <oneukum@xxxxxxx> writes: > > On Monday 30 July 2012 22:35:37 Bjørn Mork wrote: > >> Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> writes: > > uvc, some hid, some storage devices. > > I don't know anything about storage devices, but forcing them to power > off sounds scary to me. If that can be done safely with driver support > then I guess that's a good reason, yes. Powering off storage devices is scary. However, we do exactly that when we go to S4. > For uvc and hid: What's the advantage with driver support compared to The system, including all devices, stays fully functional. > just unbinding? When it comes to hid I would assume that most such > devices need remote wakeup to be able to sleep at all? Depends on whether they are open. You can power down stuff like joysticks that are not in use. With the help of user space we could also power down internal touchpads and keyboards while the lid is closed. > >> > 2. If the device is internal and suspended, power off the port if all > >> > the following are true: > >> > > >> > a) all interface drivers have supports_power_off set, or no > >> > interface drivers are bound and usbfs has not claimed the > >> > device. > >> > b) remote wakeup is disabled > >> > c) USB_QUIRK_RESET_MORPHS is not set > >> > >> Why can't that be a userspace decision? I.e. drop all this policy in > >> the kernel stuff, and just implement: > > > > We cannot. User space doesn't know and cannot know when remote wakeup > > is needed. > > So? Return an error. It's not like you are going to guarantee this > operation will succeed anyway. Or if you worry about being able to We don't guarantee any IO to succeed. That's no excuse to not try. > power off the port as soon as possible: Replicate the autosuspend > functionality, with userspace controlled enable and delay instead of > making it an on/off switch. User space cannot control auto resume. It is fundamentally impossible. You will deadlock sooner or later. Devices must be resumed by the kernel as soon as they are needed. Otherwise they must be totally closed. User space can power off devices. We can already do that by control messages and could extended the code for root hubs to use ACPI methods. That is beside the point for this discussion. > But please put the control of which ports to enable this feature for in > the hands of the user. Definitely, with very few exceptions. Regards Oliver -- 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
