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 14:42:13 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
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 10:32 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:
>
>> I'm highly convinced that the existence of oftree-hell in ARM-land would
>> have been *the* key motivation for FSL to have worked on mainline
>> instead of inhouse-BSPs back in 2004 when we mainlined i.MX1 and in 2007
>> when we started the mainline work on MX27 and MX31.
>
> I remain to be convinced about that but anyway..
>
>> Seriously: oftree in general is a good idea. Just that it doesn't work
>> in practise. The concept has some serious flaws:
>
>> - Platform data makes it possible to store function pointers. There
>>   is no equivalent to this concept in oftree-land.
>
> 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.

The other common pattern, usually used on platform drivers, is to
factor out the common code and use 2 separate bus binding blocks; one
for platform and one for of_platform.  It has some (low) impact on
driver structure, but not everyone likes this approach.

>> oftree could be a great tool if these things would be resolved.
>> Currently they are not, and in result, ARM just works and is easy,
>> whereas on PowerPC systems people often spend more time working on
>> binding stuff than on the actual functionality.
>
> 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.

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/