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]

Date:	Sun, 06 Jul 2008 11:55:30 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Olivier Galibert <galibert@...ox.com>,
	Takashi Iwai <tiwai@...e.de>, Hannes Reinecke <hare@...e.de>,
	Theodore Tso <tytso@....edu>, Jeff Garzik <jeff@...zik.org>,
	David Miller <davem@...emloft.net>, hugh@...itas.com,
	akpm@...ux-foundation.org, 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"

On Sun, 2008-07-06 at 06:02 -0400, Christoph Hellwig wrote:
> The worst examples are aic7xx/aic79xx and the symbios family of drivers
> where the firmware / driver interface is entirely defined by the driver.
> But as we have opensource firmware for these and build it as part of
> the kernel build I suspect you don't want to convert them to external
> firmware either.

The fact that they're open source changes the technical situation
somewhat, mostly because it means that the firmware is much more likely
to change in step with the driver, and not have a stable ABI. So it
might make a little more sense to ship the firmware _with_ the driver in
those cases. For aic7.xx it's also a bit harder to load it as a discrete
blob, given that we generate C code in the driver which has intimate
knowledge of its internals.

There's still something to be said for keeping it in userspace and
loading it on demand though if we can, though, rather than keeping it in
kernel memory at all times.

I haven't yet come to a firm conclusion about what to do when we get to
those drivers; they're a bit of a special case. 

> aic94xx has a very similar firmware to aic7xx/aic79xx but it's only
> available as blob.  We've alredy required specific firmware versions
> there.

I don't believe we were going to touch that; it already uses
request_firmware(), doesn't it?

And what I think you're referring to is this:

    [SCSI] aic94xx: tie driver to the major number of the sequencer firmware

    The sequencer firmware file has both a string (currently showing
    V17/10c6) and a number (currently set to 1.1).  It has become apparent
    that Adaptec may issue sequencer firmware in the future which could be
    incompatible with the current driver.  Therefore, the driver will be
    tied to the particular major number of the firmware (i.e. the current
    driver will load any 1.x firmware). 

That's quite a good example. It hasn't happened yet but we know that
_if_ the major version changes, we can treat that like an soname bump.
The new firmware will have a new name, and the old drivers can continue
loading the old firmware.

> b43 has two totally different firmware major revisions that even require
> different drivers.

Another one we're not touching because it already uses request_firmware.
And this is one where we've _already_ used the soname trick -- there are
two versions of the firmware, and they each have different paths
in /lib/firmware. So the old and new drivers can happily coexist.

-- 
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/