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

[Linus Walleij]

On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren <swarren at 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
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.

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

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.

If the drive code is written in such a way that this will be denied,
I'll soften up, but I'd like to see the code first.

Then the same mistake has to be avoided in all drivers.

And that makes me want to probe for solutions tying them
up in the core so no mistakes can be made.

>> Is it not possible to do this in
>> drivers/gpio/gpiolib-of.c: of_gpiochip_add(), if the DT *know*
>> which GPIOs will be used as plain IRQs? That is the point with
>> the gpio hogs I talk about ...
>
> I suppose that if you modified the device tree bindings (schema
> definitions), you could have every GPIO provider DT node indicate which
> GPIOs were used as IRQs instead. However,
>
> a) This would be an incompatible change to the DT bindings, and they're
> supposed to be a stable ABI; old DTBs should work unmodified with new
> kernels.
>
> b) This would place GPIO usage information in multiple places. Right
> now, GPIO consumers list which GPIO(s) they use. The same goes for IRQs.
> If a GPIO provider started listing which GPIOs were really IRQs, then
> that'd mean configuring each GPIO-as-an-IRQ in two places; once in the
> client node to indicate which IRQ it should hook/register, and once in
> the provider node to indicate that the GPIO is really an IRQ. Two places
> is more hassle for people to implement, and more opportunity for mistakes.

Yeah but the current approach AFAICT isn't exactly safe either.

So I need some more convincing... or code rather, I guess.
If I can't point out the problems I see in a piece of code I guess
I'm just plain wrong :-)

Yours,
Linus Walleij