Re: [PATCH RFT/RFC] mfd: cs42l43: setup true links with software nodes

[Bartosz Golaszewski]

On Wed, Nov 19, 2025 at 12:53 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> Okay, you got into fundamental problem of fwnode design it seems.
>

The problem here is not that we can have a single secondary firmware
node, it's that we can only have a single software node. But that may
not be a problem because the question here is: do we in this case
really need the software node assigned by the ACPI part of the MFD
core. I'd say no, see my other response for a proposed fix.

> (below is the summary related to that, but it may be not related here)
>
> If it's the case, there is no easy solution for it right now.
>
> And going ahead, please, don't even try hacks like recreating a copy
> of needed properties from the parent fwnode to get an independent child
> fwnode.
>

Are any of these properties needed/used? If so, then maybe we should
consider allowing the primary and secondary nodes to be software
nodes?

> The proper solution OTOH should be decoupling fwnode from struct device
> and making there a list of fwnodes.
>
>         struct fwnode_handle {
>                 struct list_head node;
>                 ...
>         }
>
>         struct device {
>                 // asumming dropped of_node and fw_node
>                 struct list_head nodes;
>         }
>
> This will require at first to make sure no code dereferencing fwnode
> (and of_node) from struct device. With that enormous task done, the
> rest is much easier to achieve as it will be just API's internals
> refactoring.
>

Yeah, let's talk realistic things that we can improve now and not a
task that will take years. :)

> With that done, we may stitch as many fwnodes as we want where the order in
> the list will define match priority.
>

FWIW we can already do it without changing the fwnode_handle
structure. The secondary fwnode also has the secondary pointer so it's
effectively a linked list already.

> > I am guessing this code has perhaps been more heavily tested on
> > device tree where it is more common to have nodes for each cell,
> > whereas ACPI is far more likely to have a single firmware node for
> > the whole device.
>

Bart