Return-path: Received: from out5.smtp.messagingengine.com ([66.111.4.29]:58910 "EHLO out5.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752792Ab2ACMTU (ORCPT ); Tue, 3 Jan 2012 07:19:20 -0500 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 89CCC2070C for ; Tue, 3 Jan 2012 07:19:19 -0500 (EST) Message-ID: <4F02F244.6040902@fastmail.fm> (sfid-20120103_131944_138496_6E5E05C2) Date: Tue, 03 Jan 2012 12:19:16 +0000 From: Jack Stone MIME-Version: 1.0 To: Oliver Neukum CC: Alan Cox , Matthew Garrett , Linus Torvalds , Alan Stern , 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. References: <4F0220F5.30309@fastmail.fm> <20120103004220.084d61f3@pyramind.ukuu.org.uk> <201201031257.47265.oliver@neukum.org> In-Reply-To: <201201031257.47265.oliver@neukum.org> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 03/01/12 11:57, Oliver Neukum wrote: > Am Dienstag, 3. Januar 2012, 01:42:20 schrieb Alan Cox: >> In that case however you don't want some generic firmware module knowing >> all this crap, your driver can just request_firmware() the stuff as >> modprobe and free it up on the module unload. For a typical 8bit firmware >> of a few K you'll free a ton more memory unloading the module than the >> firmware ! That I think actually covers the majority of devices under >> discussion. > > I am afraid it doesn't, at least not fully. > We have many devices whose primary (operational) driver does not load > the firmware. That job is left to a secondary driver or user space. > > We could leave those secondary drivers and their firmware in RAM after > their primary usage and except for a few pathological cases (which > can be solved with a few udev rules preventively loading drivers) we'd > be good, but we lack a mechanism for switching to a seconary driver > and back during resumption. You don't mension the bus used so I'm going to use USB as an example. As I understand it the majority of devices that need firmware have two different identities: the "bootstrap" id and the "primary" id. If we always make sure we have the drivers for both bootsrap and primary ids loaded then we should have the firmware in memory. If the device has lost its firmware then it will reregister with the bootstrap id otherwise it will continue with the primary id. Either way the correct driver should pick it up and handle it. That said, I guess there are more complicated / difficult pieces of hardware that might not do that. Is that the case here? Can we detect that the firmware needs reloading and have the primary driver "yield" to the firmware driver? Thanks, Jack