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]

Date:	Thu, 28 May 2009 18:10:58 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Scott Wood <scottwood@...escale.com>,
	Peter Korsgaard <jacmet@...site.dk>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, 2009-05-27 at 20:29 +0100, Russell King wrote:
> 
> 
> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?

Yes. Anything. Basically just a bunch of named properties with
arbitrary content in the nodes for the various devices.

> If you're going to say yes to all that, I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

I'm not sure about the question. If it's about identifying which
instance of a device is using the data, it's basically easy since
you used that device-node to create the device in the kernel in
the first place, so you just stick that node pointer into the
achdata as we do on powerpc and can use it to retrieve all the
properties.

If you are talking about different drivers for the same device,
well we try to define bindings such that they describe the hardware
itself in a way that is reasonably agnostic to whatever driver will be
used... 

> I assume you have some kind of compiler, which needs a set of
> specification files to tell it what's required for each driver which
> is OF compatible. If not, I can see no way for OF trees to ever be
> safe and correct.

No, the format at boot time is a flattened tree of nodes with arbitrary
named nodes containing other nodes and named properties (names are
ASCII) and properties have arbitrary binary content.

_Bindings_ define what to put in these things for various bus and device
types, and we do have a compiler, dtc, that goes from a C-like textual
representation and generates the blob.

It makes it easy to create properties that contains strings, numbers,
phandles (references to other nodes), etc...

Cheers,
Ben.

--
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/