public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
@ 2026-02-11  8:53 Bartosz Golaszewski
  2026-02-11 11:57 ` Hans de Goede
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Bartosz Golaszewski @ 2026-02-11  8:53 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
	Greg Kroah-Hartman, Dmitry Torokhov, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter
  Cc: linux-gpio, linux-kernel, platform-driver-x86,
	Bartosz Golaszewski, stable

Using the remote firmware node for software node lookup is the right
thing to do. The GPIO controller we want to resolve should have the
software node we scooped out of the reference attached to it. However,
there are existing users who abuse the software node API by creating
dummy swnodes whose name is set to the expected label string of the GPIO
controller whose pins they want to control and use them in their local
swnode references as GPIO properties.

This used to work when we compared the software node's name to the
chip's label. When we switched to using a real fwnode lookup, these
users broke down because the firmware nodes in question were never
attached to the controllers they were looking for.

Restore the label matching as a fallback to fix the broken users but add
a big FIXME urging for a better solution.

Cc: stable@vger.kernel.org # v6.18, v6.19
Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v2:
- check if gdev_node and gdev_node->name are not NULL before trying to
  match the label (Hans & Dan)
- use the right link
- collect tags

 drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
index 21478b45c127d..0d7f3f09a0b4b 100644
--- a/drivers/gpio/gpiolib-swnode.c
+++ b/drivers/gpio/gpiolib-swnode.c
@@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
 
 fwnode_lookup:
 	gdev = gpio_device_find_by_fwnode(fwnode);
+	if (!gdev && gdev_node && gdev_node->name)
+		/*
+		 * FIXME: We shouldn't need to compare the GPIO controller's
+		 * label against the software node that is supposedly attached
+		 * to it. However there are currently GPIO users that - knowing
+		 * the expected label of the GPIO chip whose pins they want to
+		 * control - set up dummy software nodes named after those GPIO
+		 * controllers, which aren't actually attached to them. In this
+		 * case gpio_device_find_by_fwnode() will fail as no device on
+		 * the GPIO bus is actually associated with the fwnode we're
+		 * looking for.
+		 *
+		 * As a fallback: continue checking the label if we have no
+		 * match. However, the situation described above is an abuse
+		 * of the software node API and should be phased out and the
+		 * following line - eventually removed.
+		 */
+		gdev = gpio_device_find_by_label(gdev_node->name);
+
 	return gdev ?: ERR_PTR(-EPROBE_DEFER);
 }
 
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-11  8:53 [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching Bartosz Golaszewski
@ 2026-02-11 11:57 ` Hans de Goede
  2026-02-18  0:31 ` Dmitry Torokhov
  2026-02-18  8:43 ` Bartosz Golaszewski
  2 siblings, 0 replies; 9+ messages in thread
From: Hans de Goede @ 2026-02-11 11:57 UTC (permalink / raw)
  To: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski,
	Andy Shevchenko, Greg Kroah-Hartman, Dmitry Torokhov,
	Arnd Bergmann, Ilpo Järvinen, Dan Carpenter
  Cc: linux-gpio, linux-kernel, platform-driver-x86, stable

Hi,

On 11-Feb-26 09:53, Bartosz Golaszewski wrote:
> Using the remote firmware node for software node lookup is the right
> thing to do. The GPIO controller we want to resolve should have the
> software node we scooped out of the reference attached to it. However,
> there are existing users who abuse the software node API by creating
> dummy swnodes whose name is set to the expected label string of the GPIO
> controller whose pins they want to control and use them in their local
> swnode references as GPIO properties.
> 
> This used to work when we compared the software node's name to the
> chip's label. When we switched to using a real fwnode lookup, these
> users broke down because the firmware nodes in question were never
> attached to the controllers they were looking for.
> 
> Restore the label matching as a fallback to fix the broken users but add
> a big FIXME urging for a better solution.
> 
> Cc: stable@vger.kernel.org # v6.18, v6.19
> Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans




> ---
> Changes in v2:
> - check if gdev_node and gdev_node->name are not NULL before trying to
>   match the label (Hans & Dan)
> - use the right link
> - collect tags
> 
>  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> index 21478b45c127d..0d7f3f09a0b4b 100644
> --- a/drivers/gpio/gpiolib-swnode.c
> +++ b/drivers/gpio/gpiolib-swnode.c
> @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
>  
>  fwnode_lookup:
>  	gdev = gpio_device_find_by_fwnode(fwnode);
> +	if (!gdev && gdev_node && gdev_node->name)
> +		/*
> +		 * FIXME: We shouldn't need to compare the GPIO controller's
> +		 * label against the software node that is supposedly attached
> +		 * to it. However there are currently GPIO users that - knowing
> +		 * the expected label of the GPIO chip whose pins they want to
> +		 * control - set up dummy software nodes named after those GPIO
> +		 * controllers, which aren't actually attached to them. In this
> +		 * case gpio_device_find_by_fwnode() will fail as no device on
> +		 * the GPIO bus is actually associated with the fwnode we're
> +		 * looking for.
> +		 *
> +		 * As a fallback: continue checking the label if we have no
> +		 * match. However, the situation described above is an abuse
> +		 * of the software node API and should be phased out and the
> +		 * following line - eventually removed.
> +		 */
> +		gdev = gpio_device_find_by_label(gdev_node->name);
> +
>  	return gdev ?: ERR_PTR(-EPROBE_DEFER);
>  }
>  


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-11  8:53 [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching Bartosz Golaszewski
  2026-02-11 11:57 ` Hans de Goede
@ 2026-02-18  0:31 ` Dmitry Torokhov
  2026-02-18  8:42   ` Bartosz Golaszewski
  2026-02-18  8:43 ` Bartosz Golaszewski
  2 siblings, 1 reply; 9+ messages in thread
From: Dmitry Torokhov @ 2026-02-18  0:31 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> Using the remote firmware node for software node lookup is the right
> thing to do. The GPIO controller we want to resolve should have the
> software node we scooped out of the reference attached to it. However,
> there are existing users who abuse the software node API by creating
> dummy swnodes whose name is set to the expected label string of the GPIO
> controller whose pins they want to control and use them in their local
> swnode references as GPIO properties.
> 
> This used to work when we compared the software node's name to the
> chip's label. When we switched to using a real fwnode lookup, these
> users broke down because the firmware nodes in question were never
> attached to the controllers they were looking for.
> 
> Restore the label matching as a fallback to fix the broken users but add
> a big FIXME urging for a better solution.
> 
> Cc: stable@vger.kernel.org # v6.18, v6.19
> Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Changes in v2:
> - check if gdev_node and gdev_node->name are not NULL before trying to
>   match the label (Hans & Dan)
> - use the right link
> - collect tags
> 
>  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> index 21478b45c127d..0d7f3f09a0b4b 100644
> --- a/drivers/gpio/gpiolib-swnode.c
> +++ b/drivers/gpio/gpiolib-swnode.c
> @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
>  
>  fwnode_lookup:
>  	gdev = gpio_device_find_by_fwnode(fwnode);

By the way, should we extend gpio_device_find_by_fwnode() to use both
primary and secondary nodes?

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-18  0:31 ` Dmitry Torokhov
@ 2026-02-18  8:42   ` Bartosz Golaszewski
  2026-02-18 17:15     ` Dmitry Torokhov
  0 siblings, 1 reply; 9+ messages in thread
From: Bartosz Golaszewski @ 2026-02-18  8:42 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 18, 2026 at 1:31 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> > Using the remote firmware node for software node lookup is the right
> > thing to do. The GPIO controller we want to resolve should have the
> > software node we scooped out of the reference attached to it. However,
> > there are existing users who abuse the software node API by creating
> > dummy swnodes whose name is set to the expected label string of the GPIO
> > controller whose pins they want to control and use them in their local
> > swnode references as GPIO properties.
> >
> > This used to work when we compared the software node's name to the
> > chip's label. When we switched to using a real fwnode lookup, these
> > users broke down because the firmware nodes in question were never
> > attached to the controllers they were looking for.
> >
> > Restore the label matching as a fallback to fix the broken users but add
> > a big FIXME urging for a better solution.
> >
> > Cc: stable@vger.kernel.org # v6.18, v6.19
> > Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> > Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> > Changes in v2:
> > - check if gdev_node and gdev_node->name are not NULL before trying to
> >   match the label (Hans & Dan)
> > - use the right link
> > - collect tags
> >
> >  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > index 21478b45c127d..0d7f3f09a0b4b 100644
> > --- a/drivers/gpio/gpiolib-swnode.c
> > +++ b/drivers/gpio/gpiolib-swnode.c
> > @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
> >
> >  fwnode_lookup:
> >       gdev = gpio_device_find_by_fwnode(fwnode);
>
> By the way, should we extend gpio_device_find_by_fwnode() to use both
> primary and secondary nodes?
>

That's already done on a higher lever for all fwnodes in gpiod_fwnode_lookup().

Bartosz

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-11  8:53 [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching Bartosz Golaszewski
  2026-02-11 11:57 ` Hans de Goede
  2026-02-18  0:31 ` Dmitry Torokhov
@ 2026-02-18  8:43 ` Bartosz Golaszewski
  2 siblings, 0 replies; 9+ messages in thread
From: Bartosz Golaszewski @ 2026-02-18  8:43 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
	Greg Kroah-Hartman, Dmitry Torokhov, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel, platform-driver-x86, stable


On Wed, 11 Feb 2026 09:53:13 +0100, Bartosz Golaszewski wrote:
> Using the remote firmware node for software node lookup is the right
> thing to do. The GPIO controller we want to resolve should have the
> software node we scooped out of the reference attached to it. However,
> there are existing users who abuse the software node API by creating
> dummy swnodes whose name is set to the expected label string of the GPIO
> controller whose pins they want to control and use them in their local
> swnode references as GPIO properties.
> 
> [...]

Applied, thanks!

[1/1] gpio: swnode: restore the swnode-name-against-chip-label matching
      https://git.kernel.org/brgl/c/ff91965ad8b214e0771bc5a15253f14f583a7649

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-18  8:42   ` Bartosz Golaszewski
@ 2026-02-18 17:15     ` Dmitry Torokhov
  2026-02-18 18:08       ` Bartosz Golaszewski
  0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Torokhov @ 2026-02-18 17:15 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 18, 2026 at 09:42:28AM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 18, 2026 at 1:31 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> > > Using the remote firmware node for software node lookup is the right
> > > thing to do. The GPIO controller we want to resolve should have the
> > > software node we scooped out of the reference attached to it. However,
> > > there are existing users who abuse the software node API by creating
> > > dummy swnodes whose name is set to the expected label string of the GPIO
> > > controller whose pins they want to control and use them in their local
> > > swnode references as GPIO properties.
> > >
> > > This used to work when we compared the software node's name to the
> > > chip's label. When we switched to using a real fwnode lookup, these
> > > users broke down because the firmware nodes in question were never
> > > attached to the controllers they were looking for.
> > >
> > > Restore the label matching as a fallback to fix the broken users but add
> > > a big FIXME urging for a better solution.
> > >
> > > Cc: stable@vger.kernel.org # v6.18, v6.19
> > > Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> > > Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > ---
> > > Changes in v2:
> > > - check if gdev_node and gdev_node->name are not NULL before trying to
> > >   match the label (Hans & Dan)
> > > - use the right link
> > > - collect tags
> > >
> > >  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > > index 21478b45c127d..0d7f3f09a0b4b 100644
> > > --- a/drivers/gpio/gpiolib-swnode.c
> > > +++ b/drivers/gpio/gpiolib-swnode.c
> > > @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
> > >
> > >  fwnode_lookup:
> > >       gdev = gpio_device_find_by_fwnode(fwnode);
> >
> > By the way, should we extend gpio_device_find_by_fwnode() to use both
> > primary and secondary nodes?
> >
> 
> That's already done on a higher lever for all fwnodes in gpiod_fwnode_lookup().

How exactly? I am not talking about checking secondary node for the
fwnode that is used in the reference, I am talking about secondary
fwnode that might be assigned to the gpio chip and you need to check
both primary and secondary if they match with the fwnode that you call
gpio_device_find_by_fwnode() with.

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-18 17:15     ` Dmitry Torokhov
@ 2026-02-18 18:08       ` Bartosz Golaszewski
  2026-02-18 19:22         ` Dmitry Torokhov
  0 siblings, 1 reply; 9+ messages in thread
From: Bartosz Golaszewski @ 2026-02-18 18:08 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 18, 2026 at 6:15 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Feb 18, 2026 at 09:42:28AM +0100, Bartosz Golaszewski wrote:
> > On Wed, Feb 18, 2026 at 1:31 AM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> > > > Using the remote firmware node for software node lookup is the right
> > > > thing to do. The GPIO controller we want to resolve should have the
> > > > software node we scooped out of the reference attached to it. However,
> > > > there are existing users who abuse the software node API by creating
> > > > dummy swnodes whose name is set to the expected label string of the GPIO
> > > > controller whose pins they want to control and use them in their local
> > > > swnode references as GPIO properties.
> > > >
> > > > This used to work when we compared the software node's name to the
> > > > chip's label. When we switched to using a real fwnode lookup, these
> > > > users broke down because the firmware nodes in question were never
> > > > attached to the controllers they were looking for.
> > > >
> > > > Restore the label matching as a fallback to fix the broken users but add
> > > > a big FIXME urging for a better solution.
> > > >
> > > > Cc: stable@vger.kernel.org # v6.18, v6.19
> > > > Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> > > > Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> > > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > ---
> > > > Changes in v2:
> > > > - check if gdev_node and gdev_node->name are not NULL before trying to
> > > >   match the label (Hans & Dan)
> > > > - use the right link
> > > > - collect tags
> > > >
> > > >  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
> > > >  1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > > > index 21478b45c127d..0d7f3f09a0b4b 100644
> > > > --- a/drivers/gpio/gpiolib-swnode.c
> > > > +++ b/drivers/gpio/gpiolib-swnode.c
> > > > @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
> > > >
> > > >  fwnode_lookup:
> > > >       gdev = gpio_device_find_by_fwnode(fwnode);
> > >
> > > By the way, should we extend gpio_device_find_by_fwnode() to use both
> > > primary and secondary nodes?
> > >
> >
> > That's already done on a higher lever for all fwnodes in gpiod_fwnode_lookup().
>
> How exactly? I am not talking about checking secondary node for the
> fwnode that is used in the reference, I am talking about secondary
> fwnode that might be assigned to the gpio chip and you need to check
> both primary and secondary if they match with the fwnode that you call
> gpio_device_find_by_fwnode() with.
>

Right, I didn't quite get it. I was surprised to find out
device_match_fwnode() - which we use in gpiolib - does not do it
already. I'm wondering if this is something we should change in device
core or only locally.

Bartosz

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-18 18:08       ` Bartosz Golaszewski
@ 2026-02-18 19:22         ` Dmitry Torokhov
  2026-02-19  6:53           ` Andy Shevchenko
  0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Torokhov @ 2026-02-18 19:22 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 18, 2026 at 07:08:22PM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 18, 2026 at 6:15 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Wed, Feb 18, 2026 at 09:42:28AM +0100, Bartosz Golaszewski wrote:
> > > On Wed, Feb 18, 2026 at 1:31 AM Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> > > > > Using the remote firmware node for software node lookup is the right
> > > > > thing to do. The GPIO controller we want to resolve should have the
> > > > > software node we scooped out of the reference attached to it. However,
> > > > > there are existing users who abuse the software node API by creating
> > > > > dummy swnodes whose name is set to the expected label string of the GPIO
> > > > > controller whose pins they want to control and use them in their local
> > > > > swnode references as GPIO properties.
> > > > >
> > > > > This used to work when we compared the software node's name to the
> > > > > chip's label. When we switched to using a real fwnode lookup, these
> > > > > users broke down because the firmware nodes in question were never
> > > > > attached to the controllers they were looking for.
> > > > >
> > > > > Restore the label matching as a fallback to fix the broken users but add
> > > > > a big FIXME urging for a better solution.
> > > > >
> > > > > Cc: stable@vger.kernel.org # v6.18, v6.19
> > > > > Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> > > > > Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> > > > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > > ---
> > > > > Changes in v2:
> > > > > - check if gdev_node and gdev_node->name are not NULL before trying to
> > > > >   match the label (Hans & Dan)
> > > > > - use the right link
> > > > > - collect tags
> > > > >
> > > > >  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
> > > > >  1 file changed, 19 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > > > > index 21478b45c127d..0d7f3f09a0b4b 100644
> > > > > --- a/drivers/gpio/gpiolib-swnode.c
> > > > > +++ b/drivers/gpio/gpiolib-swnode.c
> > > > > @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
> > > > >
> > > > >  fwnode_lookup:
> > > > >       gdev = gpio_device_find_by_fwnode(fwnode);
> > > >
> > > > By the way, should we extend gpio_device_find_by_fwnode() to use both
> > > > primary and secondary nodes?
> > > >
> > >
> > > That's already done on a higher lever for all fwnodes in gpiod_fwnode_lookup().
> >
> > How exactly? I am not talking about checking secondary node for the
> > fwnode that is used in the reference, I am talking about secondary
> > fwnode that might be assigned to the gpio chip and you need to check
> > both primary and secondary if they match with the fwnode that you call
> > gpio_device_find_by_fwnode() with.
> >
> 
> Right, I didn't quite get it. I was surprised to find out
> device_match_fwnode() - which we use in gpiolib - does not do it
> already. I'm wondering if this is something we should change in device
> core or only locally.

Yes, I think so (change in driver core). There is only a handful of
calls to device_match_fwnode() that they can be audited to make sure the
conversion is safe.

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching
  2026-02-18 19:22         ` Dmitry Torokhov
@ 2026-02-19  6:53           ` Andy Shevchenko
  0 siblings, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2026-02-19  6:53 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Bartosz Golaszewski, Bartosz Golaszewski, Linus Walleij,
	Greg Kroah-Hartman, Arnd Bergmann, Hans de Goede,
	Ilpo Järvinen, Dan Carpenter, linux-gpio, linux-kernel,
	platform-driver-x86, stable

On Wed, Feb 18, 2026 at 11:22:07AM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 18, 2026 at 07:08:22PM +0100, Bartosz Golaszewski wrote:
> > On Wed, Feb 18, 2026 at 6:15 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Wed, Feb 18, 2026 at 09:42:28AM +0100, Bartosz Golaszewski wrote:
> > > > On Wed, Feb 18, 2026 at 1:31 AM Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > On Wed, Feb 11, 2026 at 09:53:13AM +0100, Bartosz Golaszewski wrote:
> > > > > > Using the remote firmware node for software node lookup is the right
> > > > > > thing to do. The GPIO controller we want to resolve should have the
> > > > > > software node we scooped out of the reference attached to it. However,
> > > > > > there are existing users who abuse the software node API by creating
> > > > > > dummy swnodes whose name is set to the expected label string of the GPIO
> > > > > > controller whose pins they want to control and use them in their local
> > > > > > swnode references as GPIO properties.
> > > > > >
> > > > > > This used to work when we compared the software node's name to the
> > > > > > chip's label. When we switched to using a real fwnode lookup, these
> > > > > > users broke down because the firmware nodes in question were never
> > > > > > attached to the controllers they were looking for.
> > > > > >
> > > > > > Restore the label matching as a fallback to fix the broken users but add
> > > > > > a big FIXME urging for a better solution.
> > > > > >
> > > > > > Cc: stable@vger.kernel.org # v6.18, v6.19
> > > > > > Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes")
> > > > > > Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> > > > > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > - check if gdev_node and gdev_node->name are not NULL before trying to
> > > > > >   match the label (Hans & Dan)
> > > > > > - use the right link
> > > > > > - collect tags
> > > > > >
> > > > > >  drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++
> > > > > >  1 file changed, 19 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > > > > > index 21478b45c127d..0d7f3f09a0b4b 100644
> > > > > > --- a/drivers/gpio/gpiolib-swnode.c
> > > > > > +++ b/drivers/gpio/gpiolib-swnode.c
> > > > > > @@ -42,6 +42,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
> > > > > >
> > > > > >  fwnode_lookup:
> > > > > >       gdev = gpio_device_find_by_fwnode(fwnode);
> > > > >
> > > > > By the way, should we extend gpio_device_find_by_fwnode() to use both
> > > > > primary and secondary nodes?
> > > > >
> > > >
> > > > That's already done on a higher lever for all fwnodes in gpiod_fwnode_lookup().
> > >
> > > How exactly? I am not talking about checking secondary node for the
> > > fwnode that is used in the reference, I am talking about secondary
> > > fwnode that might be assigned to the gpio chip and you need to check
> > > both primary and secondary if they match with the fwnode that you call
> > > gpio_device_find_by_fwnode() with.
> > >
> > 
> > Right, I didn't quite get it. I was surprised to find out
> > device_match_fwnode() - which we use in gpiolib - does not do it
> > already. I'm wondering if this is something we should change in device
> > core or only locally.
> 
> Yes, I think so (change in driver core). There is only a handful of
> calls to device_match_fwnode() that they can be audited to make sure the
> conversion is safe.

I believe there was already similar discussion and IIRC conclusion was to
distinguish current device_match_fwnode() with something new that will check
also secondary one. This way we can in a usual way convert drivers one-by-one
if even required.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-02-19  6:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-11  8:53 [PATCH v2] gpio: swnode: restore the swnode-name-against-chip-label matching Bartosz Golaszewski
2026-02-11 11:57 ` Hans de Goede
2026-02-18  0:31 ` Dmitry Torokhov
2026-02-18  8:42   ` Bartosz Golaszewski
2026-02-18 17:15     ` Dmitry Torokhov
2026-02-18 18:08       ` Bartosz Golaszewski
2026-02-18 19:22         ` Dmitry Torokhov
2026-02-19  6:53           ` Andy Shevchenko
2026-02-18  8:43 ` Bartosz Golaszewski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox