Re: [PATCH] spi: cs42l43: Workaround for wrong speaker ID on Dell XPS 13 DX13260

[Mark Brown]

On Sat, Sep 19, 2026 at 02:47:30PM +0100, Richard Fitzgerald wrote:
> Create an acpi_gpio_mapping so that speaker ID GPIOs can be read directly
> from the ACPI GpioIo() instead of relying on the spk-id-gpios property to
> have the correct number of pins. Change the reading loop to read each pin
> one at a time until it reaches a pin index that doesn't exist.

...

> Instead of quirking this specific system, the code can be rewritten so
> that it will always use the direct GpioIo() mapping. This works on all
> ACPI systems, so avoids having to keep adding quirks for other systems
> that have the same ACPI error.

Is there an overlap with cs35l56_try_get_broken_sdca_spkid_gpio() here?
Didn't check thoroughly, and if they are doing the same thing it's
probably reasonable to factor out incrementally.

> +       struct cs42l43_spk_id_gpio_mapping *mapping __free(kfree) = kzalloc_obj(*mapping,

kzalloc_obj() needs slab.h (which will be implicitly included anyway but
still).

> +static int cs42l43_get_speaker_id_gpios(struct cs42l43_spi *priv, int *result)
> +{
> +	struct fwnode_handle *gpio_fwnode = dev_fwnode(priv->dev);
> +	struct cs42l43_spk_id_gpio_mapping *mapping = NULL;
> +	struct gpio_desc *desc;
> +	u32 spkid = 0;
> +	int i, ret = 0;
> +
> +	if (is_acpi_node(gpio_fwnode)) {
> +		mapping = cs42l43_add_speaker_id_gpio_mapping(priv);
> +		if (IS_ERR(mapping)) {
> +			ret = PTR_ERR(mapping);
> +			if (ret == -ENOENT)
> +				return 0;
> +
> +			return ret;
> +		}

Could we see an -EBUSY if there's something else using another GPIO from
the same provider?  I'm a bit fuzzy on the ACPI mappings so possibly
that can't happen.

Attachment: signature.asc
Description: PGP signature