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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Nov 19, 2025 at 03:30:46PM +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 19, 2025 at 3:24 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > > > My idea was to mark the fwnode with __private and fix the (ab)users,
> > > > should not be so many. Can somebody mock up a coccinelle script to
> > > > find all dereferences of fwnode from struct device?
> > >
> > > I think you're underestimating the level of complexity. What about the
> > > concept of dev_fwnode()? It literally makes no sense if we switch to a
> > > list of fwnodes.
> >
> > Why not? It will return the pointer to the primary node. You can look
> > for example how the list of the DMA descriptors is done in
> > drivers/dma/dw/core.c. Not the best solution, but gives you an idea of
> > how it may look.
> 
> What even is a primary node though? You can have auxiliary devices
> without an ACPI or OF node.

The one which gives the main set of the properties for the device.
The devices that don't have it, simply have a list of fwnodes empty.

> Only with software nodes. Which one is the
> primary? The first one we add?

Yes. The problem here might be if we add the SW node before the actual FW node
appear (it can be if we created some devices before the actual FW based
enumeration happens. It would probably need to have some kind of weight
(or priority value) and list should be sorted based on that number.

> > > For it to make sense we'd have to have a kind of "dynamic" firmware
> > > node attached to a device which we'd fill with an aggregation of all
> > > properties from firmware nodes in the list.
> >
> > "Dynamic" is just a node in the list. The only potential problem here
> > is prioritisation. Should we add to the head, tail or insert? But
> > converting current approach will be straightforward.
> 
> What I have in my mind is not another firmware node in the list in
> struct device but rather a new firmware node implementation, that
> would be assigned to the device via a dedicated pointer and would be
> filled with a logical OR of properties from other firmware nodes added
> to the list.

Oh no, this won't work in corner cases. What if we actually need to "fix"
an existing primary node (there were discussions long time ago about inverting
primary/secondary in some corner cases, but it didn't appear so far as
it most likely will give tons of issues in the _current_ design)?

> Then dev_fwnode() would return this rather than any one
> of the firmware nodes from the list. Think of it as the "master
> fwnode" of a struct device.

fwnode should not be in any relations to the device, I mean when we do fwnodes,
we should not assume that it's backing the device. In the idea you shared it
won't be possible ("dedicated pointer") in mine it is (just a list of something
that may belong to the device, or to another object, doesn't matter).


-- 
With Best Regards,
Andy Shevchenko