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:	Wed, 27 May 2009 22:38:45 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Timur Tabi <timur@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	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 02:42:13PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 10:32 AM, Mark Brown

> > The handling of platform data is my main concern as someone working
> > primarily on platform independant drivers - function pointers are a
> > particular problem but the possibility of having to write code to
> > handle both OF and non-OF systems to cater for systems using both
> > approaches is also a concern for me.

> Having a hook function which generates a pdata structure from a device
> node on a per driver basis is a common approach.  Essentially, the
> hook becomes an addon to the driver which doesn't impact the driver as
> a whole.  i2c and SPI device tend to take this approach.

Yes, this is what I mean about doing it twice - you have to have the
regular platform data structure plus another function to map the
OpenFirmware data into it.  The fact that quite a few of the devices I
deal with want function pointers as platform data doesn't help here.

> > This worries me too, my experiences with OF device tree handling for
> > ASoC have been pretty negative - but then audio is one of the worst
> > cases for handling within the device tree.

> First steps are hard.  I2C and SPI work had similar groans and pains,
> and ASoC is considerably more complex.  In the end the stuff in
> drivers/of/* was added to handle the creation of i2c, spi and phy
> devices from data in the device tree.  It is a mechanism which seems
> to be working well.

Instantiating the devices is a solved problem - with the current code
you can load the drivers for all the various parts of the audio
subsystem via the standard device model with everything appearing on
whatever bus it normally should.  The only exception to that is AC97
(because it's a bit special and needs some general TLC).  Some more work
is needed on the core to fully take advantage of what this bought us but
as far as loading and initialising device drivers goes you should be
there already.

What's a really crippling problem for what people seem to want to do
with the device tree right now is expressing the clocking trees and
requirements for a non-trivial audio subsystem.  The current clock API
is quite a way off being able to cope with this at runtime and without
that the benefits of trying to put the data into device trees are
questionable - a plaform independant representation of this data most
likely needs us to be able to automatically configure the clock tree
based on a description of the interconnects and their constraints.
--
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/