From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/3] base board consolidation
Date: Mon, 4 Jul 2011 13:33:01 +0100 [thread overview]
Message-ID: <20110704123301.GE8286@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <201107041355.52025.marek.vasut@gmail.com>
On Mon, Jul 04, 2011 at 01:55:51PM +0200, Marek Vasut wrote:
> Which leads me to a question (likely quite off-topic here). Working on a pxa-
> device tree support, there're a lot of procedures called during init doing
> exactly this -- how do you handle this via device tree ? Is there any way to
> call them ? Or does the kernel need to patch device tree on run-time ? Or how?
That is _precisely_ my concern which caused me to be unconvinced that
DT actually solves the problem which Linus is concerned about.
What I see is that DT solves part of the problem, but we're still going
to end up having board files to deal with procedural stuff which can't
be encoded in DT.
That in turn leads to the problem of how to bind the board specific code
in board files into DT declared devices (that information will likely be
Linux specific and may not be stable between kernel versions, so would
probably require kernel version specific DTs).
I think others (eg Nico) share that view.
If that is how things will turn out, then we've got a far bigger problem
to deal with than that which we started with - and at that point it may
be far easier maintainability wise to fork the kernel from the pre-DT
stage and continue as we have been.
The only reason that I've said yes to DT is through pressure from multiple
directions (including Linus), and I'm willing to see whether it _can_ work.
However, I remain entirely unconvinced, even at this stage.
If it was up to me, then I'd still have DT out of the kernel tree, pending
some real platforms with the issue you raised having been converted to it
so we can see how these problems are addressed.
prev parent reply other threads:[~2011-07-04 12:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 9:44 [RFC PATCH 0/3] base board consolidation Uwe Kleine-König
2011-07-01 9:46 ` [RFC PATCH 1/3] ARM: common abstraction for specifying a baseboard Uwe Kleine-König
2011-07-01 9:46 ` [RFC PATCH 2/3] ARM: imx/mx31moboard: convert to new baseboard handling Uwe Kleine-König
2011-07-01 9:46 ` [RFC PATCH 3/3] ARM: imx/mx31moboard: remove obsolete " Uwe Kleine-König
2011-07-04 8:19 ` [RFC PATCH 0/3] base board consolidation Philippe Rétornaz
2011-07-04 8:27 ` Russell King - ARM Linux
2011-07-04 10:20 ` Daniel Mack
2011-07-04 10:38 ` Russell King - ARM Linux
2011-07-04 11:55 ` Marek Vasut
2011-07-04 12:33 ` Russell King - ARM Linux [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110704123301.GE8286@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).