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: <486D6DDB.4010205@infradead.org>
Date:	Fri, 04 Jul 2008 01:24:59 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Miller <davem@...emloft.net>
CC:	tytso@....edu, jeff@...zik.org, 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 Miller wrote:
> From: David Woodhouse <dwmw2@...radead.org>
> 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.)

The word for that is definitely 'conform'. I know you don't _like_ the 
modern accepted practice, but that's _your_ windmill to tilt at. I have 
my own :)

>> In the meantime, it would be useful if Jeff would quit throwing his toys
>> out of the pram on that issue and actually review the _code_ changes. In
>> particular, are the reports correct that the device operates just fine
>> without the TSO firmware loaded? Should we change the request_firmware()
>> error path to just disable TSO and continue with the initialisation?
> 
> No!
> 
> The 5701 A0 firmware is necessary to load in order to work around
> hardware and existing firmware bugs on those cards.  It's an issue of
> basic functionality, not just optimizations.
> 
> 5701 A0 tg3 chips cannot operate at all without the firmware being
> present in the driver.
> 
> Therefore, if you can't load the firmware, the card is not going to
> work.

Neat avoidance of question there... it was fairly clear that the 5701_A0 
firmware was going to be mandatory; I was asking about the TSO firmware.

Does anyone _else_ actually want to give a straight answer to a simple 
question? Someone who wouldn't have to follow it with an apology because 
of all their shouting about 'breakage' when the firmware in question is 
actually optional anyway, perhaps?


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

 > 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'.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ