linux-kernel - Re: [PATCH v2 1/2] driver core: Export device_is

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: <2025120326-treat-unstopped-f883@gregkh>
Date: Wed, 3 Dec 2025 16:47:54 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bartosz Golaszewski <brgl@...nel.org>,
	Maxime Ripard <mripard@...nel.org>, rafael@...nel.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-next@...r.kernel.org, sfr@...b.auug.org.au,
	andrzej.hajda@...el.com, neil.armstrong@...aro.org,
	rfoss@...nel.org, Laurent.pinchart@...asonboard.com,
	jonas@...boo.se, jernej.skrabec@...il.com,
	maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
	airlied@...il.com, daniel@...ll.ch,
	angelogioacchino.delregno@...labora.com, ulf.hansson@...aro.org,
	linus.walleij@...aro.org, Liu Ying <victor.liu@....com>
Subject: Re: [PATCH v2 1/2] driver core: Export device_is_dependent() to
 modules

On Thu, Nov 27, 2025 at 05:19:19AM -0800, Bartosz Golaszewski wrote:
> On Thu, 27 Nov 2025 09:29:03 +0100, Greg KH <gregkh@...uxfoundation.org> said:
> > On Wed, Nov 26, 2025 at 02:13:03PM +0100, Bartosz Golaszewski wrote:
> >> The logical thing to do would be to use "device_is_dependent()" but
> >> this thread makes me think that won't fly.
> >>
> >> What should I do? What's the "correct" way of checking if two devices
> >> are linked? I assume that fiddling with the supplier/consumer lists in
> >> struct device is not it.
> >
> > fiddling with those lists is what device_is_dependent() does, but no,
> > you really don't want to be doing that either manually or by calling
> > this function.
> >
> > Who is creating this "link"?  Can't that caller tell the gpio core this
> > relationship at the same time as you are wanting to keep track of it
> > too?
> >
> 
> The link would be created in reset core.
> 
> Let's consider the following:
> 
> GPIO Consumer A ---> reset-gpio ---> |
>                                      | GPIO Controller pin X
> GPIO Consumer B -------------------> |
> 
> The GPIO core will scan the device tree and realize that A and B share the
> same pin. The reset-gpio device is not described in firmware, it will be
> created only when A requests a reset control. When it, on behalf of consumer A,
> requests pin X, GPIO core can not associate the link between consumer A and
> pin X with the link between reset-gpio and pin X because there's no such
> reference in firmware nodes between consumer A and reset-gpio. To GPIO, these
> are two separate references to the same pin. Only reset core knows about A
> being the consumer of reset-gpio.
> 
> We could add a function in reset like:
> 
>   struct device *reset_gpio_to_reset_device(struct device *dev);
> 
> which would return the actual consumer of pin X for a device we identified as
> reset-gpio (for instance: with device_is_compatible(dev, "reset-gpio")) but
> that would be adding a symbol for a corner case and a single user and for
> which the relevant information already exists and could easily be retrieved
> from existing device links.
> 
> I hope that explains it better.

Yes it does, thanks.

> To answer your question: the caller can't tell GPIO about this relationship,
> GPIO would have to ask reset about it but having a dedicated symbol for this
> doesn't really sound like the best approach.

Ah, ick, no it doesn't.  I really don't know what to suggest here,
sorry.

greg k-h