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

[Hans Verkuil <hverkuil@xxxxxxxxx>]

On 29/08/18 09:15, Linus Walleij wrote:
> 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 does? Overriding all these irqchip hooks is scary. But it might be
because this is all new 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.

Can you reply to the question in my cover letter? I need to know
the answer before spinning a non-RFC patch series.

Should I prepare that patch series on top of a specific git tree? Currently
I just used the mainline tree for this.

Regards,

	Hans