### System details

HP EliteBook 8 G1i 14" (DMI board 8D8A, SKU D75TQET#ABE, BIOS X91 01.05.02), Intel Core Ultra 5 238V, Arc 130V/140V, Realtek ALC245 + 2x Cirrus CS35L54 on SPI, Omarchy 4.0.4-1, linux-omarchy 7.2.5-3

### What's wrong?

## Symptom

Internal speakers produce no sound. Headphones, Bluetooth audio and HDMI work. Windows on the same machine plays through the speakers, so the hardware is fine.

The same model is reported elsewhere, which may help anyone searching: [Ubuntu #2131138](https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2131138), [Fedora discussion](https://discussion.fedoraproject.org/t/audio-speakers-not-working-on-hp-elitebook-8-g1i-intel-lunar-lake-alc245-cs35l56/180647).

## Root cause

Two Cirrus CS35L54 amplifiers (ACPI HID `CSC3554`, driven by `cs35l56-hda`) sit on the Intel LPSS SPI controller `8086:a827`, at chip selects 0 and 1. The DSDT describes both devices (`SpiSerialBusV2` with `DeviceSelection` 0x0000 and 0x0001), and `GSPK._CRS` includes a `GpioIo` for the second amp's chip-select line. But the SPI controller's `_DSD` lists only one chip select:

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

The controller's capability register also reports a single native chip select (`caps[0xfc] = 0x220`, CS_EN = 0x1), so the SPI core rejects CS1. `serial-multi-instantiate` then unregisters **both** devices, so neither amplifier exists and the codec has no speaker path. A second issue sits underneath: with a GPIO chip select, the LPSS controller gates its own clock unless a native chip select is asserted, so providing the GPIO alone is not enough.

## Evidence

Before (stock kernel; first boot of this install):

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

`/sys/bus/spi/devices/` then contains only the flash chip, and no `cs35l54` device exists.

That log is from Arch's `linux 7.1.9`. I have not booted `linux-omarchy 7.2.5` without the fix, but its `spi-pxa2xx-core` has the same `srcversion` as the stock Arch module, and its `serial-multi-instantiate` contains no chip-select handling, so it is in the same state.

After (cold boot on `linux-omarchy 7.2.5-3` with the upstream fix below):

```
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: DSP1: cirrus/cs35l54-b0-dsp1-misc-103c8d8f-amp1.bin (v1): v19.11.11
cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: DSP1: cirrus/cs35l54-b0-dsp1-misc-103c8d8f-amp2.bin (v1): v19.11.11
cs35l56-hda spi1-CSC3554:00-cs35l54-hda.0: Calibration applied
cs35l56-hda spi1-CSC3554:00-cs35l54-hda.1: Calibration applied
```

Both amplifiers bind to the codec and the speakers play in stereo.

## Upstream status

- Fix under review: [[PATCH v3 0/3] Fix CS35L56 amplifier on Intel LPSS SPI with broken ACPI cs-gpios](https://lore.kernel.org/all/[email protected]/) by Khalil. It is not in 7.2.5 or 7.3-rc3.
  - 1/3 `spi: Preserve preset cs_gpiod in __spi_add_device()`
  - 2/3 `platform/x86: serial-multi-instantiate:` DMI-gated quirk for board `8D8A` that installs the CS1 GPIO from `GpioIo[0]`
  - 3/3 `spi: pxa2xx:` keeps the clock running for GPIO chip selects
- Cirrus [noted](https://lore.kernel.org/all/[email protected]/) that HP has a BIOS with `cs-gpios` fixed, available on request.
- My test report on the thread: [link](https://lore.kernel.org/all/[email protected]/)

## What I tested, and what I didn't

- Tested: v3 **2/3 and 3/3**, built as DKMS modules against `linux-omarchy 7.2.5-3` headers. `serial-multi-instantiate.c` was taken from linux-omarchy's own tree (v7.2.5 plus `0510-sound-updates.patch`, which adds AW88399), with 2/3 on top. Loaded at runtime and from a cold boot.
- Not tested: a `linux-omarchy` package build with the patches in the PKGBUILD.
- Not applied: **1/3**, since `CONFIG_SPI=y`. On this path 2/3 installs the descriptor in `ctlr->cs_gpiods` and never presets the device's `cs_gpiod`, so 1/3 doesn't change behaviour here.
- All three v3 patches apply to v7.2.5 plus linux-omarchy's `0510-sound-updates.patch` with `patch -Np1 --fuzz=0`, which is the strictness the PKGBUILD uses.

## Possible fix in Omarchy

Carry the v3 patches in `pkgbuilds/linux-omarchy` in omarchy-pkgs, next to the existing single-laptop audio fixes (`0513`, `0516`, `0517`), until the series is merged upstream or HP's BIOS update ships. Two reasons to prefer a kernel patch over a DKMS package:

- 2/3 is DMI-gated to board `8D8A`, so no other machine's behaviour changes.
- `0510-sound-updates.patch` already modifies `serial-multi-instantiate.c`. A DKMS package replacing that module would silently remove the AW88399 entry, while a patch applies on top of it.

Removal: drop the patches once linux-omarchy's base includes the upstream commits, or once a BIOS update adds the second `cs-gpios` entry. The latter can be checked in the decompiled DSDT (`Package (0x02)` instead of `Package (0x01)`).

I'm happy to open that PR, test further revisions of the series on this machine, or test HP's BIOS when it becomes available.

## omarchy-debug

Full `omarchy-debug` output available on request, the relevant kernel log lines are quoted above.