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

[Danilo Krummrich]

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.

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

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