| Message ID | 20221111113732.461881-1-thierry.reding@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | gpiolib: of: Use correct fwnode for DT-probed chips | expand |
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 >
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
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
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; >
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 >
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
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
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
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
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
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 ---
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.)
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
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 --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;