From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Daniel Glöckner" <dg@emlix.com>
Cc: linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: acpi_find_gpio with absent GPIOs
Date: Mon, 26 Oct 2015 12:20:31 +0200 [thread overview]
Message-ID: <20151026102031.GG1526@lahna.fi.intel.com> (raw)
In-Reply-To: <562A4AB6.1010805@emlix.com>
On Fri, Oct 23, 2015 at 04:56:54PM +0200, Daniel Glöckner wrote:
> Hi,
>
> I'm currently trying to use rfkill-gpio with a device that has just a
> single GPIO assigned by ACPI. rfkill-gpio calls acpi_dev_add_driver_gpios
> to assign names to the ACPI GPIOs and then uses devm_gpiod_get_optional
> to request both of them. The problem is that on the second call to
> devm_gpiod_get_optional acpi_find_gpio falls back to using the GPIO index
> 0 (from gpiod_get) in _CRS, which leads to the same GPIO being returned
> as in the first call. Probing the driver then fails with -EBUSY.
>
> In my opinion it is a bad idea to fall back to indexing the _CRS if the
> con_id was found in the _DSD or the GPIOs added by
> acpi_dev_add_driver_gpios, but I don't know if there are drivers relying
> on this behavior.
I agree it is bad idea and I think this is actually a bug in the
implementation rather than wanted behavior. No drivers should rely on
that anyway.
> Luckily acpi_get_gpiod_by_index returns -ENODATA if the name can't be
> found and -ENOENT if the GPIO is absent, so we can distinguish the two
> cases. -EPROBE_DEFER also should not make acpi_find_gpio try to use
> another GPIO from the _CRS.
>
> There is also the possibility that the GPIO index exceeds the size of
> the package found in _DSD or added with acpi_dev_add_driver_gpios.
> The former will return -EPROTO, the latter will forward the error
> from acpi_dev_get_property_reference (usually -ENODATA). of_find_gpio
> returns -ENOENT in this case.
>
> So, what of this should be fixed?
I think both should be fixed.
For the first maybe something like below?
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 5db3445552b1..441be96e18e7 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1765,6 +1765,11 @@ static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id,
/* Then from plain _CRS GPIOs */
if (IS_ERR(desc)) {
+ /* Only fallback if the device has no properties at all */
+ if (PTR_ERR(desc) == -ENODATA &&
+ (adev->data.properties || adev->driver_gpios))
+ return ERR_PTR(-ENOENT);
+
desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info);
if (IS_ERR(desc))
return desc;
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2015-10-26 10:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 14:56 acpi_find_gpio with absent GPIOs Daniel Glöckner
2015-10-26 10:20 ` Mika Westerberg [this message]
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=20151026102031.GG1526@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=dg@emlix.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@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.