From: Thierry Reding <thierry.reding@gmail.com>
To: Brian Masney <bmasney@redhat.com>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, psodagud@quicinc.com,
quic_shazhuss@quicinc.com, quic_ppareek@quicinc.com,
ahalaney@redhat.com, echanude@redhat.com,
nicolas.dechesne@linaro.org
Subject: Re: [PATCH RFC] gpiolib: ensure that fwnode is properly set
Date: Wed, 16 Nov 2022 11:35:37 +0100 [thread overview]
Message-ID: <Y3S8+cZO379Oiyce@orome> (raw)
In-Reply-To: <Y3S5sZIVi2DPua0p@orome>
[-- Attachment #1: Type: text/plain, Size: 4357 bytes --]
On Wed, Nov 16, 2022 at 11:21:37AM +0100, Thierry Reding wrote:
> On Mon, Nov 14, 2022 at 03:29:43PM -0500, Brian Masney wrote:
> > Note that this is a RFC patch and not meant to be merged. I looked into
> > a problem with linux-next-20221110 on the Qualcomm SA8540P automotive
> > board (sc8280xp) where the UFS host controller would fail to probe due
> > to repeated probe deferrals when trying to get reset-gpios via
> > devm_gpiod_get_optional().
> >
> > of_get_named_gpiod_flags() returns -EPROBE_DEFER, which is caused by
> > of_gpiochip_match_node_and_xlate() returning 0 since the of_xlate function
> > pointer is not set for the qcom,sc8280xp-tlmm pinctrl driver. The
> > pinctrl driver doesn't define one, so of_gpiochip_add() should
> > automatically setup of_gpio_simple_xlate() on it's behalf. This doesn't
> > happen since the fwnode member on the struct gpiochip is set to null
> > when of_gpiochip_add() is called. Let's work around this by ensuring
> > that it's set if available.
> >
> > Note that this broke sometime within the last few weeks within
> > linux-next and I haven't bisected this. I'm posting this in the hopes
> > that someone may know offhand which patch(es) may have broken this.
> >
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > ---
> > drivers/gpio/gpiolib.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 11fb7ec883e9..8bec66008869 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -678,7 +678,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> > * Assign fwnode depending on the result of the previous calls,
> > * if none of them succeed, assign it to the parent's one.
> > */
> > - gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode;
> > + gc->fwnode = gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode;
>
> This doesn't look right to me. Looking at the documentation of
> gc->fwnode and how it is used, the purpose of this is to allow
> explicitly overriding the fwnode that the GPIO chip will use.
>
> So really this should not be used beyond the initial registration
> in gpiochip_add_data_with_key(). If the above patch fixes anything,
> then I suspect somebody is using gc->fwnode outside of this
> registration.
>
> Looking at gpiolib, the only remaining place that seems to do this is
> the gpio-reserved-ranges handling code, in which case, the below on top
> of my initial patch might fix that. That might explain why MSM is still
> seeing issues.
>
> --- >8 ---
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 11fb7ec883e9..d692ad5c5a27 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -447,10 +447,11 @@ static unsigned long *gpiochip_allocate_mask(struct gpio_chip *gc)
>
> static unsigned int gpiochip_count_reserved_ranges(struct gpio_chip *gc)
> {
> + struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev);
> int size;
>
> /* Format is "start, count, ..." */
> - size = fwnode_property_count_u32(gc->fwnode, "gpio-reserved-ranges");
> + size = fwnode_property_count_u32(fwnode, "gpio-reserved-ranges");
> if (size > 0 && size % 2 == 0)
> return size;
>
> @@ -471,6 +472,7 @@ static int gpiochip_alloc_valid_mask(struct gpio_chip *gc)
>
> static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
> {
> + struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev);
> unsigned int size;
> u32 *ranges;
> int ret;
> @@ -483,7 +485,7 @@ static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
> if (!ranges)
> return -ENOMEM;
>
> - ret = fwnode_property_read_u32_array(gc->fwnode, "gpio-reserved-ranges", ranges, size);
> + ret = fwnode_property_read_u32_array(fwnode, "gpio-reserved-ranges", ranges, size);
> if (ret) {
> kfree(ranges);
> return ret;
> --- >8 ---
>
> I don't have a good idea about the Lenovo X13 issue, though, but I
> haven't looked at ACPI at all since I don't have any hardware to test
> on.
Ah... looks like that device was actually a Thinkpad X13*s*, which is
based on a Qualcomm chip, so maybe this patch fixes that one, too. It
does use gpio-reserved-ranges, so seems at least likely.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-16 10:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 20:29 [PATCH RFC] gpiolib: ensure that fwnode is properly set Brian Masney
2022-11-14 21:02 ` Robert Marko
2022-11-14 21:16 ` Brian Masney
2022-11-15 8:18 ` Shazad Hussain
2022-11-15 11:08 ` Marijn Suijten
2022-11-15 11:53 ` Konrad Dybcio
2022-11-15 17:07 ` Bryan O'Donoghue
2022-11-15 22:02 ` Steev Klimaszewski
2022-11-16 9:19 ` Bartosz Golaszewski
2022-11-16 10:23 ` Thierry Reding
2022-11-16 9:09 ` Neil Armstrong
2022-11-16 10:21 ` Thierry Reding
2022-11-16 10:35 ` Thierry Reding [this message]
2022-11-16 11:14 ` Brian Masney
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=Y3S8+cZO379Oiyce@orome \
--to=thierry.reding@gmail.com \
--cc=ahalaney@redhat.com \
--cc=bmasney@redhat.com \
--cc=brgl@bgdev.pl \
--cc=echanude@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.dechesne@linaro.org \
--cc=psodagud@quicinc.com \
--cc=quic_ppareek@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).