[lkml]   [2012]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: loading firmware while usermodehelper disabled.
On Mon, Jan 02, 2012 at 01:27:03PM -0800, Linus Torvalds wrote:

> If we didn't load the firmware before the suspend, then the resume
> function of a device sure as hell had better not load it at resume
> time either.

If the hardware has lost its state then refusing to load the firmware at
resume time isn't going to leave you with a working device.

> And for chrissake, don't bother making it more complicated than it is,
> just for some theoretical hardware or situation that nobody cares
> about.

It's not theoretical hardware. This appears to be the current behaviour
of the isight devices. If you reboot they retain their firmware. If you
suspend, they don't. So if we have a flow like this:

1) user boots from cold. Device comes up with generic USB ID.
2) isight_firmware loads and binds. Firmware is loaded. Device
disconnects and reconnects with an ID that's bound by the UVC driver.
3) user reboots. Device comes up with UVC ID. isight_firmware doesn't
4) user suspends.
5) user resumes. isight_firmware binds and attempts to load firmware.

then just caching the firmware is inadequate - we had never previously
seen the device on this boot, so we've never loaded it in order to cache
it. isight_firmware could unconditionally load the firmware on module
load just in case a device is plugged in, but that seems even less
elegant than caching it.

Now this is obviously somewhat mitigated because isight_firmware won't
have been autoloaded at (3), so won't be there at (5) unless the user's
manually loaded it. But insmodding a driver shouldn't result in stuff
breaking later.

Matthew Garrett |

 \ /
  Last update: 2012-01-02 22:53    [W:0.173 / U:0.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site