linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).