[PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Thierry Reding]

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>
---
 drivers/gpio/gpiolib-of.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 4be3c21aa718..55c3712592db 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
 	struct device_node *np;
 	int ret;
 
-	np = to_of_node(chip->fwnode);
+	np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
 	if (!np)
 		return 0;
 
-- 
2.38.1

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Andy Shevchenko]

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.

Thank you!

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

P.S.
It's good we have this report, which means I have to reconsider the
followup I'm cooking. In any case I will send it after v6.2-rc1 for
broader testing.

> 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>
> ---
>  drivers/gpio/gpiolib-of.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 4be3c21aa718..55c3712592db 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
>  	struct device_node *np;
>  	int ret;
>  
> -	np = to_of_node(chip->fwnode);
> +	np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
>  	if (!np)
>  		return 0;
>  
> -- 
> 2.38.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Linus Walleij]

On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding
<thierry.reding@gmail.com> 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: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Thierry Reding]

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

On Fri, Nov 11, 2022 at 01:45:03PM +0200, Andy Shevchenko 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.
> 
> Thank you!
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> P.S.
> It's good we have this report, which means I have to reconsider the
> followup I'm cooking. In any case I will send it after v6.2-rc1 for
> broader testing.

Feel free to add me on Cc if you need the patches tested on OF systems.

Thierry

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

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Robert Marko]

On 11. 11. 2022. 12:37, 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>

Hi, I can confirm this fixes the blamed commit on Qualcomm IPQ8074.

Tested-by: Robert Marko <robimarko@gmail.com>

> ---
>   drivers/gpio/gpiolib-of.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 4be3c21aa718..55c3712592db 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
>   	struct device_node *np;
>   	int ret;
>   
> -	np = to_of_node(chip->fwnode);
> +	np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
>   	if (!np)
>   		return 0;
>   

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Andrew Halaney]

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>

Tested-by: Andrew Halaney <ahalaney@redhat.com>

This fixes issues I ran into today on my sa8540p-ride board.

Thanks,
Andrew

> ---
>  drivers/gpio/gpiolib-of.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 4be3c21aa718..55c3712592db 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
>  	struct device_node *np;
>  	int ret;
>  
> -	np = to_of_node(chip->fwnode);
> +	np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
>  	if (!np)
>  		return 0;
>  
> -- 
> 2.38.1
> 

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Brian Masney]

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

I'm still not sure what caused this breakage in linux-next.

Brian

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Geert Uytterhoeven]

Hi Thierry,

On Fri, Nov 11, 2022 at 12:40 PM Thierry Reding
<thierry.reding@gmail.com> 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")

Thank you, I bisected boot failures on Renesas platforms to that
commit, and then found your patch.

> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>

Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

> ---
>  drivers/gpio/gpiolib-of.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 4be3c21aa718..55c3712592db 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
>         struct device_node *np;
>         int ret;
>
> -       np = to_of_node(chip->fwnode);
> +       np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
>         if (!np)
>                 return 0;
>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Marijn Suijten]

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/

- Marijn

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Brian Masney]

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/

Thierry's patch fixes the issue that I encountered in
of_gpiochip_match_node_and_xlate() on the Qualcomm sa8540p automotive
board. I don't get the stack dump that you encountered. I am having
issues with probe deferrals on UFS when trying to acquire the
reset-gpio.

The patch I posted feels hacky (hence the RFC) but if the maintainers
agree with it then I can clean up the commit message and post a v2.

Brian

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Bartosz Golaszewski]

On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding
<thierry.reding@gmail.com> 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>
> ---
>  drivers/gpio/gpiolib-of.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 4be3c21aa718..55c3712592db 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip)
>         struct device_node *np;
>         int ret;
>
> -       np = to_of_node(chip->fwnode);
> +       np = to_of_node(dev_fwnode(&chip->gpiodev->dev));
>         if (!np)
>                 return 0;
>
> --
> 2.38.1
>

Applied, thanks!

Bart

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Thierry Reding]

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

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Andy Shevchenko]

On Wed, Nov 16, 2022 at 11:26:34AM +0100, Thierry Reding wrote:
> 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?

Yes, they fix the 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)?

I don't know why we would need this. Brian's patch (already applied into
GPIO tree) is correct, no? (Moreover, it makes yours unneeded, but I'm fine
with having it anyway.)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Thierry Reding]

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

On Wed, Nov 16, 2022 at 12:38:24PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 16, 2022 at 11:26:34AM +0100, Thierry Reding wrote:
> > 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?
> 
> Yes, they fix the 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)?
> 
> I don't know why we would need this. Brian's patch (already applied into
> GPIO tree) is correct, no? (Moreover, it makes yours unneeded, but I'm fine
> with having it anyway.)

I've explained this in the reply to Brian's patch, but I don't think we
want to use gc->fwnode other than initially to override the fwnode that
the GPIO chip uses. It might even be worth turning it into a parameter
to gpiochip_add() to avoid the ambiguity we have right now where we
store the same fwnode in two different places and end up using either
depending on whoever wrote the patch and what mood they were in. There
really should only be one place to store this pointer to avoid this sort
of ambiguity.

Thierry

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

Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips

[Marijn Suijten]

On 2022-11-16 11:26:34, Thierry Reding wrote:
> 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)?

Yes that solves it too, thanks!

- Marijn