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]

Message-ID: <147217552167.17958.11590706771471540284@sboyd-linaro>
Date:   Thu, 25 Aug 2016 18:38:41 -0700
From:   Stephen Boyd <stephen.boyd@...aro.org>
To:     David Gibson <david@...son.dropbear.id.au>,
        "Rob Herring" <robh+dt@...nel.org>
Cc:     "Frank Rowand" <frowand.list@...il.com>,
        "Pantelis Antoniou" <pantelis.antoniou@...sulko.com>,
        "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

Quoting David Gibson (2016-07-21 21:25:56)
> On Thu, Jul 21, 2016 at 02:15:57PM -0500, Rob Herring wrote:
> > On Mon, Jul 18, 2016 at 9:20 AM, David Gibson
> > <david@...son.dropbear.id.au> wrote:
> > 
> > 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.
> 
> Yes, sorry.  We have both the /soc/intc node which is the base board's
> master interrupt controller.  Then we have the connector local 'intc'
> alias which describes the local interrupt space for just the
> connector.
> 
> > What does using aliases here buy us vs. just properties with a
> > phandle?
> 
> Um.. I'm not sure what you mean.

I think Rob means drop the aliases node and just have:

	property = &phandle;

In this example:

	i2c = &i2c;
	intc = &w1_irqs;
	mmio = &mmio;

or perhaps to have a list of phandles and names that map to them?

	targets = <&i2c>, <&w1_irqs>, <&mmio>;
	target-names = "i2c", "intc", "mmio";

?

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

How would we support an expansion board that goes onto two
sockets/connectors provided by the baseboard when the connectors
"export" the same phandle aliases? From what I can tell with this design
we'll be unable to describe a device on the expansion board that is
wired to properties provided by the two connectors.