Re: 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 
bind.
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 | mjg59@srcf.ucam.org