Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver

[Stephen Warren <swarren@wwwdotorg.org>]

On 04/10/2013 03:28 PM, Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 04/10/2013 12:12 PM, Linus Walleij wrote:
> 
>>> If the information is there, whether to convert from IRQ to GPIO
>>> or from GPIO to IRQ is a technicality and any order should be
>>> feasible in some way?
>>
>> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put
>> another way, a single GPIO would likely only ever trigger a single IRQ,
>> but a single IRQ might easily be triggered by any number of GPIOs. This
>> is exactly why the function irq_to_gpio() isn't something one should use
>> any more. I think there was an effort to outright remove the API,
>> although it doesn't look like that's entirely complete yet. I guess you
>> know this given your mentions of problem with gpio_to_irq() later on, so
>> I'm not quite sure what your paragraph above was supposed to mean.
> 
> So the only reason I'm rambing on about this is that it breaks the

I'm not sure I understand this paragraph; what is "it" in the line above.

If "it" is this patch, then should "breaks" be re-establishes?

> connection between GPIOs and their IRQs and at one point
> I percieved it as there was going to be some IRQ -> GPIO lookup,
> and it would sneak back in. But now I realize that may have been
> supposed to be something local to the driver, in it's irqchip portions
> and then it's actually no problem for the kernel at large.

Yes, I believe the intention was for their to be a correlation between
GPIOs and IRQs only with the individual gpio_chip/irq_chip drivers for
those GPIOs/IRQs, and not exposed anywhere outside it.

> Let's restate: I'm also after something fragile here.

I assume you mean the opposite of that?

> IIUC, it will be possible for a GPIO to be set up as input and used
> as an IRQ without the GPIO subsystem knowing it. And it will be
> possible for the GPIO subsystem to go in and request the same pin
> and set it as output and e.g. bit-bang it. I wonder what happens then.

Yes, I think that's possible now.

If I recall the patch I'm replying to correctly, the idea was to add an
"IRQ request" operation that would (internally to the GPIO/IRQ driver
itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
exactly the situation you mention above.