linux-kernel - Re: [PATCH] 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] [day] [month] [year] [list]

Message-ID: <ac9132249e594001801c2bbbc4245ff2e40c7a62.camel@pengutronix.de>
Date: Wed, 26 Nov 2025 11:38:11 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Val Packett <val@...kett.cool>, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, Bartosz
 Golaszewski	 <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH] reset: gpio: add a devlink between reset-gpio and its
 consumer

On Mi, 2025-11-26 at 09:56 +0100, Bartosz Golaszewski wrote:

[...]
> > > -static int reset_add_gpio_aux_device(struct device *parent,
> > > -                                  struct fwnode_handle *swnode,
> > > -                                  int id, void *pdata)
> > > +static struct auxiliary_device *
> > > +reset_add_gpio_aux_device(struct device *parent, struct fwnode_handle *swnode,
> > > +                       int id, void *pdata)
> > 
> > This function grows ever more similar to auxiliary_device_create().
> > 
> 
> I could have used it if not for the fact that it calls
> device_set_of_node_from_dev() and we don't want it.
> 
> > s/add/create/?
> 
> I don't mind but would prefer to not overload this patch.

Ok.

[...]
> > > +     consumer = get_dev_from_fwnode(of_fwnode_handle(np));
> > 
> > If called via __reset_control_get(), this just reconstructs the device
> > from dev->of_node. I think it would be better to move the linking into
> > __reset_control_get() and use the passed in consumer device directly.
> > 
> 
> That would affect all users, do we want this? In most cases they will
> already have a link with different flags. I don't think this is
> correct.

Right. We could also pass an optional dev into __of_reset_control_get()
and then just go

	if (gpio_fallback)
		device_link_add(dev, rcdev->dev, DL_FLAG_STATELESS);

at the end.

> > > +     if (consumer) {
> > > +             if (!device_link_add(consumer, &rgpio_dev->adev->dev, DL_FLAG_STATELESS))
> > 
> > Who removes this link when the consumer puts the reset control, or if
> > we error out later?
> > 
> 
> Nobody. Here's why: the reset-gpio device never gets removed. If we're
> here, this means it's already registered. If the consumer is unbound,
> the devlink stays in place. When we rebind, device_link_add() will do
> nothing. If the consumer device is released, we purge all links
> anyway. Let me know if I'm wrong, but seems to me, it's fine to leave
> it and make it stateless.

I think you are right. Still, the device_link_add() documentation says
that the caller is expected to call device_link_del/remove() and we
don't, so warrants a comment.

regards
Philipp