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]

Date:	Wed, 27 May 2009 17:05:27 +0200
From:	Robert Schwebel <r.schwebel@...gutronix.de>
To:	Timur Tabi <timur@...escale.com>
Cc:	Janboe Ye <yuan-bo.ye@...orola.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	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 09:39:30AM -0500, Timur Tabi wrote:
> > > Signed-off-by: janboe <yuan-bo.ye@...orola.com>
> >
> > Heeheehe, This is Fantastic.
>
> Yes, I agree. Thanks for working on this. I was hoping to work on it
> myself later this year. Freescale develops both ARM-based and
> PowerPC-based SOCs, and some devices are shared between them (e.g. the
> SSI). Lack of device-tree support on ARM has been a real hindrance to
> getting the ARM-based Linux support on par with PowerPC.

Another reason might be this:

rsc@...be:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | grep freescale | wc -l
1

rsc@...be:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | grep pengutronix | wc -l
97

rsc@...be:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | wc -l
195

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.

Seriously: oftree in general is a good idea. Just that it doesn't work
in practise. The concept has some serious flaws:

- The whole concept is based on the assumption that bindings are defined
  *once*, then never to be changed again. As this is not true (check
  MPC5200 to find out what I mean), oftree wreckage is *the* main cause
  of new kernels not working on old bootloaders any more. Is there a
  solution of this problem? I have not seen a good idea how to avoid the
  constant change in definitions.

- The oftree layering is fundamentally broken. We already have a sane
  abstraction for arbitrary hardware in the kernel: platform devices.
  Why not instanciate platform devices from a generic oftree core?

- Platform data makes it possible to store function pointers. There
  is no equivalent to this concept in oftree-land.

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.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/