[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1301869097.2549.36.camel@pasglop>
Date: Mon, 04 Apr 2011 08:18:17 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Detlef Vollmann <dv@...lmann.ch>
Cc: Arnd Bergmann <arnd@...db.de>, 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>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
linux-omap@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Brown <davidb@...eaurora.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
> > * No board files
> Where do you put code that needs to run very early (e.g. pinging the
> watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The generic -> board linkage must not be hard (ie, no
platform_restart, but a board_ops.restart() etc....)
- An average board file is a few hundreds line long, that's it, mostly
it hooks up to generically provided functions, tho it gets the choice of
_which_ ones to hookup.
- It can still quirk/fixup a thing or two if needed, I thinkt it's
useful to keep that around, as long as such "quirks" remain small and
few. At the end of the day, if dealing with one board special case gives
you the choice between changing a ton of infrastructure/core to
introduce a new abstraction to deal with -that- special case vs. having
a one liner fixup in the platform code, the later is the most sensible
option. The hard part of course is to have sensible maintainers to make
sure this doesn't grow back to the old mess.
Cheers,
Ben.
--
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