Return-path: Received: from cavan.codon.org.uk ([93.93.128.6]:44165 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752606Ab2ABVui (ORCPT ); Mon, 2 Jan 2012 16:50:38 -0500 Date: Mon, 2 Jan 2012 21:50:28 +0000 From: Matthew Garrett To: Linus Torvalds Cc: Jack Stone , Alan Stern , Oliver Neukum , Dave Jones , Linux Kernel , Larry Finger , Chaoming Li , "John W. Linville" , Greg Kroah-Hartman , USB list , Linux Wireless List Subject: Re: loading firmware while usermodehelper disabled. Message-ID: <20120102215028.GA15701@srcf.ucam.org> (sfid-20120102_225102_285659_C280AB95) References: <4F02165C.1060400@fastmail.fm> <20120102211904.GA15316@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: 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