On Monday 30 July 2012 22:35:37 Bjørn Mork wrote:
> Sarah Sharp <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
