Re: [PATCH 3/4] ASoC: SDCA: Add basic SDCA class driver

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

On Tue, Jan 06, 2026 at 06:10:06PM +0100, Pierre-Louis Bossart wrote:
> On 1/6/26 13:58, Charles Keepax wrote:
> > On Sat, Dec 20, 2025 at 12:04:47PM +0100, Pierre-Louis Bossart wrote:
> >> On 12/10/25 10:55, Charles Keepax wrote:
> >>> On Tue, Dec 09, 2025 at 12:47:06PM +0000, Pierre-Louis Bossart wrote:
> >> The only issue I have with it is whether one would deregister
> >> the child device on a soft reset or whenever the device
> >> loses sync? It'd be somewhat ugly to do so, but then again
> >> we have the issue that for the second enumeration we already
> >> have a probed child driver, which would bring us back to an
> >> async model really. The 'beauty' of the current model is
> >> that the probe does nothing really, everything happens at
> >> enumeration/sync loss. If we dynamically add/remove child
> >> devices it'll be 'fun' really quickly.
> > 
> > Yeah that is one of the questions I have pondered a few times.
> > Were I usually get to is separating out expected cases of
> > something dropping off the bus and unexpected cases. For say
> > suspend/resume it is quite likely the device will drop off the
> > bus and that is expected and probably shouldn't result in the
> > child drivers being removed, as it will as you say become 'fun'
> > very quickly. However, an unexpected drop off the bus during
> > normal operation is really a pretty fatal error. In many ways the
> > best thing to do is probably to remove the child drivers in this
> > case, since that will tear down the sound card, and allow
> > everything to be rebuilt. But these are far from fully formed
> > ideas, for the most part at the moment we just report things went
> > bad.
> 
> A device falling off the bus is not that rare in early
> bring-up or experimental platforms.  IIRC some devices will
> require a full reset after firmware download.  Not to mention
> the glitches that can be seen consistently after clock stop
> on some platforms.

So doing a reset after firmware download should be fine, I would
consider than an expected drop off.

> My take is that it's better to 'hide' some of the low-level
> detail and keep the card visible to apps, always.

I would agree here, it is better if the card stays present and
hides non-error states.

> That means the drivers need to deal with cases where accesses
> to devices might be delayed due to slow sync or sync loss. As
> long as everything recovers we are good to go.

Yeah that is a point we slightly disagree on, I really am not
a huge fan of auto-recovery stuff. Been involved in too many
situations where the auto-recovery recovers *most* of the time
and takes a 1/10 fail to a 1/10000 fail.

Taking this case, if the device loses sync during audio that
is gonna glitch the audio, which makes it a problem I will be
expected to fix. I would rather get a report the audio stopped
with a log up to that point, than get reports of audio glitches.

> >> That's precisely the problem, the model assumes something
> >> that is broken left and right in practice.
> >> Exhibit A is the PCI/HDaudio parts where we rely on an async
> >> probe due to the module handling.
> > 
> > I think I am perhaps not totally familiar with the issues on the
> > PCI/HDaudio side. What is the primary issue here?
> 
> The HDAudio side loads different modules, which can take a lot
> of time. For that reason, the driver probe returns immediately
> but most of the processing is done in a workqueue. This leads
> to two problems
> a) if the processing fails for some reason, we have no way
>    of signaling any error.
> b) if the card is created independently from the PCI driver,
>    e.g. with ACPI information, then we have no way of telling
>    that the resources needed by the card are available.

I mean sure it does make the boot look faster, but is it really
faster as the devices weren't actually ready when we told
user-space they were? And now we have to deal with the problems
outlined here, as well as what happens if user-space/another
driver tries to use the device whilst it is in this
not-quite-ready state. It feels like we sacrifice quite a lot
for appearing faster.

> >> You also have devices that require firmware download to be
> >> functional, or some sort of internal ramp-up needed.
> > 
> > Yeah these can be fairly annoying. But both of these can be
> > tackled with either handling the situation in probe, or if that
> > makes boot too slow, moving to a similar child driver approach.
> 
> Both options are not so good IMHO...

What is it you dislike about them? Just the slower boot, or
something more fundamental?

Thanks,
Charles