Re: [PATCH] gpiolib: Don't implicitly disable irq when masking

[Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx>]

Hi Linus,

On 11/05/23 20:00, Linus Walleij wrote:
> On Wed, May 10, 2023 at 10:59 PM Chris Packham
> <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote:
>
>> The coupling of gpiochip_irq_mask()/gpiochip_irq_unmask() with
>> gpiochip_disable_irq()/gpiochip_enable_irq() goes back to the same
>> commit a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable").
>> It's not immediately obvious to me why the coupling is needed.
> That is just a refactoring of what existed before.
>
> The use case is here:
> drivers/media/cec/platform/cec-gpio/cec-gpio.c
>
> The driver needs to switch, at runtime, between actively driving a GPIO
> line with gpiod_set_value(), and setting the same line into input mode
> and listening for signalling triggering IRQs on it, and then back to
> output mode and driving the line again. It's a bidirectional GPIO line.
> This use case yields a high need of control.
>
>> I was
>> hoping that someone seeing my patch would confirm that it's not needed
>> or say why it's needed suggest an alternative approach.
> Which IRQ-enabled gpiochip is this? Has it been converted to be immutable?
> I think that could be part of the problem.

For me it's a pca9555. I spent yesterday trying to demonstrate the 
problem on a newer kernel. Some teething issues aside I can trigger the 
warning if I have a gpio-button using one of the pca9555 pins as an 
interrupt and then I export some of the other pins via sysfs.

Interestingly the warning isn't triggered if I use a gpio-hog instead of 
exporting the pins. I haven't figured out why that is but I'm assuming 
it's something to do with the hogged pins being excluded from the irq 
domain before it is registered.