linux-kernel - Re: [PATCH] spi: cs42l43: Use actual ACPI firmware node for chip selects

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: <CAHp75VcjhdBXps+VmPNNUucA4LQwiZnReDMbQVpxHROcVsMurw@mail.gmail.com>
Date: Wed, 19 Nov 2025 18:49:57 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc: broonie@...nel.org, brgl@...ev.pl, linus.walleij@...aro.org, 
	andy@...nel.org, p.zabel@...gutronix.de, linux-gpio@...r.kernel.org, 
	linux-spi@...r.kernel.org, bartosz.golaszewski@...aro.org, 
	linux-kernel@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH] spi: cs42l43: Use actual ACPI firmware node for chip selects

On Wed, Nov 19, 2025 at 6:40 PM Charles Keepax
<ckeepax@...nsource.cirrus.com> wrote:
>
> On some systems the cs42l43 has amplifiers attached to its SPI
> controller that are not properly defined in ACPI. Currently software
> nodes are added to support this case, however, the chip selects
> for these devices are specified using a bit of a hack. A software
> node is added with the same name as the pinctrl driver, as the look
> up was name based this caused the GPIO looks to return the pinctrl
> driver even though the swnode is not associated with the pinctrl
> driver. This was necessary as the swnodes did not support directly
> linking to real firmware nodes.
>
> Since commit e5d527be7e69 ("gpio: swnode: don't use the
> swnode's name as the key for GPIO lookup") changed the lookup to
> be fwnode based this hack will no longer find the pinctrl driver,
> resulting in the driver not probing. But other patches also add support
> for linking a swnode to a real fwnode node [1]. As such switch over to
> just passing the real fwnode for the pinctrl property to avoid any
> issues.

> [1] https://lore.kernel.org/linux-gpio/20251106-reset-gpios-swnodes-v6-0-69aa852de9e4@linaro.org/
>

This can be

Link: ... [1]

actually.

> Signed-off-by: Charles Keepax <ckeepax@...nsource.cirrus.com>
> ---
>
> Ok here is what I would propose to fix this one, IMPORTANT NOTE: this
> does depend on the first four patches of the linked chain which I don't
> think are merged yet. But I would argue if we are removing the name
> based look up, we should add support for fwnodes at the same time.

You mean it has functional dependency and not a compile-time one?

...

>  static const struct software_node_ref_args cs42l43_cs_refs[] = {
> -       SOFTWARE_NODE_REFERENCE(&cs42l43_gpiochip_swnode, 0, GPIO_ACTIVE_LOW),
> +       SOFTWARE_NODE_REFERENCE(NULL, 0, GPIO_ACTIVE_LOW),
>         SOFTWARE_NODE_REFERENCE(&swnode_gpio_undefined),
>  };

Since it's a placeholder, we don't need it at all. See below.

...

> +               args = devm_kmemdup(priv->dev, cs42l43_cs_refs, sizeof(cs42l43_cs_refs),
> +                                   GFP_KERNEL);
> +               if (!args)
> +                       return -ENOMEM;
> +

> +               args[0].fwnode = fwnode;

You can assign entries directly here as

  args = devm_kmalloc_array(...);
  ...
  args[0] = SOFTWARE_NODE_REFERENCE(...);
  args[1] = SOFTWARE_NODE_REFERENCE(&swnode_gpio_undefined),

-- 
With Best Regards,
Andy Shevchenko