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

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

On Wed, Nov 19, 2025 at 02:07:55PM +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 19, 2025 at 1:53 PM Charles Keepax
> <ckeepax@opensource.cirrus.com> 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@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
> > 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.

Its the software node we assigned to the first MFD cell, that one
succeeds but attaches itself to the ACPI node as a secondary.
When we get to the second cell we try to attach a new node but we
get the one from the first cell since they share an ACPI node.

I think as Andy pointed out though the first 4 patches in your
chain do loosely want we want. Previously, we used the name to
point to the actual pinctrl driver, your patches should let us
do that properly through the fwnode. So we can drop the pinctrl
swnode and just have the cs-gpios bit point at the actual fwnode
instead. I am trying to hack together a strawman but its failing
in a lightly odd way. Hopefully I can get that sorted fairly
soon and post, or I guess I could post a version earlier if you
wanted a look in the knowledge it still doesn't work?

Thanks,
Charles