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: <20090528142208.GB16199@trinity.fluff.org>
Date:	Thu, 28 May 2009 15:22:08 +0100
From:	Ben Dooks <ben-linux@...ff.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	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 02:22:50PM -0600, Grant Likely wrote:
> 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.

Surely the code could simply run at init time, throwing away the data
and code it doesn't need once it is done?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

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