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=MfQTY7REt4Mty6mzv9Onwjv75LMU_RbJCM4LSgT74RHsw@mail.gmail.com>
Date: Wed, 19 Nov 2025 13:08:18 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.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 12:53 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> Okay, you got into fundamental problem of fwnode design it seems.
>

The problem here is not that we can have a single secondary firmware
node, it's that we can only have a single software node. But that may
not be a problem because the question here is: do we in this case
really need the software node assigned by the ACPI part of the MFD
core. I'd say no, see my other response for a proposed fix.

> (below is the summary related to that, but it may be not related here)
>
> If it's the case, there is no easy solution for it right now.
>
> And going ahead, please, don't even try hacks like recreating a copy
> of needed properties from the parent fwnode to get an independent child
> fwnode.
>

Are any of these properties needed/used? If so, then maybe we should
consider allowing the primary and secondary nodes to be software
nodes?

> The proper solution OTOH should be decoupling fwnode from struct device
> and making there a list of fwnodes.
>
>         struct fwnode_handle {
>                 struct list_head node;
>                 ...
>         }
>
>         struct device {
>                 // asumming dropped of_node and fw_node
>                 struct list_head nodes;
>         }
>
> This will require at first to make sure no code dereferencing fwnode
> (and of_node) from struct device. With that enormous task done, the
> rest is much easier to achieve as it will be just API's internals
> refactoring.
>

Yeah, let's talk realistic things that we can improve now and not a
task that will take years. :)

> With that done, we may stitch as many fwnodes as we want where the order in
> the list will define match priority.
>

FWIW we can already do it without changing the fwnode_handle
structure. The secondary fwnode also has the secondary pointer so it's
effectively a linked list already.

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

Bart