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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Wed, Nov 19, 2025 at 03:58:08AM -0800, Bartosz Golaszewski wrote:
> On Wed, 19 Nov 2025 12:24:09 +0100, Charles Keepax
> <ckeepax@opensource.cirrus.com> said:
> > On Wed, Nov 19, 2025 at 12:06:57PM +0100, Bartosz Golaszewski wrote:
> >> On Wed, Nov 19, 2025 at 11:58 AM Andy Shevchenko
> > 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.
> >
> 
> You probably mean this line:
> 
>      device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent));

Indeed yeah that one.

> What is the actual device whose node we copy here? Would doing the following
> help?

Its the actual ACPI node for the device, the cs42l43, sorry if
that isn't what you are looking for not sure I totally follow the
question here.

> -	device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent));
> +	acpi_fwnode = acpi_fwnode_handle(adev ?: parent);
> +
> +	if (!is_software_node(acpi_fwnode) || !cell->swnode)
> +		device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent));
>  }
>  #else
>  static inline void mfd_acpi_add_device(const struct mfd_cell *cell,
> 
> > 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.
> >
> 
> If my logic above is right, we should not set the node here unless it's
> an actual node coming from firmware OR the cell doesn't define its own
> software node.

Will that not leave the MFD children without access to the actual ACPI
node though? (Not tested just eye-balling).

Can we tackle this the other way around? Since there is only a
single fwnode for the device, can we find a way to get away with
a single software node for the device too?

Thanks,
Charles