Re: [RFCv2 PATCH 1/4] gpiolib: (un)mark gpio as irq when dis/enabling irq

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Aug 27, 2018 at 3:06 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote:

> From: Hans Verkuil <hans.verkuil@xxxxxxxxx>
>
> Drivers are currently required to call gpiochip_(un)lock_as_irq whenever
> they want to use a gpio as an interrupt. Unfortunately, this is generally
> done when the irq is requested, not when the irq is enabled/disabled.
>
> This is problematic for cases where a gpio pin is temporarily used as an
> interrupt pin, then, after the irq is disabled, is used as a regular
> gpio pin again. Currently it is not possible to do this other than by first
> freeing the interrupt so gpiochip_unlock_as_irq is called.
>
> There are currently two drivers that would like to be able to do this:
> the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
> reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
> driver where you want to configure the gpio pin as an interrupt while
> waiting for traffic over the CEC bus, or as a regular pin when receiving or
> transmitting a CEC message.
>
> The core problem is that gpiochip_(un)lock_as_irq is called when the
> interrupt is allocated/freed, not when the interrupt is enabled/disabled.
>
> Also, it is hit-and-miss whether drivers call these functions.
>
> This patch hooks gpiochip_irq_(un)lock into the irq_enable/disable
> callbacks of the irqchip. That way drivers no longer have to call these
> functions and this is all done transparently for drivers.
>
> The old gpiochip_(un)lock_as_irq() functions are now empty stubs that
> can be removed once all drivers that call them are updated.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@xxxxxxxxx>

This looks *REALLY* good to me.

It solves a bunch of long-standing unelegance issues with the GPIO
IRQs by creating an indirection of IRQchip pointers.

I just want to know that Marc Z in on board with this change
and I want to apply it (or if you want to make a v1) early so
we can shake out any bugs in the development cycle for v4.20.

Yours,
Linus Walleij