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 for Android: free password hash cracker in your pocket

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

Message-ID: <fa686aa40905271322x2f62c3dcs355374b30b4db3ca@mail.gmail.com>
Date:	Wed, 27 May 2009 14:22:50 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Timur Tabi <timur@...escale.com>,
	Jon Smirl <jonsmirl@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 1:39 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...osoft.com> wrote:
> On 20:21 Wed 27 May     , Russell King - ARM Linux wrote:
>> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
>> > On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@...escale.com> wrote:
>> > > I'm not talking about platform specific code, I'm talking about code to
>> > > retrieve information about a device from the device tree.  There would not
>> > > be separate instances of this for "platforms X, Y and Z", just one
>> > > of_platform binding in each driver.  It's no different than having a
>> > > platform bus binding, except in the data structures used.
>> > >
>> > > But to restate, having external glue to create platform devices from the
>> > > device tree is fine if that's what you want to do.  We used to do that, but
>> > > it was a pain compared to keeping everything in one place.  Your experience
>> > > may differ.
>> >
>> > Could 'struct platform_device' and 'struct of_platform_device" be
>> > unified into a single structure? It's personal preference whether the
>> > internal representation of the hardware is done via a device tree or
>> > snippets of platform code, but do we need to have to different device
>> > types?
>>
>> That's a damned good question - platform devices have been around since
>> the dawn of the device model, so the real question which needs to be
>> asked is: what was the reason that of_platform_device created rather
>> than unifying it with the already provided platform_device ?
> I agree at 100%
>
> when you have to support the same driver for non OF and OF platform it's
> really a pain in the ass

There are two issues that keep the of_platform and platform busses
separate.  They aren't show stoppers, but they reflect the current
state.

1) Source of data: a platform_device carries a pdata structure with it
to describe the hardware.  An of_device carries a device_node pointer.
 Before dropping of_platform bus, a mechanism needs to be in place to
add hooks for translating the device tree data into a pdata structure
for each platform device.

2) Driver binding mechanism:  device tree nodes usually have a
"compatible" property which is a list of strings.  The first string
describes exactly what the device is (ie. "atmel,24c08") and an
optional list of other devices which it is register interface
backwards compatible with.  The intent is that newer devices can claim
compatibility with older ones so that existing device drivers will
work without needing to be told the new device name.  However, it
leaves the option when a device errata or something similar raises
it's ugly head, a driver can still get information about the exact
device name and apply the appropriate workarounds.  Driver probing
should walk the list and give preference to higher priority compatible
values.  of_platform bus does this, but I cannot think of a clean way
to do the same thing with the platform bus.

One option that has been suggested (more than once) is to make the
adapter code an of_platform_driver which translates the device tree
data and then registers the appropriate platform_devices.  This neatly
solves the problem, but I don't like the overhead involved in
registering 2 struct devices with the kernel for every device node in
the device tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/