[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <94683609-5a52-494c-9041-85c2ef40da34@kernel.org>
Date: Wed, 11 Feb 2026 12:57:33 +0100
From: Hans de Goede <hansg@...nel.org>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
Linus Walleij <linusw@...nel.org>, Bartosz Golaszewski <brgl@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>, Arnd Bergmann
<arnd@...nel.org>, Ilpo Järvinen
<ilpo.jarvinen@...ux.intel.com>, Dan Carpenter <dan.carpenter@...aro.org>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] gpio: swnode: restore the
swnode-name-against-chip-label matching
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@...r.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@...ux.intel.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <johannes.goede@....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);
> }
>
Powered by blists - more mailing lists