Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

David Woodhouse
2008-07-03T21:33:10Z

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