Re: [PATCH 1/2] driver core: provide device_match_fwnode_ext()

[Rafael J. Wysocki]

On Fri, Feb 20, 2026 at 4:43 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> On Fri Feb 20, 2026 at 1:08 PM CET, Rafael J. Wysocki wrote:
> > Secondary fwnodes were not intended for device matching in the first
> > place.  The idea was to use them as a secondary supply of device
> > properties that may be missing from the primary node (think of an ACPI
> > device object accompanied by a software node supplying properties that
> > cannot be derived from the former).  They could be added by a driver
> > after matching the primary node for the benefit of a generic
> > framework.
> >
> > IMV, the example with children inheriting the fwnode from their parent
> > where the user wants to add a different secondary node to each child
> > doesn't really match the picture described above.  At least it was not
> > anticipated.  The idea was to allow the parent's fwnode to be extended
> > and then (possibly) inherited.
> >
> > That's why the secondary fwnode pointer is there under the primary one.
> >
> > So all of this goes beyond the original anticipated use of secondary
> > fwnodes and it seems to be calling for a list of equivalent (not
> > primary and secondary) fwnodes in struct device, but then of course
> > there's the question about duplicate properties and whether or not the
> > fwnode used for driver binding should be preferred (I don't see why
> > not).
> >
> > Until all of this is resolved, I wouldn't even add a generic helper
> > for matching secondary nodes.  I'd just put this code directly into
> > gpio_chip_match_by_fwnode() along with a big fat comment explaining
> > why exactly secondary nodes need to be taken into account there.
>
> I'm aware that secondary software nodes were originally intended to supply
> missing properties only.
>
> However, I wonder whether the capability to match against them isn't actually a
> natural, unavoidable consequence of how software nodes can be used to bridge
> (broken) connections between providers and consumers.
>
> Or said differently, once PROPERTY_ENTRY_GPIO() - or more generically
> PROPERTY_ENTRY_REF() - was introduced, it exposed secondary nodes within the
> device graph, which subsystems have to consider.
>
> IIUC, this is also the reason why gpiod_fwnode_lookup() [1] (which is eventually
> called from gpiod_get()) has to consider secondary nodes.

Well, in practice, is there any subsystem other than gpio that has to
consider them?

> So, if I'm not mistaken with the above, it seems fair to provide such a helper.

In the absence of any, the helper doesn't seem necessary.

> [1] https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpio/gpiolib.c#L4675