From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" Date: Thu, 03 Jul 2008 22:33:10 +0100 Message-ID: <486D4596.60005@infradead.org> References: <20080703020236.adaa51fa.akpm@linux-foundation.org> <20080703205548.D6E5.KOSAKI.MOTOHIRO@jp.fujitsu.com> <486CC440.9030909@garzik.org> <486CCFED.7010308@garzik.org> <1215091999.10393.556.camel@pmac.infradead.org> <486CD654.4020605@garzik.org> <1215093175.10393.567.camel@pmac.infradead.org> <20080703173040.GB30506@mit.edu> <1215111362.10393.651.camel@pmac.infradead.org> <486D3E88.9090900@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Theodore Tso , Hugh Dickins , Andrew Morton , KOSAKI Motohiro , mchan@broadcom.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org To: Jeff Garzik Return-path: Received: from casper.infradead.org ([85.118.1.10]:36056 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754231AbYGCVds (ORCPT ); Thu, 3 Jul 2008 17:33:48 -0400 In-Reply-To: <486D3E88.9090900@garzik.org> Sender: netdev-owner@vger.kernel.org List-ID: Jeff Garzik wrote: > David Woodhouse wrote: >> Although it does make me wonder if it was better the way I had it >> originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL >> attached to each driver, rather than a single FIRMWARE_IN_KERNEL option >> which controls them all. > > IMO, individual options would be better. They had individual options for a long time, but the consensus was that I should remove them -- a consensus which was probably right. It was moderately inconvenient going back through it all and recommitting it without that, but it was worth it to get it right... > Plus, unless I am misunderstanding, the firmware is getting built into > the kernel image not the tg3 module? That's right, although it doesn't really matter when they're both in the vmlinux. When it's actually a module, there really is no good reason not to let request_firmware() get satisfied from userspace. If you can load modules, then you can load firmware too -- the required udev stuff has been there as standard for a _long_ time, as most modern drivers _require_ it without even giving you the built-in-firmware option at all. It makes no more sense to object to that than it does to object to the module depending on _other_ modules. Both those other modules, and the required firmware, are _installed_ by the kernel Makefiles, after all. It wouldn't be _impossible_ to put firmware blobs into the foo.ko files themselves and find them there. The firmware blobs in the kernel are done in a separate section (like initcalls, exceptions tables, pci fixups, and a bunch of other stuff). It'd just take some work in module.c to link them into a global list, and some locking shenanigans in the lookups (and lifetime issues to think about). But it just isn't worth the added complexity, given that userspace is known to be alive and working. It's pointless not to just use request_firmware() normally, from a module. -- dwmw2