[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[matt.porter@linaro.org (Matt Porter)]

On Tue, Oct 22, 2013 at 11:39:24AM +0200, Thierry Reding wrote:
> On Mon, Oct 21, 2013 at 04:40:15PM -0400, Nicolas Pitre wrote:
> > On Mon, 21 Oct 2013, Stephen Warren wrote:
> > > I
> > > think we can still have a hack-free, churn-free, multi-platform kernel
> > > without requiring DT, but by using board files.
> > 
> > I kinda agree with you, but this is too late for that now.
> > 
> > We have DT, and the best way forward is to fix the process which is, 
> > arguably, somewhat obstructive and broken at the moment.
> 
> I agree that the process could use some enhancements. But I also think
> that we should be open to move away from DT again if it turns out to not
> be a good enough solution. "It's too late" doesn't sound like a very
> good argument to me.
> 
> Essentially DT is just a different way to represent what we used to have
> in platform data, so we haven't fundamentally changed anything at that
> level. Well, we've made things worse to some degree.

DT started that way. However, the direction set by binding reviews have
essentially limited DT to only external hardware configuration. So, yes,
we've made things worse. DT, as defined and maintained today, does not
replace platform data since it's been de facto limited to a tiny subset
of system configuration info. Further, the current approach to "breaking
compatibility" with old DTBs that has resulted from the claims of "DT as
ABI" is completely tied to the vision of moving DT independent of the
kernel. Platform data in code never had this compatibility issue.

DT has many benefits. It would be great to leverage them as long as it
doesn't interfere with the rate of change and willingness to evolve code
that's always been the strength of the kernel process. That strength is
too valuable to trade away for the "DT as ABI" vision.

All these failings can start to be fixed by addressing the process and
what DT *is*.

-Matt