linux-kernel - Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

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, 12 Sep 2013 13:09:44 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Grant Likely <grant.likely@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Enric Balletbo i Serra <eballetbo@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Kevin Hilman <khilman@...aro.org>,
	Balaji T K <balajitk@...com>,
	Tony Lindgren <tony@...mide.com>,
	Jon Hunter <jgchunter@...il.com>
Subject: Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 12.09.2013 12:28, schrieb Alexander Holler:
> Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
>> On 09/12/2013 10:55 AM, Alexander Holler wrote:
>
> ...
>>>
>>> By the way, how do you define two GPIOs/IRQs from different
>>> gpio-banks/irq-controllers wuth that scheme?
>>>
>>
>> That is indeed a very good question and I don't have a definite answer.
>>
>>> Would that be like below?
>>>
>>>   ethernet@5,0 {
>>>            compatible = "smsc,lan9221", "smsc,lan9115";
>>>            interrupt-parent = <&gpio6>;
>>>            interrupts = <16 8>;
>>>            interrupt-parent = <&gpio7>;
>>>            interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
>>>   };
>>>
>
> ...
>
>> So, if I understood the code correctly the DT IRQ core doesn't expect
>> a device
>> node to have more than one "interrupt-parent" property.
>>
>> It *should* work though if you have multiple "interrupts" properties
>> defined and
>> all of them have the same "interrupt-parent":
>>
>>         interrupt-parent = <&gpio6>;
>>         interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
>>         interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */
>>
>> since of_irq_map_one() will be called for each "interrupts" and the
>> correct
>> "interrupt-parent" will get obtained by of_irq_find_parent().
>
> I assumed that answer. So to make such a scenario possible, something
> like this might be neccessary:
>
>           interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
>           interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */
>
> or, to be compatible
>
>           interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
>           interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
>
> Another problem is the naming. In all the above cases, the driver would
> not know which IRQ he should use for what. Maybe the order defines it,
> but that wouldn't be very verbose. And I think just changing the name
> would make travelling the tree impossible, as only the driver itself
> would know the name and it's meaning.

On a second look, travelling the tree is still possible if the solution 
would be like above (without that interrupt-parent). So if a driver 
requires two interrupts he could use

       interrupt-foo = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
       interrupt-bar = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */

And travelling the tree will still be possible because walking from the 
interrupt-controllers (those gpio) downwards would end up at the 
interrupt definitions, so the name of them isn't needed to find them in 
the tree.

Regards,

Alexander Holler

--
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/