From: Thierry Reding <[email protected]>
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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
---
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
On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding
<[email protected]> wrote:
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
On 11. 11. 2022. 12:37, Thierry Reding wrote:
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
Hi, I can confirm this fixes the blamed commit on Qualcomm IPQ8074.
Tested-by: Robert Marko <[email protected]>
> ---
> 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;
>
On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
Tested-by: Andrew Halaney <[email protected]>
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
>
On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
Reviewed-by: Brian Masney <[email protected]>
Tested-by: Brian Masney <[email protected]>
I separately sent a similar type of patch to fix the same issue today:
https://lore.kernel.org/linux-arm-msm/[email protected]/T/#u
I'm still not sure what caused this breakage in linux-next.
Brian
Hi Thierry,
On Fri, Nov 11, 2022 at 12:40 PM Thierry Reding
<[email protected]> wrote:
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
> ---
> 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 -- [email protected]
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
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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Thierry Reding <[email protected]>
>
> Reviewed-by: Brian Masney <[email protected]>
> Tested-by: Brian Masney <[email protected]>
>
> I separately sent a similar type of patch to fix the same issue today:
> https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
- Marijn
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 <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Signed-off-by: Thierry Reding <[email protected]>
> >
> > Reviewed-by: Brian Masney <[email protected]>
> > Tested-by: Brian Masney <[email protected]>
> >
> > I separately sent a similar type of patch to fix the same issue today:
> > https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
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
On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding
<[email protected]> wrote:
>
> From: Thierry Reding <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Thierry Reding <[email protected]>
> ---
> 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
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 <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Signed-off-by: Thierry Reding <[email protected]>
> >
> > Reviewed-by: Brian Masney <[email protected]>
> > Tested-by: Brian Masney <[email protected]>
> >
> > I separately sent a similar type of patch to fix the same issue today:
> > https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
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 ---
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 <[email protected]>
> > > >
> > > > 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 <[email protected]>
> > > > Signed-off-by: Thierry Reding <[email protected]>
> > >
> > > Reviewed-by: Brian Masney <[email protected]>
> > > Tested-by: Brian Masney <[email protected]>
> > >
> > > I separately sent a similar type of patch to fix the same issue today:
> > > https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
>
> 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
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 <[email protected]>
> > > > >
> > > > > 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 <[email protected]>
> > > > > Signed-off-by: Thierry Reding <[email protected]>
> > > >
> > > > Reviewed-by: Brian Masney <[email protected]>
> > > > Tested-by: Brian Masney <[email protected]>
> > > >
> > > > I separately sent a similar type of patch to fix the same issue today:
> > > > https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
> >
> > 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
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 <[email protected]>
> > > >
> > > > 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 <[email protected]>
> > > > Signed-off-by: Thierry Reding <[email protected]>
> > >
> > > Reviewed-by: Brian Masney <[email protected]>
> > > Tested-by: Brian Masney <[email protected]>
> > >
> > > I separately sent a similar type of patch to fix the same issue today:
> > > https://lore.kernel.org/linux-arm-msm/[email protected]/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/[email protected]/
>
> 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