Re: ASoC: cs42l43: SDCA reattach timeout on Dell XPS 14 Panther Lake; chip stuck across distros and kernels; worked initially; still working at hardware level

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Fri, May 08, 2026 at 05:45:19PM +0200, Tobias Bachmann wrote:
> On Fri, May 08, 2026 at 5:21:44PM CEST, Charles Keepax wrote:
> > On Fri, May 08, 2026 at 04:16:19PM +0100, Charles Keepax wrote:
> > > On Fri, May 08, 2026 at 04:56:03PM +0200, Tobias Bachmann wrote:
> > > > On Fri, May 08, 2026 at 10:41:10AM CEST, Charles Keepax wrote:
> > Although I am little worried more might be required looking
> > more closely. But let me know if you can test how it gets on
> > otherwise I will add it to my list to poke. I think last time I
> > tested that it was for a device that didn't also have a bunch of
> > SDCA stuff and some of that runs through a different path so
> > little nervous that might need a gate too.
> 
> Fortunately not. Tested on 7.1.0-rc2 and the speakers work fine. Lovely 
> stuff :)

Awesome sauce. Always nice when things go slightly better than
expected.

> This is probably a very unique solution to a unique problem. But I'd be 
> happy to test patches etc if you can use this information to foolproof 
> the architecture, which might help others.

Thanks, that is very generous of you. Full disclosure, most of
this SDCA stuff is still fairly new to the kernel so the basics
are keeping me/us pretty busy at the moment. Unlikely I am
going to get time to look at this in a lot of detail in the short
term. But it would be nice if we can do something here in the
future.

I think the biggest hurdle really is that a lot of this soundcard
stuff is decided before the devices themselves actually bind to
drivers. So it's easy to make it conditional off the contents of
the ACPI but hard to make it conditional off the dynamic state
of the system.

Thanks,
Charles