linux-kernel - Re: 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]
Date:	Thu, 21 Jul 2016 14:15:57 -0500
From:	Rob Herring <robh+dt@...nel.org>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Frank Rowand <frowand.list@...il.com>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Stephen Boyd <stephen.boyd@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Mark Rutland <mark.rutland@....com>,
	Matt Porter <mporter@...sulko.com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Marek Vašut <marex@...x.de>,
	Wolfram Sang <wsa@...-dreams.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	Pantelis Antoniou <panto@...oniou-consulting.com>
Subject: Re: DT connectors, thoughts

On Mon, Jul 18, 2016 at 9:20 AM, David Gibson
<david@...son.dropbear.id.au> wrote:
> 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;

I understand how you are using i2c alias, but not the intc. It would
help if the same names were not used in multiple places unless they
are the same thing.

What does using aliases here buy us vs. just properties with a phandle?

>                                 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";

Yet another way to express the target... Every new feature for
overlays seems to define a new way. My thinking was the target is a
connector node and all devices are under it. In your case, the
connector is not part of the hierarchy for any devices in the overlay.
That may simplify adding OS support, but seems to be a less accurate
representation of the h/w.

>                 __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>;
>         };
> };