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:	Mon, 12 Nov 2012 22:22:07 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	David Gibson <david@...son.dropbear.id.au>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	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 11/12/2012 06:05 PM, David Gibson wrote:
> On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote:
...
> 2) graft bundle
> 
> The base tree has something like this:
> 
> 	...
> 	i2c@XXX {
> 		...
> 		cape-socket {
> 			compatible = "vendor,cape-socket";
> 			id = "Socket-A";
> 			piece-id = "i2c";
> 			ranges = < ... >;
> 		};
> 	};
> 	...
> 	spi@YYY {
> 		...
> 		cape-socket {
> 			compatible = "vendor,cape-socket";
> 			id = "Socket-A";
> 			piece-id = "spi";
> 			ranges = < ... >;
> 		};
> 	};
> 	...
> 	cape-socket {
> 		compatible = "vendor,cape-socket";
> 		id = "Socket-A";
> 		piece-id = "misc";
> 		interrupt-map = < ... >;
> 		interrupt-map-mask = < ... >;
> 		gpio-map = < ... >;
> 		gpio-map-mask = < ... >;
> 	};
> 
> Then instead of grafting a single subtree for the socket, we install a
> "bundle" of subtrees, one each for each of the pieces within the
> socket.  That bundle could either be an actual set of multiple fdts,
> or they could be placed into one fdt with a dummy root node, something like:
>
> 	/ {
> 		plugin-bundle;
> 		compatible = "vendor,cape-plugin";
> 		version = ...;
> 		i2c-piece = {
> 			piece-id = "i2c";
> 			...
> 		};
> 		misc-piece = {
> 			piece-id = "misc";
> 			...
> 		};
> 	};

I do like this approach; it's the kind of thing I proposed at:

> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html

One question though: Perhaps the base board has two instances of the
same type of connector vendor,cape-socket, allowing 2 independent capes
to be plugged in. When overlaying/grafting the child board's .dts, we'd
need some way to specify the socket ID that was being plugged into. Is
that the intent of the "id" property in your base board example above?
--
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/