linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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:	Fri, 9 Nov 2012 23:27:01 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	David Gibson <david@...son.dropbear.id.au>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Scott Wood <scottwood@...escale.com>,
	Russ Dill <Russ.Dill@...com>, linux-omap@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving
 omap_devices to mach-omap2)

On Fri, Nov 9, 2012 at 10:57 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 11/08/2012 07:26 PM, David Gibson wrote:
> ...
>> I also think graft will handle most of your use cases, although as I
>> said I don't fully understand the implications of some of them, so I
>> could be wrong.  So, the actual insertion of the subtree is pretty
>> trivial to implement.  phandles are the obvious other matter to be
>> dealt with.  I haven't found the right thread where what you've
>> envisaged so far is discussed, so here are things I can see:
>>
>> 1) Avoiding phandle collisions between main tree and subtree (or
>>    between subtrees).
>>
>> I'm hopeful that this can be resolved just by establishing some
>> conventions about the ranges of phandles to be used for various
>> components.  I'd certainly be happy to add a directive to dtc which
>> enforces allocation of phandles within a specified range.
>
> One case I wonder about is:
>
> Base board A that's split into two .dts files e.g. due to there being
> two versions of the base board which are 90% identical, yet there being
> a few differences between them.
>
> Base board B that's just a single .dts file.
>
> We might allocate phandle range 0..999 for the base board.
>
> Child board X plugs into either, so the two base boards need to "export"
> the same set of phandle IDs to the child board to allow it to reference
> them.

It's more than just that. The boards really need to be equivalent
since the irq specifiers and gpio specifiers need to match the gpio
and irq controllers provided by the board. So a simple overlay design
won't cover the case of a single file that will work generically on
any board.

> If base board A version 2 comes along after the phandle IDs that the
> child board uses are defined, then how do we handle assigning a specific
> phandle ID range to each of base board A's two version-specific
> overlays, when the version-specific changes might affect arbitrary
> phandle IDs within the range, and require some to be moved into the base
> board version-specific overlays and some to stay in the common base
> board .dts?

With the design I'm currently considering, at the dts level the
overlay could be compiled against any base boards if the specifiers
are equivalent and the labels match up as indicated above. The
compiled dtb could also be somewhat portable, but only if care is
taken to make sure the phandles match too; possibly by explicitly
specifying them instead of letting them be generated by a hash.

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