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

[Mark Brown]

On Fri, Sep 25, 2026 at 02:14:34PM +0100, Richard Fitzgerald wrote:
> On 20/9/26 16:14, Mark Brown wrote:

> > Could we see an -EBUSY if there's something else using another GPIO from
> > the same provider?

> I'm not sure what you mean by "another GPIO from the same provider".
> If you mean can the codec driver also try to read the same GPIOs:

I mean we're looping over all the GPIOs from the provider, what if
something else already requested one of the others?

> 1. No. It's read here in the SPI bus driver because on these systems the
> cs42l43 is the only device that appears in ACPI, so it's the only one
> that has access to the ACPI GpioIo(). And there's only one instance.

So this is all hyper specific to some specific systems?  I can't see
what in the code is limiting the workaround to those systems, but it's
possible that's in wider context than I looked at.

> The ACPI property takes precedence and overrides the mapping, but the
> specific case of the cs42l43 SPI driver we know that the node containing
> the defective _DSD property is always different from the node containing
> the GpioIo() definition.
> 
> On the Sashiko complaints:

If I care about Sashiko output I'll say something.  There's no harm in
looking at it and it's possible that some of the stuff I don't mention
is valid since the false positive rate is such that I can't generally be
bothered to figure out if something that's not immediately obviously
valid is actually valid.

Attachment: signature.asc
Description: PGP signature