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

Message-ID: <CAMRc=Meb0-Q7UCPhbfQ+pLybS2Jp=QpwxXGXNfQ+Ti64okoqYw@mail.gmail.com>
Date: Thu, 27 Nov 2025 05:19:19 -0800
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Greg KH <gregkh@...uxfoundation.org>
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, 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.

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.

Bartosz