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: <20090528150409.GO22742@pengutronix.de>
Date:	Thu, 28 May 2009 17:04:09 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Thomas Gleixner <tglx@...utronix.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, May 28, 2009 at 03:18:02PM +0200, Thomas Gleixner wrote:
> On Thu, 28 May 2009, Sascha Hauer wrote:
> > > There is the advantage of easy multiplatform support.  I regularly
> > > build a single kernel image which boots on all my MPC5200 boards, and
> > > on my MPC83xx boards.
> > 
> > That is not necessarily an advantage of a device tree. On ARM you can
> > also build a kernel which runs on 20+ PXA platforms at the same time.
> > (And I'm sure it can be done to even support say i.MX and PXA at the
> > same time, but this is another story)
> 
> Well, you can run it on 20+ PXA platforms which have all their own
> machine number, but you have all the little details of each platform
> hardcoded into the kernel.
> 
> 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.

> 
> So you either have 5 board numbers and all the details harcoded again
> or you add some extra magic to deduce on which variant you are running
> on.
> 
> We have seen almost everything in the weirdness range from poking in
> some hardcoded FLASH cells over weird command line parsers up to a XML
> parser which were added to work around the limitations of the machine
> number model.
> 
> With a device tree you can avoid that crap and provide a standardized
> interface for such cases.
> 
> I'm not saying that the device tree will make all those problems go
> away magically, but it's orders of magnitudes better than what people
> do now.
> 
> 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.

Sascha

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