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

On Thu, Oct 24, 2013 at 04:33:39PM +0200, Maxime Bizon wrote:

On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:

quoted

We treated DT the same way we had treated platform data before, which
has inevitable lead to the current mess, which is only slightly better
than what we used to have. 

Side question, in your point of view, how is that better ?

The representation of the data may not be all that much better. But as a
side-effect of the whole DT shebang we've made improvements in many
other areas as well. Granted, we could've done that without DT too, but
DT was a pretty good motivator.

I also think that during the conversion of platform data to DT we've
made attempts to make the representation more generic and introduce
common or standard properties. So on the whole I think we have managed
to unify many things, which I think is a good thing.

current DT tools are not able to validate a file wrt its schema, so for
now we just moved platdata to DTS files and lost compiler type checking
in between.

There's been talk about fixing that. I guess it might have been better
if we had had such a tool two years ago, but I certainly hadn't thought
about it before, so who am I to blame anyone else for not writing it.

I respectfully understand people fighting for *stable* DT because I see
the benefits behind this, even if IMO they absolutely do not outweigh
the pain.

But I fail to see any benefits of "forever unstable" DT, if you have to
tie the kernel tree with a DTB file, the description could have been
left in C code.

Well the longterm goal certainly is to separate both, and keeping both
in lockstep was a means of easing the initial conversion. There's
certainly a lot of pain, but I also think that whatever we had before
just didn't work out so well. If it had all been sunshine and lollipops
then there wouldn't have been a need to change anything, right?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/2486e105/attachment-0001.sig>