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 20:11:33 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	linux@....linux.org.uk, scottwood@...escale.com,
	devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
	timur@...escale.com, yuan-bo.ye@...orola.com,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, 2009-05-28 at 02:57 -0700, David Miller wrote:
> From: Russell King - ARM Linux <linux@....linux.org.uk>
> Date: Thu, 28 May 2009 10:15:13 +0100
> 
> > For example, how would an IrDA transceiver be expressed in OF?
> 
> As a child device node of the IRDA device, with associated
> properties.
> 
> You can express _ANYTHING_ using the OF device tree.  It is
> not even something to discuss, it's flexible enough.

Well, that example is interesting because you may not want the
transceiver to be a child of the UART :-) The tree hierachy is mostly
about addressing, and addressing below a UART doesn't mean much.

So if the transceiver has a bunch of MMIO registers, it might be better
off located elsewhere, and have the UART have a "fir-transceiver"
property with a phandle to the actual device...

But yes, I definitely agree, it's flexible enough for a lot of that
stuff. Where things get tricky is to express "methods" rather than just
relationships. This is where x86 loses big time with ACPI, Apple lost
with their platform functions in OF properties, and appart from having a
real OF implementation under the hood that is kept alive along with the
kernel to call in, the tree doesn't provide a simple solution.

However, it doesn't either invalidate existing solutions based on
function pointers into the platform code... it might even make it nicer
by naming those functions into some kind of directory where they can be
registered by the platform code and "named" by a property in the node,
though I tend to prefer the approach of having a property with a phandle
to a node that is a pseudo-device ("power-control") or so, which has its
own driver providing the methods.

The possibilities are endless. _BUT_ it does require some careful
thinking to get things right. To that extent, I do agree with Russell
that rather than a "violent" conversion, ARM should first try things out
as an opt-in for a few platforms and see how it goes.

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/