From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Daniel Kaehn <kaehndan@gmail.com>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpiolib: acpi: use the fwnode in acpi_gpiochip_find()
Date: Fri, 10 Mar 2023 13:41:50 +0200 [thread overview]
Message-ID: <20230310114150.GA62143@black.fi.intel.com> (raw)
In-Reply-To: <20230309-fix-acpi-gpio-v1-1-b392d225efe8@redhat.com>
On Thu, Mar 09, 2023 at 02:40:51PM +0100, Benjamin Tissoires wrote:
> While trying to set up an SSDT override for a USB-2-I2C chip [0],
> I realized that the function acpi_gpiochip_find() was using the parent
> of the gpio_chip to do the ACPI matching.
>
> This works fine on my icelake laptop because AFAICT, the DSDT presents
> the PCI device INT3455 as the "Device (GPI0)", but is in fact handled
> by the pinctrl driver in Linux.
> The pinctrl driver then creates a gpio_chip device. This means that the
> gc->parent device in that case is the GPI0 device from ACPI and everything
> works.
>
> However, in the hid-cp2112 case, the parent is the USB device, and the
> gpio_chip is directly under that USB device. Which means that in this case
> gc->parent points at the USB device, and so we can not do an ACPI match
> towards the GPIO device.
>
> I think it is safe to resolve the ACPI matching through the fwnode
> because when we call gpiochip_add_data(), the first thing it does is
> setting a proper gc->fwnode: if it is not there, it borrows the fwnode
> of the parent.
>
> So in my icelake case, gc->fwnode is the one from the parent, meaning
> that the ACPI handle we will get is the one from the GPI0 in the DSDT
> (the pincrtl one). And in the hid-cp2112 case, we get the actual
> fwnode from the gpiochip we created in the HID device, making it working.
>
> Link: https://lore.kernel.org/linux-input/20230227140758.1575-1-kaehndan@gmail.com/T/#m592f18081ef3b95b618694a612ff864420c5aaf3 [0]
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
next prev parent reply other threads:[~2023-03-10 11:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 13:40 [PATCH] gpiolib: acpi: use the fwnode in acpi_gpiochip_find() Benjamin Tissoires
2023-03-09 14:03 ` Andy Shevchenko
2023-03-09 14:47 ` Andy Shevchenko
2023-03-10 6:43 ` Mika Westerberg
2023-03-10 11:37 ` Andy Shevchenko
2023-03-10 11:41 ` Mika Westerberg [this message]
2023-03-10 12:51 ` Benjamin Tissoires
2023-03-10 13:36 ` Andy Shevchenko
2023-03-10 13:39 ` Benjamin Tissoires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230310114150.GA62143@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=benjamin.tissoires@redhat.com \
--cc=brgl@bgdev.pl \
--cc=kaehndan@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.