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=Mc3T1u1sa0P+78dfhtoyBPc+9zsJ5sGP=ZLR+S=h16vZg@mail.gmail.com>
Date: Wed, 26 Nov 2025 14:13:03 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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 Mon, Nov 27, 2023 at 7:21 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Nov 27, 2023 at 05:38:13PM +0100, Maxime Ripard wrote:
> > Greg, Rafael,
> >
> > On Mon, Nov 27, 2023 at 01:14:13PM +0800, Liu Ying wrote:
> > > Export device_is_dependent() since the drm_kms_helper module is starting
> > > to use it.
> > >
> > > Signed-off-by: Liu Ying <victor.liu@....com>
> > > ---
> > > v2:
> > > * Newly introduced as needed by patch 2.
> > >
> > >  drivers/base/core.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 67ba592afc77..bfd2bf0364b7 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -328,6 +328,7 @@ int device_is_dependent(struct device *dev, void *target)
> > >     }
> > >     return ret;
> > >  }
> > > +EXPORT_SYMBOL_GPL(device_is_dependent);
> >
> > So, a committer just applied this to drm-misc-fixes without your
> > approval. Could you ack it? If you don't want to, we'll fix it.
>
> Wait, why exactly is this needed?  Nothing outside of the driver core
> should be needing this function, it shouldn't be public at all (I missed
> that before.)
>

Hi Greg!

Sorry for reviving this old thread but I stumbled upon it when looking
for information on whether anyone ever tried to export
device_is_dependent() before.

I have a use-case where I think I need to check if two devices are
linked with a device link. I assume you'll prove me wrong. :)

The reset-gpio driver is a reset control driver that mediates sharing
a reset GPIO (defined as a standardized reference fwnode property
"reset-gpios") among multiple users. reset-gpio auxiliary devices are
instantiated from reset core when it detects a consumer trying to get
a reset-control handle but there's no "resets" reference on the
consumer's fwnode, only "reset-gpios".

It makes sense for reset core to create a device link between the
auxiliary reset-gpio device (the supplier) and the reset consumer
because this link is not described in firmware - only the link between
the consumer AND the GPIO controller.

Now in order to make gpiolib-shared.c code (generic support for shared
GPIOs) happy, I need to handle the side effects of interacting with
reset-gpio which does a similar thing. To that end, I need to know if
given GPIO controller is a supplier of the consumer described in
firmware OR the auxiliary reset device which is only described with
software nodes.

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.

Thanks,
Bartosz