linux-kernel - Re: [PATCH v7 4/9] 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: <aSSOo4q0sLDHqe1h@opensource.cirrus.com>
Date: Mon, 24 Nov 2025 16:58:11 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Danilo Krummrich <dakr@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        David Rhodes <david.rhodes@...rus.com>,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Mark Brown <broonie@...nel.org>,
        Maciej Strozek <mstrozek@...nsource.cirrus.com>,
        Andy Shevchenko <andy@...nel.org>,
        Bartosz Golaszewski <brgl@...nel.org>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-sound@...r.kernel.org, patches@...nsource.cirrus.com,
        linux-spi@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
        stable+noautosel@...nel.org
Subject: Re: [PATCH v7 4/9] spi: cs42l43: Use actual ACPI firmware node for
 chip selects

On Thu, Nov 20, 2025 at 02:23:59PM +0100, Bartosz Golaszewski wrote:
> From: Charles Keepax <ckeepax@...nsource.cirrus.com>
> 
> 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 hack. A software
> node is added with the same name as the pinctrl driver, as the
> look up was name based, this allowed the GPIO look up to return
> the pinctrl driver even though the swnode was not owned by it.
> 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. There is no pinctrl driver
> attached to the swnode itself. But other patches did add support
> for linking a swnode to a real fwnode node [1]. As such the hack
> is no longer needed, so switch over to just passing the real
> fwnode for the pinctrl property to avoid any issues.
> 
> Link: https://lore.kernel.org/linux-gpio/20251106-reset-gpios-swnodes-v6-0-69aa852de9e4@linaro.org/ [1]
> Fixes: 439fbc97502a ("spi: cs42l43: Add bridged cs35l56 amplifiers")
> Cc: stable+noautosel@...nel.org # Don't backport, previous approach works, fix relies on swnode changes

Just wanted to check what the thinking is on backports here. I
see we have marked this as do not backport. Which I think is
sensible the changes in the preceeding patches are a bit much for
a backport. However, the patch has caused the regression has gone
to a few stable branches (v6.17, v6.12):

commit e5d527be7e69 ("gpio: swnode: don't use the swnode's name as the key for GPIO lookup")

Are you guys ok if I send a revert for that patch to the stable
branches it has gone to? It doesn't actually fix any bugs on
those kernels, and we are starting to see issues coming in that I
think are related to this:

https://github.com/thesofproject/linux/issues/5599

Thanks,
Charles