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]

Message-ID: <522EC392.8070002@ti.com>
Date:	Tue, 10 Sep 2013 02:00:34 -0500
From:	Joel Fernandes <joelf@...com>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	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>,
	Alexander Holler <holler@...oftware.de>,
	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

On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
> On 07/31/2013 01:44 AM, Linus Walleij wrote:
>> On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely <grant.likely@...aro.org> wrote:
>>> On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij <linus.walleij@...aro.org> wrote:
>>>> To solve this dilemma, perform an interrupt consistency check
>>>> when adding a GPIO chip: if the chip is both gpio-controller and
>>>> interrupt-controller, walk all children of the device tree,
>>>> check if these in turn reference the interrupt-controller, and
>>>> if they do, loop over the interrupts used by that child and
>>>> perform gpio_reques() and gpio_direction_input() on these,
>>>> making them unreachable from the GPIO side.
>>>
>>> Ugh, that's pretty awful, and it doesn't actually solve the root
>>> problem of the GPIO and IRQ subsystems not cooperating. It's also a
>>> very DT-centric solution even though we're going to see the exact same
>>> issue on ACPI machines.
>>
>> The problem is that the patches for OMAP that I applied
>> and now have had to revert solves it in an even uglier way,
>> leading to breaking boards, as was noticed.
>>
>> The approach in this patch has the potential to actually
>> work without regressing a bunch of boards...
>>
>> Whether this is a problem in ACPI or not remains to be seen,
>> but I'm not sure about that. Device trees allows for a GPIO line
>> to be used as an interrupt source and GPIO line orthogonally,
>> and that is the root of this problem. Does ACPI have the same
>> problem, or does it impose natural restrictions on such use
>> cases?
>>
> 
> I agree with Linus here. The problem is that GPIO controllers that can work as
> IRQ sources are treated in the kernel as if there where two separate controlers
> that are rather orthogonal: an irq_chip and a gpio_chip.
> But DT allows to use a GPIO line as an IRQ just by using an omap-gpio phandle as
> "interrupt-parent".
> 
> So, there should be a place where both irq_chip and gpio_chip has to be related
> somehow to properly configure a GPIO (request it and setting it as input) when
> used as an IRQ by DT.
> 
> My patch for OMAP used an irq_domain_ops .map function handler to configure the
> GPIO when a IRQ was mapped since that seemed to me as the best place to do it.
> This worked well in OMAP2+ platforms but unfortunately broke OMAP1 platforms
> since they are still using legacy domain mapping thus not call .map.

Just wondering- why .map not called for omap1? irq_create_mapping does seem to
call  -> irq_domain_associate which calls map function. For omap case, GPIO
driver does call irq_create_mapping, just like omap2+ no?

Further, if for any reason the .map is not called. Can you not call gpio_request
yourself direct in omap_gpio_chip_init function?

Does it really matter if you call gpio_request from .map or from the chip_init
function?

Also on a different note.. this would call gpio_request for *every* gpio line,
but isn't that what your original patch that got reverted was doing in
omap_gpio_chip_init:

+       if (!bank->chip.of_node)
+               for (j = 0; j < bank->width; j++)
+                       irq_create_mapping(bank->domain, j);

Just trying to understand your initial patch better.

Regards,

-Joel





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