lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ