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:	Thu, 28 May 2009 17:27:11 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sascha Hauer <s.hauer@...gutronix.de>
cc:	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Russell King <rmk+lkml@....linux.org.uk>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Timur Tabi <timur@...escale.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 Thu, 28 May 2009, Sascha Hauer wrote:
> > That does not help at all when your board has 5 variants just
> > different in subtle details which can not be probed or enumerated by
> > inspection. That's a common scenario in the embedded world.
> 
> We normally hide these subtle details behind a baseboard= kernel
> parameter. I agree with you that it's far better to have a standardized
> way to specify this. For my taste the oftree is too bloated for this
> purpose.

Well, with the baseboard= you still have to hack the details into the
kernel, which just adds code which needs to be maintained. I really
can do without 20 different platform structs and switch cases which
init GPIOs if there is an elegant way to describe the pin routing and
such. If you get your configuration out of OF tree then you can handle
this w/o even touching the kernel in most cases.

> > There is no need to force switch all of ARM to the device tree, but
> > adding support for it would be a good move. Nobody wants to enforce it
> > and both models can live happily side by side and we'll see which
> > variant turns out to be the long term favourite solution.
> 
> Having it as an optional feature seems a good idea for the same reasons
> you mentioned. I just wonder how optional it can be once a board
> maintainer and a person sending patches disagree on whether to use oftree
> or not.

As always it will be discussed on technical grounds. :)

Thanks,

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