linux-kernel - Re: [PATCH 02/15] reset: gpio: add a devlink between reset-gpio and its consumer

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a587a7ab48c4a202840ca17dc7ad540e9f65dd32.camel@pengutronix.de>
Date: Thu, 08 Jan 2026 10:02:48 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Krzysztof
 Kozlowski <krzk@...nel.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/15] reset: gpio: add a devlink between reset-gpio and
 its consumer

On Mo, 2026-01-05 at 15:15 +0100, Bartosz Golaszewski wrote:
> The device that requests the reset control managed by the reset-gpio
> device is effectively its consumer but the devlink is only established
> between it and the GPIO controller exposing the reset pin. Add a devlink
> between the consumer of the reset control and its supplier. This will
> allow us to simplify the GPIOLIB code managing shared GPIOs when
> handling the corner case of reset-gpio and gpiolib-shared interacting.
> While at it and since we need to store the address of the auxiliary
> device: don't allocate memory for the device separately but fold it into
> struct reset_gpio_lookup instead.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
> ---
>  drivers/reset/core.c | 80 ++++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 56 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 0666dfc41ca9af6fbf1768f17157b4faf7849962..813b85cb2758e129c72c09267a387108d7ad683b 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -20,6 +20,7 @@
>  #include <linux/kref.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> +#include <linux/of_platform.h>
>  #include <linux/reset.h>
>  #include <linux/reset-controller.h>
>  #include <linux/slab.h>
> @@ -77,11 +78,13 @@ struct reset_control_array {
>   * @of_args: phandle to the reset controller with all the args like GPIO number
>   * @swnode: Software node containing the reference to the GPIO provider
>   * @list: list entry for the reset_gpio_lookup_list
> + * @adev: Auxiliary device representing the reset controller
>   */
>  struct reset_gpio_lookup {
>  	struct of_phandle_args of_args;
>  	struct fwnode_handle *swnode;
>  	struct list_head list;
> +	struct auxiliary_device adev;
>  };

Now this looks like it should be renamed to struct reset_gpio_device.

[...]
> +static void reset_gpio_add_devlink(struct device_node *np,
> +				   struct reset_gpio_lookup *rgpio_dev)
> +{
> +	struct device *consumer;
> +
> +	/*
> +	 * We must use get_dev_from_fwnode() and not of_find_device_by_node()
> +	 * because the latter only considers the platform bus while we want to
> +	 * get consumers of any kind that can be associated with firmware
> +	 * nodes: auxiliary, soundwire, etc.
> +	 */
> +	consumer = get_dev_from_fwnode(of_fwnode_handle(np));
> +	if (consumer) {
> +		if (!device_link_add(consumer, &rgpio_dev->adev.dev,
> +				     DL_FLAG_AUTOREMOVE_CONSUMER))
> +			pr_warn("Failed to create a device link between reset-gpio and its consumer");
> +
> +		put_device(consumer);
> +	}
> +	/*
> +	 * else { }
> +	 *
> +	 * TODO: If ever there's a case where we need to support shared
> +	 * reset-gpios retrieved from a device node for which there's no
> +	 * device present yet, this is where we'd set up a notifier waiting
> +	 * for the device to appear in the system. This would be a lot of code
> +	 * that would go unused for now so let's cross that bridge when and if
> +	 * we get there.
> +	 */
>  }

Nice, no more DL_FLAG_STATELESS.

I still think getting back the consumer device from the device_node is
a bit more convoluted than it needs to be and that the right place to
call device_link_add() from would be fwnode_reset_control_get().

I'm fine with this as an intermediate step, though.

Reviewed-by: Philipp Zabel <p.zabel@...gutronix.de>

regards
Philipp