linux-kernel - Re: [GIT PULL] omap changes for v2.6.39 merge window

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 Apr 2011 04:27:33 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Will Deacon <will.deacon@....com>, Ingo Molnar <mingo@...e.hu>,
	david@...g.hm, Russell King - ARM Linux <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...xnic.net>,
	Tony Lindgren <tony@...mide.com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	lkml <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Brown <davidb@...eaurora.org>,
	linux-omap@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

On Fri, Apr 01, 2011 at 05:55:57PM +0200, Arnd Bergmann wrote:
> On Friday 01 April 2011, Will Deacon wrote:

> > I don't understand how you can handle `early quirks' without board
> > files. Does this follow on from Linus' suggestion about moving code out
> > of the kernel and into the bootloader?

> There are multiple ways of dealing with this. One way would be to
> mandate that the boot loader does the quirks, ideally as little
> as possible.

Though we then get into the issues with bootloader quality and risk 

> Another option is to have a boot wrapper with board specific code,
> which gets run between the regular boot loader and the common
> kernel entry point. We might need such a wrapper anyway to pass the
> device tree to the kernel.

This sounds an awful lot like a board file which doesn't get to use any
of the in-kernel infrastructure like bus controller drivers or chip
drivers to help which feels retrograde.  I understand where you're
coming from on this but an absolute ban feels overly restrictive here,
it seems like we'd be better off allowing board files but pushing back
strongly on anything that should be data...

> > Realistically, I don't think you will ever get away from board files.
> > The trick is probably to make them as small as possible and common to as
> > many boards as possible (like the platforms directory for PowerPC).

> Perhaps. But we can start out with strict rules and add exceptions
> later when we run out of options.

...which is pretty much what you're saying here.
--
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/