netdev - 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: <486E2260.5050503@garzik.org>
Date:	Fri, 04 Jul 2008 09:15:12 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, tytso@....edu,
	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"

David Woodhouse wrote:
> On Fri, 2008-07-04 at 12:09 +0200, Andi Kleen wrote:
>> David Woodhouse <dwmw2@...radead.org> writes:
>>> I'll look at making the requirement for 'make firmware_install' more
>>> obvious, or even making it happen automatically as part of
>>> 'modules_install'.
>> Perhaps I didn't pay enough attention, but how are "only 
>> boot bzImage without initrd or modules" setups supposed to work now
>> for those drivers? My testing setup relies on that heavily.
> 
> That will continue to work just fine.
> 
>> Will the firmware automatically end up in initramfs and be included
>> in the bzImage and loaded at the right point?
> 
> No, not even in the initramfs. It's built _right_ into the static kernel
> image, and request_firmware() finds it there without even having to call
> out to userspace at all.
> http://git.infradead.org/users/dwmw2/firmware-2.6.git?a=commitdiff;h=81d4e79a

However, there is still a broken element to the system:  the firmware no 
longer rides along in the module's .ko file.  That introduces new 
problems for any user and script that copies modules around.

The compiled-in firmware should be in the same place where it was before 
your changes -- in the driver's kernel module.

So, yes, there should not be regressions for non-module users.  Let's 
now solve the regression problem for the other half of the world...

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html