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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 3 Jul 2008 19:42:12 -0700 (PDT)
To:	David Woodhouse <>
cc:	David Miller <>,,,,,,,,,
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

On Fri, 4 Jul 2008, David Woodhouse wrote:

> David Miller wrote:
>> From: David Woodhouse <>
>> Date: Thu, 03 Jul 2008 19:56:02 +0100
>>> It's wrong to change the CONFIG_FIRMWARE_IN_KERNEL default to 'Y',
>>> because the _normal_ setting for that option _really_ should be 'N'.
>> On what basis?  From a "obviously works" basis, the default should be
>> 'y'.
> I already changed it to 'y'.
>>> What we're doing now is just cleaning up the older drivers which don't
>>> use request_firmware(), to conform to what is now common practice.
>> You say "conform" I say "break".
> You mean...
> 	"What we're doing now is just cleaning up the older drivers
> 	 which don't use request_firmware(), to break to what is now
> 	 common practice."
> ?
> Doesn't really scan, does it?
> Common practice in modern Linux drivers is to use request_firmware(). I'm 
> just going through and fixing up the older ones to do that too.
> (After making it possible to build that firmware _into_ the kernel so that we 
> aren't forcing people to use an initrd where they didn't before, of course.)

has this taken place yet? (and if so, what kernel version first included 
this fix)

>> If it was purely technical, you wouldn't be choosing defaults that
>> break things for users by default.
> Actually, the beauty of Linux is that we _can_ change things where a minor 
> short-term inconvenience leads to a better situation in the long term.

but doing so should not be a easy and quick decision, and it needs to be 
made very clear exactly what breakage is going to take place and why 
(along with the explination of why the breakage couldn't be avoided)

>> Jeff and I warned you about this from day one, you did not listen, and
>> now we have at least 10 reports just today of people with broken
>> networking.
> Out of interest... of those, what proportion would be 'fixed' if they'd just 
> paid attention when running 'make oldconfig', which is now addressed because 
> I've changed the FIRMWARE_IN_KERNEL default to 'y'?
> And how many would be 'fixed' if someone had given me a straight answer when 
> I asked about the TSO firmware, and that failure path no longer aborted the 
> driver initialisation but instead just fell back to non-TSO?
> I'll look at making the requirement for 'make firmware_install' more obvious, 
> or even making it happen automatically as part of 'modules_install'.

I won't mind this as long as I can get a working kernel without doing make 
firmware_install or make modules_install (I almost never use modules, my 
laptop is one of the few exceptions, and even there it's mostly becouse of 
the intel wireless driver needing userspace for firmware)

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists