[PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Khalil]

v3 of the patch series fixing dual CS35L56 amplifiers on HP laptops
with Intel Lunar Lake and broken ACPI cs-gpios.

Changes since v2:
- Rebased onto broonie/spi for-next (commit b00c00f7dc)
- No code changes

Changes since RFC v1 (addressing feedback from Richard Fitzgerald):
- Added DMI quirk table: GPIO CS fixup is now only applied on known
  affected platforms (HP EliteBook 8 G1i, board 8D8A), not generically
  for all devices with CS > 0.
- Fixed chip select range check: only chip selects outside the
  controller's num_chipselect range are fixed up. A NULL cs_gpiods[cs]
  within range means "native chip select", not broken.
- Removed ASUS reference (GU605C was fixed by BIOS update).
- Added Patch 1/3 (spi core): __spi_add_device() now preserves preset
  cs_gpiod on the device instead of unconditionally overwriting from
  ctlr->cs_gpiods. Suggested by Richard Fitzgerald.
- Patch 2/3 (serial-multi-instantiate): Extracted GPIO fixup into a
  dedicated helper function with DMI-based quirk table.
- Patch 3/3 (spi-pxa2xx): Handles clock gating on Intel LPSS
  controllers when GPIO chip select is active.

Tested on HP EliteBook 8 G1i 16 inch (Intel Core Ultra 7 258V,
Lunar Lake-M) with 2x CS35L56 Rev B0. Both amplifiers probe
successfully, load calibration and tuning, and produce audio.

Related bug reports:
- https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2131138
- https://bugzilla.kernel.org/show_bug.cgi?id=221064
- https://github.com/thesofproject/linux/issues/5621

Khalil (3):
  spi: Preserve preset cs_gpiod in __spi_add_device()
  platform/x86: serial-multi-instantiate: Fix SPI chip select on
    platforms with incomplete ACPI cs-gpios
  spi: pxa2xx: Handle clock gating for GPIO chip select devices

 .../platform/x86/serial-multi-instantiate.c   | 168 ++++++++++++++++++
 drivers/spi/spi-pxa2xx.c                      |  45 ++++-
 drivers/spi/spi.c                             |   3 +-
 3 files changed, 211 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v3 1/3] spi: Preserve preset cs_gpiod in __spi_add_device()

[Khalil]

__spi_add_device() unconditionally overwrites spi->cs_gpiod[] from
ctlr->cs_gpiods[cs], even if the caller has already set a GPIO
descriptor on the device. This prevents drivers like
serial-multi-instantiate from pre-configuring a GPIO chip select
acquired from ACPI before adding the device.

Skip the overwrite when the device already has a cs_gpiod set for
the given index, allowing callers to preset GPIO chip selects that
aren't described in the controller's cs-gpios property.

This is useful on platforms where the ACPI _DSD cs-gpios property
on the SPI controller is incomplete, but the peripheral's ACPI node
does contain the correct GpioIo resource for its chip select.

Suggested-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Khalil <khalilst@gmail.com>
---
 drivers/spi/spi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 07c572e1df..fbfb9a1aa2 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -924,7 +924,8 @@ static int __spi_add_device(struct spi_device *spi, struct spi_device *parent)
 	if (ctlr->cs_gpiods) {
 		for (idx = 0; idx < spi->num_chipselect; idx++) {
 			cs = spi_get_chipselect(spi, idx);
-			spi_set_csgpiod(spi, idx, ctlr->cs_gpiods[cs]);
+			if (!spi_get_csgpiod(spi, idx))
+				spi_set_csgpiod(spi, idx, ctlr->cs_gpiods[cs]);
 		}
 	}
 
-- 
2.43.0

[PATCH v3 2/3] platform/x86: serial-multi-instantiate: Fix SPI chip select on platforms with incomplete ACPI cs-gpios

[Khalil]

Some HP laptops with Intel Lunar Lake and dual Cirrus Logic CS35L56
amplifiers over SPI have an incomplete cs-gpios property in the SPI
controller's _DSD - it only declares the first chip select. The
remaining chip select GPIOs are defined as GpioIo resources in the
peripheral's ACPI node but are not referenced by the controller.

This causes the SPI framework to reject devices whose chip select
exceeds num_chipselect with -EINVAL, preventing the second amplifier
from probing.

Fix this on known affected platforms by:

1. Adding a DMI quirk table to identify affected systems
2. For devices with chip selects outside the controller's range,
   acquiring the GPIO from the peripheral's ACPI GpioIo resource
3. Extending num_chipselect and reallocating the controller's
   cs_gpiods array to install the GPIO descriptor
4. Setting SPI_CONTROLLER_GPIO_SS so the framework calls both
   the GPIO toggle and controller->set_cs (needed for clock
   gating on Intel LPSS controllers)

Only chip selects beyond the controller's num_chipselect are fixed up.
Chip selects within range with a NULL cs_gpiods entry are left alone,
as NULL means "native chip select" which is intentional.

Tested on HP EliteBook 8 G1i 16 inch (board 8D8A) with 2x CS35L56
Rev B0 amplifiers. Both amplifiers probe and produce audio.

Signed-off-by: Khalil <khalilst@gmail.com>
---
 .../platform/x86/serial-multi-instantiate.c   | 168 ++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/drivers/platform/x86/serial-multi-instantiate.c b/drivers/platform/x86/serial-multi-instantiate.c
index 1a369334f9..0d30bd0a7b 100644
--- a/drivers/platform/x86/serial-multi-instantiate.c
+++ b/drivers/platform/x86/serial-multi-instantiate.c
@@ -8,6 +8,10 @@
 
 #include <linux/acpi.h>
 #include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/dmi.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/machine.h>
 #include <linux/i2c.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
@@ -46,6 +50,53 @@ struct smi {
 	int spi_num;
 	struct i2c_client **i2c_devs;
 	struct spi_device **spi_devs;
+	struct gpio_desc *cs_gpio;
+};
+
+/*
+ * Quirk data for platforms with broken ACPI SPI chip select descriptions.
+ * cs_gpio_idx: index of the GpioIo resource in the ACPI _CRS that provides
+ *              the chip select GPIO for devices missing a proper cs-gpios
+ *              entry on the SPI controller.
+ */
+struct smi_cs_gpio_quirk {
+	int cs_gpio_idx;
+};
+
+static const struct smi_cs_gpio_quirk hp_elitebook_8g1i_quirk = {
+	.cs_gpio_idx = 0,
+};
+
+/*
+ * DMI table of platforms with broken SPI chip select ACPI descriptions.
+ *
+ * These systems have multiple SPI peripherals (e.g., dual CS35L56
+ * amplifiers) but the SPI controller's _DSD cs-gpios property is
+ * incomplete - it only declares the first chip select. The remaining
+ * chip select GPIOs are defined as GpioIo resources in the peripheral's
+ * ACPI node but are not referenced by the controller.
+ */
+static const struct dmi_system_id smi_cs_gpio_dmi_table[] = {
+	{
+		.ident = "HP EliteBook 8 G1i 16 inch",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_MATCH(DMI_BOARD_NAME, "8D8A"),
+		},
+		.driver_data = (void *)&hp_elitebook_8g1i_quirk,
+	},
+	{ }
+};
+
+/*
+ * ACPI GPIO mapping for the chip select GpioIo resource.
+ * Maps "cs-gpios" to the GpioIo resource at index 0 of the ACPI _CRS.
+ */
+static const struct acpi_gpio_params smi_cs_gpio_params = { 0, 0, false };
+
+static const struct acpi_gpio_mapping smi_cs_gpio_mapping[] = {
+	{ "cs-gpios", &smi_cs_gpio_params, 1 },
+	{ }
 };
 
 static int smi_get_irq(struct platform_device *pdev, struct acpi_device *adev,
@@ -99,6 +150,101 @@ static void smi_devs_unregister(struct smi *smi)
 	}
 }
 
+/*
+ * smi_spi_setup_cs_gpio - Fix up chip select for a device on a platform
+ * with broken ACPI cs-gpios description.
+ *
+ * On affected platforms, the SPI controller's cs-gpios property is incomplete,
+ * so the framework has no GPIO descriptor for some chip selects. This causes
+ * __spi_add_device() to reject the device with -EINVAL (cs >= num_chipselect).
+ *
+ * This function:
+ * 1. Extends num_chipselect if the device's CS is out of range
+ * 2. Reallocates cs_gpiods to match, preventing out-of-bounds access
+ *    in __spi_add_device()
+ * 3. Installs the GPIO from the peripheral's ACPI node into the
+ *    controller's cs_gpiods array so __spi_add_device() propagates
+ *    it to the device
+ * 4. Sets SPI_CONTROLLER_GPIO_SS so the framework calls both the GPIO
+ *    toggle and controller->set_cs (needed for clock gating on Intel
+ *    LPSS controllers)
+ */
+static int smi_spi_setup_cs_gpio(struct device *dev,
+				 struct spi_device *spi_dev,
+				 struct smi *smi,
+				 const struct smi_cs_gpio_quirk *quirk)
+{
+	struct spi_controller *ctlr = spi_dev->controller;
+	struct gpio_desc **new_gpiods;
+	u16 cs = spi_get_chipselect(spi_dev, 0);
+
+	/*
+	 * Only fix up chip selects that the controller doesn't know about.
+	 * A NULL cs_gpiods[cs] within the controller's num_chipselect range
+	 * means "native chip select" - that's intentional, not broken.
+	 * The broken case is when cs >= num_chipselect, meaning the ACPI
+	 * cs-gpios property on the controller was incomplete.
+	 */
+	if (cs < ctlr->num_chipselect)
+		return 0;
+
+	/* Extend num_chipselect to cover this device */
+	dev_info(dev, "Extending num_chipselect from %u to %u for CS%u\n",
+		 ctlr->num_chipselect, cs + 1, cs);
+	ctlr->num_chipselect = cs + 1;
+
+	/* Acquire the CS GPIO from the ACPI GpioIo resource if not yet done */
+	if (!smi->cs_gpio) {
+		int ret;
+
+		ret = devm_acpi_dev_add_driver_gpios(dev, smi_cs_gpio_mapping);
+		if (ret) {
+			dev_warn(dev, "Failed to add CS GPIO mapping: %d\n", ret);
+			return ret;
+		}
+
+		smi->cs_gpio = devm_gpiod_get(dev, "cs", GPIOD_OUT_HIGH);
+		if (IS_ERR(smi->cs_gpio)) {
+			dev_warn(dev, "Failed to get CS GPIO: %ld\n",
+				 PTR_ERR(smi->cs_gpio));
+			smi->cs_gpio = NULL;
+			return -ENOENT;
+		}
+		dev_info(dev, "Acquired CS GPIO for CS%u from ACPI GpioIo[%d]\n",
+			 cs, quirk->cs_gpio_idx);
+	}
+
+	/*
+	 * Reallocate the controller's cs_gpiods array to accommodate the
+	 * new num_chipselect, and install the GPIO descriptor. This is
+	 * necessary because __spi_add_device() unconditionally reads
+	 * ctlr->cs_gpiods[cs] to set the device's cs_gpiod.
+	 */
+	new_gpiods = devm_kcalloc(&ctlr->dev, ctlr->num_chipselect,
+				  sizeof(*new_gpiods), GFP_KERNEL);
+	if (!new_gpiods)
+		return -ENOMEM;
+
+	if (ctlr->cs_gpiods) {
+		unsigned int i;
+
+		for (i = 0; i < cs; i++)
+			new_gpiods[i] = ctlr->cs_gpiods[i];
+	}
+	new_gpiods[cs] = smi->cs_gpio;
+	ctlr->cs_gpiods = new_gpiods;
+
+	/*
+	 * SPI_CONTROLLER_GPIO_SS ensures the framework calls both the
+	 * GPIO CS toggle and controller->set_cs(). This is required on
+	 * Intel LPSS controllers where set_cs handles clock gating.
+	 */
+	ctlr->flags |= SPI_CONTROLLER_GPIO_SS;
+
+	dev_info(dev, "Installed GPIO CS on controller for CS%u\n", cs);
+	return 0;
+}
+
 /**
  * smi_spi_probe - Instantiate multiple SPI devices from inst array
  * @pdev:	Platform device
@@ -112,10 +258,19 @@ static int smi_spi_probe(struct platform_device *pdev, struct smi *smi,
 {
 	struct device *dev = &pdev->dev;
 	struct acpi_device *adev = ACPI_COMPANION(dev);
+	const struct dmi_system_id *dmi_id;
+	const struct smi_cs_gpio_quirk *quirk = NULL;
 	struct spi_controller *ctlr;
 	struct spi_device *spi_dev;
 	char name[50];
 	int i, ret, count;
+	u16 cs;
+
+	dmi_id = dmi_first_match(smi_cs_gpio_dmi_table);
+	if (dmi_id) {
+		quirk = dmi_id->driver_data;
+		dev_info(dev, "Applying CS GPIO quirk for %s\n", dmi_id->ident);
+	}
 
 	ret = acpi_spi_count_resources(adev);
 	if (ret < 0)
@@ -139,6 +294,19 @@ static int smi_spi_probe(struct platform_device *pdev, struct smi *smi,
 		}
 
 		ctlr = spi_dev->controller;
+		cs = spi_get_chipselect(spi_dev, 0);
+
+		/*
+		 * On quirked platforms, fix up the chip select GPIO for
+		 * devices that would otherwise fail due to incomplete
+		 * ACPI cs-gpios on the SPI controller.
+		 */
+		if (quirk) {
+			ret = smi_spi_setup_cs_gpio(dev, spi_dev, smi, quirk);
+			if (ret)
+				dev_dbg(dev, "CS GPIO setup returned %d for CS%u\n",
+					ret, cs);
+		}
 
 		strscpy(spi_dev->modalias, inst_array[i].type);
 
-- 
2.43.0

Re: [PATCH v3 2/3] platform/x86: serial-multi-instantiate: Fix SPI chip select on platforms with incomplete ACPI cs-gpios

[Juan Jimenez Carrero]

On Tue, 1 Sep 2026 21:26:24 +0200, Khalil wrote:
> Some HP laptops with Intel Lunar Lake and dual Cirrus Logic CS35L56

Tested on an HP EliteBook 8 G1i 14 inch (DMI board 8D8A) with 2x
CS35L54, together with 3/3 and without 1/3. Details in my reply to the
cover letter.

Tested-by: Juan Jimenez Carrero <juan@jimenezcarrero.com>

[PATCH v3 3/3] spi: pxa2xx: Handle clock gating for GPIO chip select devices

[Khalil]

On Intel LPSS SPI controllers (Cannon Lake and later) with dynamic
clock gating (cs_clk_stays_gated=true), the SPI clock is gated when
no native chip select is asserted. When using a GPIO chip select
(via SPI_CONTROLLER_GPIO_SS), the SPI framework toggles the GPIO
and also calls the controller's set_cs callback.

Handle this in the pxa2xx cs_assert/cs_deassert functions: when the
device uses a GPIO chip select on an LPSS controller, assert native
CS in the control register to enable the clock, and force the clock
gate on. On deassert, restore both.

This is needed on platforms where serial-multi-instantiate installs
a GPIO chip select from the peripheral's ACPI GpioIo resource to
work around an incomplete cs-gpios property on the SPI controller.

Signed-off-by: Khalil <khalilst@gmail.com>
---
 drivers/spi/spi-pxa2xx.c | 45 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6291d7c2e0..fe57620630 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -419,20 +419,43 @@ static void cs_assert(struct spi_device *spi)
 {
 	struct driver_data *drv_data =
 		spi_controller_get_devdata(spi->controller);
+	const struct lpss_config *config;
 
 	if (drv_data->ssp_type == CE4100_SSP) {
 		pxa2xx_spi_write(drv_data, SSSR, spi_get_chipselect(spi, 0));
 		return;
 	}
 
-	if (is_lpss_ssp(drv_data))
-		lpss_ssp_cs_control(spi, true);
+	if (is_lpss_ssp(drv_data)) {
+		config = lpss_get_config(drv_data);
+
+		if (spi_is_csgpiod(spi)) {
+			/*
+			 * GPIO handles the actual chip select to the device.
+			 * On LPSS controllers with dynamic clock gating, the
+			 * SPI clock won't run unless the native CS state says
+			 * "asserted" in the CS control register. Assert native
+			 * CS in the register to enable the clock, and force
+			 * the clock gate on.
+			 */
+			lpss_ssp_cs_control(spi, true);
+			if (config->cs_clk_stays_gated) {
+				__lpss_ssp_update_priv(drv_data,
+					LPSS_PRIV_CLOCK_GATE,
+					LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK,
+					LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON);
+			}
+		} else {
+			lpss_ssp_cs_control(spi, true);
+		}
+	}
 }
 
 static void cs_deassert(struct spi_device *spi)
 {
 	struct driver_data *drv_data =
 		spi_controller_get_devdata(spi->controller);
+	const struct lpss_config *config;
 	unsigned long timeout;
 
 	if (drv_data->ssp_type == CE4100_SSP)
@@ -444,8 +467,22 @@ static void cs_deassert(struct spi_device *spi)
 	       !time_after(jiffies, timeout))
 		cpu_relax();
 
-	if (is_lpss_ssp(drv_data))
-		lpss_ssp_cs_control(spi, false);
+	if (is_lpss_ssp(drv_data)) {
+		config = lpss_get_config(drv_data);
+
+		if (spi_is_csgpiod(spi)) {
+			/* Deassert native CS and restore clock gating */
+			lpss_ssp_cs_control(spi, false);
+			if (config->cs_clk_stays_gated) {
+				__lpss_ssp_update_priv(drv_data,
+					LPSS_PRIV_CLOCK_GATE,
+					LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK,
+					LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_OFF);
+			}
+		} else {
+			lpss_ssp_cs_control(spi, false);
+		}
+	}
 }
 
 static void pxa2xx_spi_set_cs(struct spi_device *spi, bool level)
-- 
2.43.0

Re: [PATCH v3 3/3] spi: pxa2xx: Handle clock gating for GPIO chip select devices

[Juan Jimenez Carrero]

On Tue, 1 Sep 2026 21:26:25 +0200, Khalil wrote:
> On Intel LPSS SPI controllers (Cannon Lake and later) with dynamic

Tested on an HP EliteBook 8 G1i 14 inch (DMI board 8D8A) with 2x
CS35L54, together with 2/3 and without 1/3. Details in my reply to the
cover letter.

Tested-by: Juan Jimenez Carrero <juan@jimenezcarrero.com>

Re: [PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Richard Fitzgerald]

On 01/09/2026 8:26 pm, Khalil wrote:
> v3 of the patch series fixing dual CS35L56 amplifiers on HP laptops
> with Intel Lunar Lake and broken ACPI cs-gpios.

HP told us they have a BIOS with the cs-gpios fixed, and they can make
that available early if you post a support request for it.

Can you test that new BIOS? It would avoid the messy SPI workarounds.

Re: [PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Juan Jimenez Carrero]

On 03/09/2026 10:21 am, Richard Fitzgerald wrote:
> HP told us they have a BIOS with the cs-gpios fixed, and they can make
> that available early if you post a support request for it.
>
> Can you test that new BIOS? It would avoid the messy SPI workarounds.

I have affected hardware. I could raise a support request and
test that BIOS, if a second machine doing so is useful:

  HP EliteBook 8 G1i 14 inch, SKU D75TQET#ABE
  BIOS X91 Ver. 01.05.02, 05/03/2026
  Intel Core Ultra 5 238V (Lunar Lake-M)
  SPI controller 8086:a827 (LPSS_CNL_SSP via tgl_spi_info)
  Realtek ALC245, SSID 103c:8d8f
  2x Cirrus Logic CS35L54 Rev B0 OTP4 fw:3.4.4, ACPI HID CSC3554

This is the CS35L54 variant rather than CS35L56, so it may be a useful
extra data point either way. The DSDT defect is identical:

  Scope (_SB.PC00.SPI0)
  {
      Name (_DSD, Package (0x02)
      {
          ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package (0x01)
          {
              Package (0x02) { "cs-gpios", Package (0x01) { Zero } }
          }
      })
  }

while GSPK._CRS declares SpiSerialBusV2 with DeviceSelection 0x0000 and
0x0001, plus a GpioIo for the CS1 line.

One difference from the cover letter's description: on this machine
neither amplifier is instantiated on a stock kernel, not only the
second. spi_add_device() rejects CS1 and serial-multi-instantiate then
unwinds the whole set:

  pxa2xx-spi pxa2xx-spi.3: cs1 >= max 1
  spi_master spi1: error -EINVAL: failed to add SPI device CSC3554:00 from ACPI
  Serial bus multi instantiate pseudo device driver CSC3554:00: probe with
    driver Serial bus multi instantiate pseudo device driver failed with error -22

For reference, the LPSS capability register on this board reads
caps[0xfc] = 0x220, so CS_EN (bits 12:9) is 0x1 and ffz() yields
num_chipselect = 1, while ACPI describes two chip selects. The TYPE
field of the same register reads 2 (LPSS_DEV_SPI), so the read itself
is valid. (Obtained with a dev_info() added to spi-pxa2xx.c; the
register is not reachable from userspace with CONFIG_IO_STRICT_DEVMEM)

I have run the earlier two-patch version from your gist
(serial-multi-instantiate + spi-pxa2xx), built out-of-tree as a DKMS
module against 7.1.9. With those applied both amplifiers probe, load
firmware and calibration, and bind to the codec. Internal speakers work
across a cold boot:

  serial-multi-instantiate CSC3554:00: Increasing num_chipselect from 1 to 2 for CS1
  serial-multi-instantiate CSC3554:00: Got CS GPIO for amp CS1
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.0: DSP system name: '103C8D8F', amp name: 'AMP1'
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: DSP system name: '103C8D8F', amp name: 'AMP2'
  snd_hda_codec_alc269 ehdaudio0D0: bound spi1-CSC3554:00-cs35l54-hda.0
  snd_hda_codec_alc269 ehdaudio0D0: bound spi1-CSC3554:00-cs35l54-hda.1
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.0: Calibration applied
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: Calibration applied

I have not tested v3, so I am deliberately not offering a Tested-by for
it. I can test v3, the new BIOS or both on this machine (whichever is
more useful).

Juan Jimenez Carrero

Re: [PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Juan Jimenez Carrero]

On Tue, 1 Sep 2026 21:26:22 +0200, Khalil wrote:
> v3 of the patch series fixing dual CS35L56 amplifiers on HP laptops

Following up on my earlier reply, where I had only run the earlier
gist version: I have now tested v3 on the same machine.

  HP EliteBook 8 G1i 14 inch, DMI board 8D8A, SKU D75TQET#ABE
  BIOS X91 Ver. 01.05.02
  2x Cirrus Logic CS35L54 Rev B0 OTP4 fw:3.4.4, ACPI HID CSC3554
  Kernel: linux-omarchy 7.2.5 (v7.2.5 plus the patch set of Omarchy,
  an Arch-based distribution)

What was tested: 2/3 and 3/3, built out of tree as modules against
that kernel's headers. The distribution kernel carries a sound
backport that also touches serial-multi-instantiate.c; 2/3 applies on
top of it with --fuzz=0.

1/3 was not applied, because CONFIG_SPI=y there. Looking at why the
result still worked: on this path 2/3 installs the descriptor in
ctlr->cs_gpiods and never presets spi->cs_gpiod, spi_alloc_device()
zero-allocates, and __spi_add_device() is the only place the device's
cs_gpiod is assigned. So the new check in 1/3 is always true here and
does not change behaviour on this platform. I may be missing a case
where 2/3 relies on it, but on this machine 2/3 + 3/3 alone were
sufficient.

Log from reloading the modules at runtime:

  Serial bus multi instantiate pseudo device driver CSC3554:00: Applying CS GPIO quirk for HP EliteBook 8 G1i 16 inch
  Serial bus multi instantiate pseudo device driver CSC3554:00: Extending num_chipselect from 1 to 2 for CS1
  Serial bus multi instantiate pseudo device driver CSC3554:00: Acquired CS GPIO for CS1 from ACPI GpioIo[0]
  Serial bus multi instantiate pseudo device driver CSC3554:00: Installed GPIO CS on controller for CS1
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.0: DSP system name: '103C8D8F', amp name: 'AMP1'
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: DSP system name: '103C8D8F', amp name: 'AMP2'
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.0: Calibration applied
  cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: Calibration applied

A cold boot shows the same quirk, GPIO, AMP1/AMP2 and calibration
lines. Both amplifiers bind to the codec and the internal speakers
play in stereo.

One small note on the quirk table: the entry's .ident is "HP EliteBook
8 G1i 16 inch", but this 14 inch model reports the same DMI board name
8D8A (and has CS35L54 rather than CS35L56 amplifiers), so it matches
too. Only the label is narrower than the match.

I'll send Tested-by on 2/3 and 3/3 individually, since 1/3 was not part
of what I ran. The offer to test HP's fixed BIOS still stands.

Juan Jimenez Carrero

Re: [PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Richard Fitzgerald]

On 16/9/26 22:23, Juan Jimenez Carrero wrote:
> On Tue, 1 Sep 2026 21:26:22 +0200, Khalil wrote:
>> v3 of the patch series fixing dual CS35L56 amplifiers on HP laptops
> 
> Following up on my earlier reply, where I had only run the earlier
> gist version: I have now tested v3 on the same machine.
> 
>    HP EliteBook 8 G1i 14 inch, DMI board 8D8A, SKU D75TQET#ABE
>    BIOS X91 Ver. 01.05.02
>    2x Cirrus Logic CS35L54 Rev B0 OTP4 fw:3.4.4, ACPI HID CSC3554
>    Kernel: linux-omarchy 7.2.5 (v7.2.5 plus the patch set of Omarchy,
>    an Arch-based distribution)

The latest BIOS (01.06.02) is reported to fix the problem:
https://bugzilla.kernel.org/show_bug.cgi?id=221064#c23

Re: [PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios

[Juan Jimenez Carrero]

On Thu, 17 Sep 2026 14:42:18 +0100, Richard Fitzgerald wrote:
> The latest BIOS (01.06.02) is reported to fix the problem:
> https://bugzilla.kernel.org/show_bug.cgi?id=221064#c23

Thanks, Richard. Confirmed on the same machine as my earlier report:

  HP EliteBook 8 G1i 14 inch, DMI board 8D8A, SKU D75TQET#ABE
  BIOS X91 Ver. 01.05.02 -> X91 Ver. 01.06.02 (dated 07/22/2026)

I dumped the ACPI tables before and after the update. The only change
in Scope (\_SB.PC00.SPI0) is the cs-gpios property:

   "cs-gpios",
  -Package (0x01)
  +Package (0x05)
   {
  +    Zero,
  +    GSPK,
  +    Zero,
  +    Zero,
       Zero
   }

CS0 stays on the native chip select and CS1 becomes GpioIo resource 0
of GSPK, which is the same GPIO that 2/3 installs. Device (GSPK) is
unchanged between the two versions.

On 01.06.02 with an unpatched kernel (7.2.5, no out-of-tree modules,
taint 0) both amplifiers probe, the calibration is applied and the
speakers play. The "cs1 >= max 1" error is gone.

With 2/3 and 3/3 still loaded on 01.06.02, the quirk matches the DMI
entry but returns early because cs < num_chipselect, so the series
does no harm on the fixed firmware. On 01.05.02 it is still needed,
and my earlier Tested-by stands for that case.

One small detail in case there is a v4: the DMI entry's .ident says
"HP EliteBook 8 G1i 16 inch", but board 8D8A is also the 14 inch model
I tested on.

Thanks,
Juan