On Monday 30 July 2012 22:35:37 Bjørn Mork wrote: > Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> writes: > > On Mon, Jul 30, 2012 at 09:28:36AM +0200, Oliver Neukum wrote: > > - We need to issue a reset resume for all suspended devices that have > > been powered off. > > > > - We can't power off ports with connected devices that require firmware > > (e.g. bluetooth and 3G modems). The firmware would be lost when > > they're reset. > > I don't think that is limited to devices needing firmware. Even modems > with persistent firmware will keep lots of internal state which the > driver cannot re-establish. And even if you could reset the device > state, the mobile network kept some state which also was lost when you > powered off the modem. Sure. Maybe a per driver flag is insufficient and we need an extra attribute like remote_wakeup. > > Possible solutions > > ------------------ > > > > - We need a new interface driver flag to indicate a driver is fine with > > the port being powered off. Something like "supports_power_off". > > May work for some devices. But what are the use cases? Which devices > will work better with such driver support than they will if you simply > unload the driver? uvc, some hid, some storage devices. > > 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. 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
