[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201209101013.16697.arnd@arndb.de>
Date: Mon, 10 Sep 2012 10:13:16 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Lee Jones <lee.jones@...aro.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com
Subject: Re: [PATCH 00/19] First HREF Device Tree enablement patch-set
On Monday 10 September 2012, Linus Walleij wrote:
> Basically that was at a point when we were changing a lot of
> subsystem trees with DT patches that were merged in out-of-order
> fashion.
>
> Then it's better to have the DT changes to be pushed
> separately at the end of the merge window after all subtrees
> with dependent changes are merged. (Or even in the next merge
> window if there is no hurry, but we always seem to be in a hurry...)
>
> If all the changes are in the same subtree (like ARM SoC with
> ACKs from all over the place where needed) you can do it
> this way instead, and I agree it looks better.
I think we're talking about different things:
I think it's fine to do the device driver conversion separately
from the platform changes, but doing that properly means that the
platform changes should only go in after the drivers have changed.
Inside of the platform code, I absolutely think we should change the
board file and the dts file simultaneously. When the driver offers
two ways of probing a device, this lets us change from one way to
the other without going through a phase where we use neither of them
or (worse) both at the same time.
Arnd
--
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