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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MdXNXQhE9zi=i0x0yGCi0fKQNU8_tn2_Uy24TAhxG7BRA@mail.gmail.com>
Date: Wed, 19 Nov 2025 14:07:55 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	David Rhodes <david.rhodes@...rus.com>, Richard Fitzgerald <rf@...nsource.cirrus.com>, 
	Lee Jones <lee@...nel.org>, Mark Brown <broonie@...nel.org>, 
	Philipp Zabel <p.zabel@...gutronix.de>, Linus Walleij <linus.walleij@...aro.org>, 
	Maciej Strozek <mstrozek@...nsource.cirrus.com>, Andy Shevchenko <andy@...nel.org>, 
	linux-sound@...r.kernel.org, patches@...nsource.cirrus.com, 
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH RFT/RFC] mfd: cs42l43: setup true links with software nodes

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

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