linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090528030233.GD1464@yookeroo.seuss>
Date:	Thu, 28 May 2009 13:02:33 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	Timur Tabi <timur@...escale.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:
> On Wed, May 27, 2009 at 09:39:30AM -0500, Timur Tabi wrote:
[snip]
> - The whole concept is based on the assumption that bindings are defined
>   *once*, then never to be changed again. As this is not true (check
>   MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>   of new kernels not working on old bootloaders any more. Is there a
>   solution of this problem? I have not seen a good idea how to avoid the
>   constant change in definitions.

That's true in the ideal, but doesn't break down completely in
reality.  Sure, you want to *aim* for a binding which never needs
updating, but in practice of course, you do need to change it.  When
you do, you end up with backwards compatibility code in the kernel or
the firmware or both to handle both "old" and "new" variants of the
device tree.  It's not perfect, but it still results in substantially
*less* accumulated cruft than we had before.

> - The oftree layering is fundamentally broken. We already have a sane
>   abstraction for arbitrary hardware in the kernel: platform devices.
>   Why not instanciate platform devices from a generic oftree core?

You're conflating the concept of the device tree structure with the
way we instantiate of_platform devices.  As Grant says, the actual
passed in device tree is just a data structure.

You're correct that the layering for the handling of the of_platform
bus and of_platform devices is fundmentally broken, although in
practice it works a lot less badly than it does in theory.  I've been
meaning to get around to replacing this with a saner structure (using
a table of constructor functions to instantiate platform devices or
others from the device tree information), but haven't had time yet.

> - Platform data makes it possible to store function pointers. There
>   is no equivalent to this concept in oftree-land.
> 
> oftree could be a great tool if these things would be resolved.
> Currently they are not, and in result, ARM just works and is easy,
> whereas on PowerPC systems people often spend more time working on
> binding stuff than on the actual functionality.

I think that was true in the early days when everyone was getting the
hang of the device tree.  It's becoming less and less true.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/