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

From: Bartosz Golaszewski

Date: Wed Nov 19 2025 - 08:08:08 EST


On Wed, Nov 19, 2025 at 1:53 PM Charles Keepax
<ckeepax@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxxxxxxx> 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.
>

So it's !is_software_node() and is_acpi_device_node() instead? Then
disregard my suggestion.

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

Yeah, nevermind it.

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

I still don't understand what the software node that's already
assigned to the SPI device is though? device_add_software_node()
should work just fine if the only other firmware node the device has
is the ACPI device node.

Bart