linux-kernel - Re: [bug?] tg3: Failed to load firmware "tigon/tg3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <486D4596.60005@infradead.org>
Date:	Thu, 03 Jul 2008 22:33:10 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Theodore Tso <tytso@....edu>, Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	mchan@...adcom.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/