All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Brian Masney <bmasney@redhat.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Konrad Dybcio <konrad.dybcio@linaro.org>
Subject: Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips
Date: Wed, 16 Nov 2022 11:26:34 +0100	[thread overview]
Message-ID: <Y3S62i7OzocP5QrT@orome> (raw)
In-Reply-To: <20221115111800.t6i6fuszhuasvgka@SoMainline.org>

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote:
> On 2022-11-14 16:15:25, Brian Masney wrote:
> > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > > 
> > > The OF node store in chip->fwnode is used to explicitly override the FW
> > > node for a GPIO chip. For chips that use the default FW node (i.e. that
> > > of their parent device), this will be NULL and cause the chip not to be
> > > fully registered.
> > > 
> > > Instead, use the GPIO device's FW node, which is set to either the node
> > > of the parent device or the explicit override in chip->fwnode.
> > > 
> > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode")
> > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > 
> > Reviewed-by: Brian Masney <bmasney@redhat.com>
> > Tested-by: Brian Masney <bmasney@redhat.com>
> > 
> > I separately sent a similar type of patch to fix the same issue today:
> > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u
> 
> For completeness, your linked patch fixes a synchronous external abort
> on multiple Qualcomm platforms pointed out in [1].  This patch however
> does not, are you sure they fix the exact same issue?
> 
> [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/

Can you check if the below fixes the MSM issue that you're seeing
(applied on top of my earlier patch, though with Brian's reverted
temporarily)?

Thanks,
Thierry

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-11-16 10:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 11:37 [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips Thierry Reding
2022-11-11 11:45 ` Andy Shevchenko
2022-11-11 15:12   ` Thierry Reding
2022-11-11 14:21 ` Linus Walleij
2022-11-12 12:59 ` Robert Marko
2022-11-14 21:12 ` Andrew Halaney
2022-11-14 21:15 ` Brian Masney
2022-11-15 11:18   ` Marijn Suijten
2022-11-15 11:41     ` Brian Masney
2022-11-16 10:26     ` Thierry Reding [this message]
2022-11-16 10:38       ` Andy Shevchenko
2022-11-16 14:05         ` Thierry Reding
2022-11-16 16:06       ` Marijn Suijten
2022-11-15 11:13 ` Geert Uytterhoeven
2022-11-15 14:38 ` Bartosz Golaszewski

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=Y3S62i7OzocP5QrT@orome \
    --to=thierry.reding@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bmasney@redhat.com \
    --cc=brgl@bgdev.pl \
    --cc=dmitry.torokhov@gmail.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=marijn.suijten@somainline.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.