From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756319Ab2IEOB1 (ORCPT ); Wed, 5 Sep 2012 10:01:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42668 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978Ab2IEOBZ (ORCPT ); Wed, 5 Sep 2012 10:01:25 -0400 Date: Wed, 05 Sep 2012 16:01:23 +0200 Message-ID: From: Takashi Iwai To: Alan Cox Cc: Ming Lei , Greg Kroah-Hartman , "Rafael J. Wysocki" , Kay Sievers , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: A workaround for request_firmware() stuck in module_init In-Reply-To: <20120905140304.5c5c58a4@pyramind.ukuu.org.uk> References: <20120905140304.5c5c58a4@pyramind.ukuu.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 5 Sep 2012 14:03:04 +0100, Alan Cox wrote: > > > If the driver is built in kernel, the request_firmware in .probe() may > > prolong kernel init, and it might be a problem. But looks it is not a > > big deal since most of drivers are built as module. > > Doing it by deferring the load also fixes that. The built in ones will > defer their final probe until the firmware appears and all will be well. > > If your rootfs needs firmware not in your initrd you already broke it and > there is a certain level beyond which you just have to give up trying to > save people from themselves. > > It may actually make sense to push more of it into the core driver layer > and take some of the ability to make mistakes away from driver authors. > For the general case of "load firmware if we see one" there isn't really > any reason we can't have a firmware_name entry in the probe table > entries themselves. If that was present the core bus probe would kick a > firmware load off and only when the firmware had loaded would it call > ->probe with dev->firmware pointing at a refcounted firmware struct. > > At that point it should be much faster to fix existing drivers and much > harder for a random device driver to get it wrong. We can even add > helpers which manage dev->firmware, and free the relevant objects when > needed, plus doing automatic ref/deref on probe/remove so that for a > typical driver the author only has to do > > {PCI_blah , ... .firmware_name="wibble500.xcr", } > > and all the loading, unloading, not loading twice happens by "magic" for > the driver author. > > Add a dev_discard_firmware() for drivers that do this and know they can > then dump the file and all is good 8) This sounds like an interesting idea. I guess majority of drivers can be covered by this scenario. Of course, there are a few drivers that need more complex handling (e.g. iwlwifi handles fallback fw loading), but they can be implemented manually if needed anyway. Takashi