On Mon, Nov 27, 2023 at 7:21 PM Greg KH <[email protected]> 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 <[email protected]> > > > --- > > > 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
