Thread (35 messages) 35 messages, 3 authors, 2023-03-09

Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: 2023-03-09 13:52:38
Also in: linux-devicetree

On Thu, Mar 09, 2023 at 10:38:11AM +0100, Benjamin Tissoires wrote:
On Mar 08 2023, Andy Shevchenko wrote:
...
quoted hunk ↗ jump to hunk
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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help