lkml.org 
[lkml]   [2008]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"
    Date
    On Thursday, 3 of July 2008, David Woodhouse wrote:
    > 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.

    Still, maybe we can add some kbuild magic to build the blobs along with
    their modules and to install them under /lib/firmware (by default) when the
    modules are installed in /lib/modules/... ?

    Rafael


    \
     
     \ /
      Last update: 2008-07-03 23:55    [W:4.286 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site