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=MfuQSGPbt3x366j5c9Sg-mgu=TfmD6X25Dk5Rmu0JiiEw@mail.gmail.com>
Date: Wed, 19 Nov 2025 14:34:58 +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 2:27 PM Charles Keepax
<ckeepax@...nsource.cirrus.com> wrote:
>
> 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@...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
> > > 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.
>

Ah, I see now. That's indeed a fundamental problem that can't be
easily solved. Andy is right about the needed change but phew that'll
be a big one...

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

Yeah, I'd like that. I want to get it upstream and have interest in
getting it fixed ASAP.

For the record: I believe the logic behind this patch is the correct
approach. It uses the existing MFD infrastructure that's there for
exactly this reason. However without being able to have an arbitrary
number of firmware nodes attached to a device, that'll be impossible.

Just an idea: we could try to do the conversion gradually - by first
adding that list of fwnodes to struct device in parallel to the
current approach of having the secondary pointer and then go from
there step by step.

Bart