From: Greg KH <gregkh@linuxfoundation•org>
To: Bartosz Golaszewski <brgl@bgdev•pl>
Cc: Bartosz Golaszewski <brgl@kernel•org>,
Maxime Ripard <mripard@kernel•org>,
rafael@kernel•org, linux-kernel@vger•kernel.org,
dri-devel@lists•freedesktop.org, linux-next@vger•kernel.org,
sfr@canb•auug.org.au, andrzej.hajda@intel•com,
neil.armstrong@linaro•org, rfoss@kernel•org,
Laurent.pinchart@ideasonboard•com, jonas@kwiboo•se,
jernej.skrabec@gmail•com, maarten.lankhorst@linux•intel.com,
tzimmermann@suse•de, airlied@gmail•com, daniel@ffwll•ch,
angelogioacchino.delregno@collabora•com, ulf.hansson@linaro•org,
linus.walleij@linaro•org, Liu Ying <victor.liu@nxp•com>
Subject: Re: [PATCH v2 1/2] driver core: Export device_is_dependent() to modules
Date: Wed, 3 Dec 2025 16:47:54 +0100 [thread overview]
Message-ID: <2025120326-treat-unstopped-f883@gregkh> (raw)
In-Reply-To: <CAMRc=Meb0-Q7UCPhbfQ+pLybS2Jp=QpwxXGXNfQ+Ti64okoqYw@mail.gmail.com>
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@linuxfoundation•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
next prev parent reply other threads:[~2025-12-03 17:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 5:14 [PATCH v2 0/2] drm/bridge: panel: Check device dependency before managing device link Liu Ying
2023-11-27 5:14 ` [PATCH v2 1/2] driver core: Export device_is_dependent() to modules Liu Ying
2023-11-27 16:38 ` Maxime Ripard
2023-11-27 18:20 ` Greg KH
2023-11-27 22:34 ` Linus Walleij
2025-11-26 13:13 ` Bartosz Golaszewski
2025-11-27 8:29 ` Greg KH
2025-11-27 13:19 ` Bartosz Golaszewski
2025-12-03 15:47 ` Greg KH [this message]
2025-12-04 10:14 ` Bartosz Golaszewski
2023-11-27 5:14 ` [PATCH v2 2/2] drm/bridge: panel: Check device dependency before managing device link Liu Ying
2023-11-27 16:03 ` [PATCH v2 0/2] " Linus Walleij
2023-11-27 16:29 ` Maxime Ripard
2023-11-27 22:13 ` Linus Walleij
2023-11-29 12:32 ` Maxime Ripard
2023-11-29 14:38 ` Linus Walleij
2023-11-30 10:05 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025120326-treat-unstopped-f883@gregkh \
--to=gregkh@linuxfoundation$(echo .)org \
--cc=Laurent.pinchart@ideasonboard$(echo .)com \
--cc=airlied@gmail$(echo .)com \
--cc=andrzej.hajda@intel$(echo .)com \
--cc=angelogioacchino.delregno@collabora$(echo .)com \
--cc=brgl@bgdev$(echo .)pl \
--cc=brgl@kernel$(echo .)org \
--cc=daniel@ffwll$(echo .)ch \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=jernej.skrabec@gmail$(echo .)com \
--cc=jonas@kwiboo$(echo .)se \
--cc=linus.walleij@linaro$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=maarten.lankhorst@linux$(echo .)intel.com \
--cc=mripard@kernel$(echo .)org \
--cc=neil.armstrong@linaro$(echo .)org \
--cc=rafael@kernel$(echo .)org \
--cc=rfoss@kernel$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tzimmermann@suse$(echo .)de \
--cc=ulf.hansson@linaro$(echo .)org \
--cc=victor.liu@nxp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox