linux-kernel - Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree

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: <50069006.8050301@linaro.org>
Date:	Wed, 18 Jul 2012 11:29:26 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Shawn Guo <shawn.guo@...escale.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	devicetree-discuss@...ts.ozlabs.org,
	Wolfram Sang <w.sang@...gutronix.de>,
	linux-kernel@...r.kernel.org, Deepak Saxena <dsaxena@...aro.org>,
	linux-next@...r.kernel.org, Alessandro Rubini <rubini@...dd.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded
 tree

On 18/07/12 10:59, Mark Brown wrote:
> On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote:
>
>> I have an IP block getting different FIFO size on different IMX SoCs.
>> We could introduce a new compatible string for driver to figure it out,
>> but I think the simpler way is just have the data encoded in device
>> tree.  In any case DT is not completely limited in encoding board
>> specific data.  Today, we have IO region and interrupt number of
>> hardware blocks encoded in DT, and to me, FIFO size could just be
>> another aspect of hardware block we could choose to encode in DT.
>
> So, this is part of the problem with encoding the description of the SoC
> into the DT - we're not doing a good job of splitting out the silicon
> description from the board specific description which is not a triumph
> for maintainability since it means that we end up needing to modify the
> DT for every board using the silicon if we want to use the new feature
> (assuming people maintain binary compatibility with old DTs, which we
> don't do a good job at either even for established DT architectures).
>
> It's not the using device tree bit that creates concern for me here,
> it's the fact that the board and silicon aren't being separated.

What's the difference?

The Device Tree describes the hardware (hardware == silicon + 
peripherals). So different platforms are different pieces of hardware. 
Everything the driver can't figure itself out from the silicon itself 
needs to be described in the DT.

We can describe the relationship with a hierarchical layout of the dts 
and dtsi files. So for my recent venture we have:

> +- db8500.dtsi       // silicon
> \	
>  +-- snowball.dts    // board

We also have plans to split it up further:

>           db8xx0.dtsi               // shared silicon
>       _________/\_________
>      /                    \
> db8500.dtsi          db8540.dtsi    // differing silicon
> \                    \
>  +-- snowball.dts     +-- new_board.dts // board

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


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