On Thu, Mar 09, 2023 at 10:38:11AM +0100, Benjamin Tissoires wrote:
> On Mar 08 2023, Andy Shevchenko wrote:
...
> Looks like gpiolib-acpi.c doesn't care about fwnode at all.
>
> if I do the following:
>
> ---
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index d8a421ce26a8..5aebc266426b 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -126,7 +126,7 @@ static bool acpi_gpio_deferred_req_irqs_done;
>
> static int acpi_gpiochip_find(struct gpio_chip *gc, void *data)
> {
> - return gc->parent && device_match_acpi_handle(gc->parent, data);
> + return ACPI_HANDLE_FWNODE(gc->fwnode) == data;
> }
>
> /**
> ---
This seems a legit fix.
> I can now directly reference the GPIO ACPI node in my GpioInt()
> declaration. And AFAICT this should be safe to do because gpiolib ensure
> that gc->fwnode is set, using the one from the parent if it is not set
> previously.
>
> I need to check if this works with my icelake laptop, and if so I'll
> send it to the list.
>
> The reason the intel gpios are working (the only one I checked) is
> because the \\SB.GPI0 node refers to the pinctrl controller (driver
> pinctrl-icelake.c in my case, which then creates a subdevice for
> handling the gpio).
Good catch!
--
With Best Regards,
Andy Shevchenko
