[v2,1/3] gpiolib: acpi: Respect bias settings for GpioInt() resource

In some cases the GpioInt() resource is coming with bias settings
which may affect system functioning. Respect bias settings for
GpioInt() resource by calling acpi_gpio_update_gpiod_*flags() API
in acpi_dev_gpio_irq_get().

Reported-by: Jamie McClymont <jamie@kwiius.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
v2: preserved ordering of IRQ map (Hans, Mika), added Rb tag (Mika)
 drivers/gpio/gpiolib-acpi.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

On Thu, Oct 22, 2020 at 07:58:45PM +0300, Andy Shevchenko wrote:
> In some cases the GpioInt() resource is coming with bias settings
> which may affect system functioning. Respect bias settings for
> GpioInt() resource by calling acpi_gpio_update_gpiod_*flags() API
> in acpi_dev_gpio_irq_get().
> 
> Reported-by: Jamie McClymont <jamie@kwiius.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> v2: preserved ordering of IRQ map (Hans, Mika), added Rb tag (Mika)

Missed comment as per v1:

This one highly depends on Intel pin control driver changes (for now [1],
but might be more), so it's probably not supposed to be backported (at least
right now).

[1]: https://lore.kernel.org/linux-gpio/20201014104638.84043-1-andriy.shevchenko@linux.intel.com/T/

>  drivers/gpio/gpiolib-acpi.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index 834a12f3219e..3a39e8a93226 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -942,6 +942,7 @@ int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
>  
>  		if (info.gpioint && idx++ == index) {
>  			unsigned long lflags = GPIO_LOOKUP_FLAGS_DEFAULT;
> +			enum gpiod_flags dflags = GPIOD_ASIS;
>  			char label[32];
>  			int irq;
>  
> @@ -952,8 +953,11 @@ int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
>  			if (irq < 0)
>  				return irq;
>  
> +			acpi_gpio_update_gpiod_flags(&dflags, &info);
> +			acpi_gpio_update_gpiod_lookup_flags(&lflags, &info);
> +
>  			snprintf(label, sizeof(label), "GpioInt() %d", index);
> -			ret = gpiod_configure_flags(desc, label, lflags, info.flags);
> +			ret = gpiod_configure_flags(desc, label, lflags, dflags);
>  			if (ret < 0)
>  				return ret;
>  
> -- 
> 2.28.0
>

On Thu, Oct 22, 2020 at 9:15 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Oct 22, 2020 at 07:58:45PM +0300, Andy Shevchenko wrote:

> Missed comment as per v1:
>
> This one highly depends on Intel pin control driver changes (for now [1],
> but might be more), so it's probably not supposed to be backported (at least
> right now).
>
> [1]: https://lore.kernel.org/linux-gpio/20201014104638.84043-1-andriy.shevchenko@linux.intel.com/T/

I probably have to elaborate what above implies from integration p.o.v.

I think the best way is to collect tags from GPIO maintainers and I
can incorporate this into our Intel pin control branch which I will
share with you as PR against GPIO and pin control subsystems.

I'm also all ears for alternatives.

On Mon, Oct 26, 2020 at 04:41:14PM +0200, Andy Shevchenko wrote:
> On Thu, Oct 22, 2020 at 9:15 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Oct 22, 2020 at 07:58:45PM +0300, Andy Shevchenko wrote:
> 
> > Missed comment as per v1:
> >
> > This one highly depends on Intel pin control driver changes (for now [1],
> > but might be more), so it's probably not supposed to be backported (at least
> > right now).
> >
> > [1]: https://lore.kernel.org/linux-gpio/20201014104638.84043-1-andriy.shevchenko@linux.intel.com/T/
> 
> I probably have to elaborate what above implies from integration p.o.v.
> 
> I think the best way is to collect tags from GPIO maintainers and I
> can incorporate this into our Intel pin control branch which I will
> share with you as PR against GPIO and pin control subsystems.
> 
> I'm also all ears for alternatives.

Linus, Bart, what do you think about this series?

(Linus, the patch 3/3 has been already applied by Bart as it's independent to ACPI anyway)

On Mon, Nov 2, 2020 at 6:51 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Mon, Oct 26, 2020 at 04:41:14PM +0200, Andy Shevchenko wrote:
...

> Linus, Bart, what do you think about this series?
>
> (Linus, the patch 3/3 has been already applied by Bart as it's independent to ACPI anyway)

I have sent a v3