Re: [PATCH v2 2/2] gpiolib: match secondary fwnode too in gpio_device_find_by_fwnode()

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Rafael,

On Mon, Feb 23, 2026 at 06:46:38PM +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 23, 2026 at 6:23 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Bartosz,
> >
> > Thanks for the patch.
> >
> > On Mon, Feb 23, 2026 at 04:40:53PM +0100, Bartosz Golaszewski wrote:
> > > In GPIOLIB, during fwnode lookup, after having resolved the consumer's
> > > reference to a specific fwnode, we only match it against the primary
> > > node of the controllers. Let's extend that to also the secondary node by
> > > reworking gpio_chip_match_by_fwnode()
> > >
> > > Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > ---
> > >  drivers/gpio/gpiolib.c | 12 +++++++++++-
> > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index c52200eaaaff82b12f22dd1ee8459bdd8ec10d81..7fe1d9ab1281d6c5022b9bdd8909fef2cb74122e 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -11,6 +11,7 @@
> > >  #include <linux/errno.h>
> > >  #include <linux/file.h>
> > >  #include <linux/fs.h>
> > > +#include <linux/fwnode.h>
> > >  #include <linux/idr.h>
> > >  #include <linux/interrupt.h>
> > >  #include <linux/irq.h>
> > > @@ -1395,7 +1396,16 @@ EXPORT_SYMBOL_GPL(gpio_device_find_by_label);
> > >
> > >  static int gpio_chip_match_by_fwnode(struct gpio_chip *gc, const void *fwnode)
> > >  {
> > > -     return device_match_fwnode(&gc->gpiodev->dev, fwnode);
> > > +     struct device *dev = &gc->gpiodev->dev;
> > > +     struct fwnode_handle *node = dev_fwnode(dev);
> > > +
> > > +     if (IS_ERR(fwnode))
> > > +             return 0;
> > > +
> > > +     if (device_match_fwnode(dev, fwnode))
> >
> > Could device_match_fwnode() match secondary fwnode as well?
> 
> In the previous discussion on this, Andy was against doing that due to
> the concern that it might introduce subtle bugs, which I agree with.

Could you elaborate or provide an example?

The function has some 27 users although few are individual drivers.

My understanding is that we only have the secondary fwnode for being able
to attach objects from different backend to the same node. The fwnode API
in the meantime generally tries to hide the existence of the secondary
fwnode; a rewrite (which ideally would have happened perhaps a few years
ago?) would probably make the fwnode a linked list instead so we'd lose
that secondary pointer in the process.

-- 
Kind regards,

Sakari Ailus