diff mbox series

gpiolib: of: Use correct fwnode for DT-probed chips

Message ID 20221111113732.461881-1-thierry.reding@gmail.com
State New
Headers
Series gpiolib: of: Use correct fwnode for DT-probed chips |

Commit Message

Thierry Reding Nov. 11, 2022, 11:37 a.m. UTC 
  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(-)

Comments

Andy Shevchenko Nov. 11, 2022, 11:45 a.m. UTC | #1 
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
>
Linus Walleij Nov. 11, 2022, 2:21 p.m. UTC | #2 
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
Thierry Reding Nov. 11, 2022, 3:12 p.m. UTC | #3 
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
Robert Marko Nov. 12, 2022, 12:59 p.m. UTC | #4 
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;
>
Andrew Halaney Nov. 14, 2022, 9:12 p.m. UTC | #5 
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
>
Brian Masney Nov. 14, 2022, 9:15 p.m. UTC | #6 
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
Geert Uytterhoeven Nov. 15, 2022, 11:13 a.m. UTC | #7 
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
Marijn Suijten Nov. 15, 2022, 11:18 a.m. UTC | #8 
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
Brian Masney Nov. 15, 2022, 11:41 a.m. UTC | #9 
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
Bartosz Golaszewski Nov. 15, 2022, 2:38 p.m. UTC | #10 
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
Thierry Reding Nov. 16, 2022, 10:26 a.m. UTC | #11 
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 ---
Andy Shevchenko Nov. 16, 2022, 10:38 a.m. UTC | #12 
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.)
Thierry Reding Nov. 16, 2022, 2:05 p.m. UTC | #13 
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
Marijn Suijten Nov. 16, 2022, 4:06 p.m. UTC | #14 
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
diff mbox series

Patch

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;