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 Thu, May 07, 2026 at 08:53:27PM +0200, Tobias Bachmann wrote:
> On Thur, May 07, 2026, 05:35:37PM CEST, Charles Keepax wrote:
> > Yeah I am afraid this looks like a hardware problem, enumerating on
> > the SoundWire bus is pretty much only dependant on power rails.
> >
> > As you say there is a tiny hope the device has got into a weird state
> > but isn't reset on a reboot. However, given it looks from the log like
> > the amps were reset:
> > 
> > [   14.603448] cs35l56 sdw:0:2:01fa:3557:01:2: Cirrus Logic CS35L57
> > Rev B2 OTP1 fw:4.2.1 (patched=0)
> > 
> > That patched=0 means the firmware has been wiped and that only happens
> > on a reset and as far as I know the resets are tied together on this
> > model. The very very long shot would be to let the battery run down
> > and leave the device for a bit to try and super make sure the power
> > rails went down which would also fully reset the device. But it is
> > definitely a long shot.
> 
> I figured as much. I can take this up with Dell as a hardware issue, but
> before I do, I wanted to ask about something architecturally:
> 
> Windows (or the Cirrus driver?) apparently treats the speakers and the
> headphone jack as independent functional paths and can drive the
> speakers fine despite the jack being non-responsive. The Linux driver
> currently appears to bring up the sound hardware  as a whole, which 
> means the headphone subfunction failing to reattach kills the entire 
> card initialization, including the still-healthy amps.
> 
> Would it be reasonable to consider a degraded-mode behavior where the
> driver proceeds with partial initialization when one subfunction fails,
> as long as others remain reachable? My particular case is likely
> hardware degradation, but I imagine similar failures could occur from
> manufacturing defects, physical damage to the jack contact, or other
> single-subfunction faults that don't render the whole chip unusable. The
> current behavior makes such a laptop entirely silent in Linux while
> still usable in Windows, which seems like a worse outcome than
> necessary.
> 
> I realize this might be a significant change and there may be good
> reasons it's not feasible with the current architecture. Happy to test
> any patches.

Yeah mostly this is an artifact of how the two operating systems
have structure the audio subsystem. Windows has more of a
collective of drivers, Linux is slightly more monolithic.
Changing things at that level is a pretty serious endeavour. I
would agree in this case the windows behaviour is slightly nicer
but its non-trivial for such a niche case.

However, that said we (and others) have been trying to get the
audio system to load more dynamically, the intention here has
been to not require as much work to support new models. But I
guess one could perhaps "abuse" this for your situation. The
current code creates the soundcard based mostly on what is
present in the ACPI. So if one removed the codec from the ACPI I
believe the machine driver would create a soundcard with just
speakers in theory. The simplest way to do this would probably be
to add an SSDT that adds a _STA method to the codec returning
zero, this would tell the kernel that the device is disabled and
it would ignore it.

Thanks,
Charles