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 11:24:09AM +0000, Charles Keepax wrote:
> On Wed, Nov 19, 2025 at 12:06:57PM +0100, Bartosz Golaszewski wrote:
> > On Wed, Nov 19, 2025 at 11:58 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Nov 19, 2025 at 11:50:09AM +0100, Bartosz Golaszewski wrote:
> > > > On Wed, Nov 19, 2025 at 11:47 AM Charles Keepax
> > > > <ckeepax@opensource.cirrus.com> wrote:
> > > > > On Wed, Nov 19, 2025 at 11:38:35AM +0100, Bartosz Golaszewski wrote:

...

> > > > > Cool, thanks for all your help here. Might take me a couple hours
> > > > > but I will get to the bottom of the EBUSY thing, and report back.
> > > >
> > > > Sure. Could you just post the stack trace down to where the EBUSY is
> > > > returned in drivers/base/swnode.c? I'd like to analyze the logic
> > > > myself too if that's not too much work for you.
> > >
> > > FWIW, there is also an interesting debug technique. Put in your driver where
> > > you get this error code something like this (after all #include directives):
> > >
> > > #undef EBUSY
> > > #define EBUSY __LINE__
> > >
> > > And then you get some error code which is line number in some C file. You can
> > > narrow down grepping of the EBUSY in the suspected files and get the one.
> > >
> > >         git grep -n -w EBUSY -- ...files of interest...
> > >
> > > Hope this saves some minutes for you.
> > 
> > Charles confirmed he gets it from device_add_software_node(). I want
> > to know how we're getting there and how we could end up already having
> > a software node.
> 
> Ok I think I see what is happening now, the swnode is created on
> the first cell (the pinctrl). Then it moves onto the second cell,
> but mfd_acpi_add_device() copies the firmware node into both
> devices, the device_set_node() call at the bottom. So it inherits
> the swnode node through that primary fwnode.

Okay, you got into fundamental problem of fwnode design it seems.

(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.

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.

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

> 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.

-- 
With Best Regards,
Andy Shevchenko