[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikfBhCH5wrpYzKbws0F_UVaskhtN_SUGQ+hU8Ab@mail.gmail.com>
Date: Fri, 1 Apr 2011 09:39:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
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, 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 1, 2011 at 8:55 AM, Arnd Bergmann <arnd@...db.de> wrote:
>
> Well, except that because of point 7, device trees are still inferior to
> having correct and complete information in hardware.
Oh, absolutely.
If you have discoverable hardware, use it.
But by "discoverable hardware" I mean something like PCI config
cycles. IOW, real hardware features. Not some code like
if (board_signature_is(xyz)) {
...
that just maps some _other_ hardware knowledge (reading a SoC ID or
something) into an unrelated thing ("I know this SoC has these bits of
hardware").
So devicetree should never override actual "hardware tells me it
exists here". But you might well have a mapping from SoC ID's to a
compiled-in devicetree thing (this is largely what POWER does, iirc).
Linus
--
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