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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqLc0N8o2Nc_dEcZChJqWyN3UtZEgzLd=j6dR=1y3xOvdA@mail.gmail.com>
Date:	Thu, 21 Jul 2016 14:09:18 -0500
From:	Rob Herring <robh+dt@...nel.org>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	David Gibson <david@...son.dropbear.id.au>,
	Frank Rowand <frowand.list@...il.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 Vasut <marex@...x.de>, Wolfram Sang <wsa@...-dreams.de>,
	devicetree <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: DT connectors, thoughts

On Thu, Jul 21, 2016 at 9:14 AM, Pantelis Antoniou
<pantelis.antoniou@...sulko.com> wrote:
> Hi David,
>
>> On Jul 21, 2016, at 16:42 , David Gibson <david@...son.dropbear.id.au> wrote:
>>
>> On Wed, Jul 20, 2016 at 11:59:44PM +0300, Pantelis Antoniou wrote:
>>> Hi David,
>>>
>>> Spent some time looking at this, and it looks like it’s going to the right direction.
>>>
>>> Comments inline.
>>>
>>>> On Jul 18, 2016, at 17:20 , 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.

[...]

>>>>             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
>>>>                             >;
>>>>                     };
>>>
>>> This is fine. We need an interrupt controller node.
>>
>> Actually I think we only need an interrupt nexus, not an interrupt
>> controller (in IEEE1275 terminology).  (An interrupt controller would
>> generally require it's own driver, to ack/mask irqs, whereas this just
>> demonstrates the routing to an existing interrupt controller).  Which
>> makes that example slightly incorrect (it shouldn't have the
>> interrupt-controller property).
>
> Hmm, as far as I can tell we only have a concept of an interrupt controller
> in the kernel. An interrupt nexus is something new. We should get by without
> a driver but hacking the interrupt lookup path at DT.

Interrupt nexus is the interrupt-map property which is fully
supported. I'd expect we'll end up with a gpio nexus (i.e. gpio-map)
for connector gpios, too.

Rob