linux-kernel - DT connectors, thoughts

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: <20160718142037.GS16769@voom.fritz.box>
Date:	Tue, 19 Jul 2016 00:20:37 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Frank Rowand <frowand.list@...il.com>
Cc:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Rob Herring <robh+dt@...nel.org>, stephen.boyd@...aro.org,
	broonie@...nel.org, grant.likely@...retlab.ca,
	Mark Rutland <mark.rutland@....com>, mporter@...sulko.com,
	Koen Kooi <koen@...inion.thruhere.net>,
	Guenter Roeck <linux@...ck-us.net>, marex@...x.de,
	Wolfram Sang <wsa@...-dreams.de>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	panto@...oniou-consulting.com
Subject: DT connectors, thoughts

Hi,

Here's some of my thoughts on how a connector format for the DT could
be done.  Sorry it's taken longer than I hoped - I've been pretty
swamped in my day job.

This is pretty early thoughts, but gives an outline of the approach I
prefer.

So.. start with an example of a board DT including a widget socket,
which contains pins for an MMIO bus, an i2c bus and 2 interrupt lines.

/dts-v1/;

/ {
	compatible = "foo,oldboard";
	ranges;
	soc@... {
		ranges;
		mmio: mmio-bus@... {
			#address-cells = <2>;
			#size-cells = <2>;
			ranges;
		};
		i2c: i2c@... {
		};
		intc: intc@... {
			#interrupt-cells = <2>;
		};
	};

	connectors {
		widget1 {
			compatible = "foo,widget-socket";
			w1_irqs: irqs {
				interrupt-controller;
				#address-cells = <0>;
				#interrupt-cells = <1>;
				interrupt-map-mask = <0xffffffff>;
				interrupt-map = <
					0 &intc 7 0
					1 &intc 8 0
				>;
			};
			aliases = {
				i2c = &i2c;
				intc = &w1_irqs;
				mmio = &mmio;
			};
		};
	};
};

Note that the symbols are local to the connector, and explicitly
listed, rather than including all labels in the tree.  This is to
enforce (or at the very least encourage) plugins to only access those
parts of the base tree.

Note also the use of an interrupt nexus node contained within the
connector to control which irqs the socketed device can use.  I think
this needs some work to properly handle unit addresses, but hope
that's enough to give the rough idea.

So, what does the thing that goes in the socket look like?  I'm
thinking some new dts syntax like this:

/dts-v1/;

/plugin/ foo,widget-socket {
	compatible = "foo,whirligig-widget";
};

&i2c {
	whirligig-controller@... {
		...
		interrupt-parent = <&widget-irqs>;
		interrupts = <0>;
	};
};

Use of the /plugin/ keyword is rather different from existing
practice, so we may want a new one instead.

The idea is that this would be compiled to something like:

/dts-v1/;

/ {
	socket-type = "foo,widget-socket";
	compatible = "foo,whirligig-widget";

	fragment@0 {
		target-alias = "i2c";
		__overlay__ {
			whirligig-controller@... {
				...
				interrupt-parent = <0xffffffff>;
				interrupts = <0>;
			};
		};
	};
	__phandle_fixups__ {
		/* These are (path, property, offset) tuples) */
		widget-irqs =
			"/fragment@..._overlay__/whirligig-controller@...",
			"interrupt-parent", <0>;
	};
};


Suppose then there's a new version of the board.  This extends the
widget socket in a backwards compatible way, but there are now two
interchangeable sockets, and they're wired up to different irqs and
i2c lines on the baseboard:

/dts-v1/;

/ {
	compatible = "foo,newboard";
	ranges;
	soc@... {
		ranges;	
		mmio: mmio-bus@... {
			#address-cells = <2>;
			#size-cells = <2>;
			ranges;
		};
		i2c0: i2c@... {
		};
		i2c1: i2c@... {
		};
		intc: intc@... {
		};
	};

	connectors {
		widget1 {
			compatible = "foo,widget-socket-v2", "foo,widget-socket";
			w1_irqs: irqs {
				interrupt-controller;
				#address-cells = <0>;
				#interrupt-cells = <1>;
				interrupt-map-mask = <0xffffffff>;
				interrupt-map = <
					0 &intc 17 0
					1 &intc 8 0
				>;
			};
			aliases = {
				i2c = &i2c0;
				intc = &w1_irqs;
				mmio = &mmio;
			};
		};
		widget2 {
			compatible = "foo,widget-socket-v2", "foo,widget-socket";
			w2_irqs: irqs {
				interrupt-controller;
				#address-cells = <0>;
				#interrupt-cells = <1>;
				interrupt-map-mask = <0xffffffff>;
				interrupt-map = <
					0 &intc 9 0
					1 &intc 10 0
				>;
			};
			aliases = {
				i2c = &i2c1;
				widget-irqs = &w2_irqs;
				mmio = &mmio;
			};
		};
	};
};


A socketed device could also have it's own connectors - the contrived
example below has a little 256 byte mmio space (maybe some sort of LPC
thingy?):


/dts-v1/;

/plugin/ foo,widget-socket-v2 {
	compatible = "foo,superduper-widget};

	connectors {
		compatible = "foo,super-socket";
		aliases {
			superbus = &superbus;
		};	
	};
};

&mmio {
	superbus: super-bridge@...000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0x0  0xabcd0000 0x12345600  0x100>;
	};
};

&i2c {
	super-controller@... {
		...
	};
	duper-controller@... {
	};
};

Thoughts?


-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)