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

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

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:
> > Additionally, there arn't that many SDCA vendor drivers at the
> > moment, a handful of Realtek ones and a TI one. If we wanted
> > to standardise I would suggest standardising on the better
> > solution, which to my mind is clearly this approach.
> 
> I am not against having a single mechanism, and that change
> would be relatively minimal.
> 
> 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.

> >> Note that things will be interesting when we use the new
> >> ACPI aggregation information to create the card, we're missing
> >> a means to re-trigger deferred probe checks as devices become
> >> functional. I had a patch on this a couple of years ago, look
> >> for "driver core: export driver_deferred_probe_trigger()",
> >> we probably need to revisit the entire scheme...
> > 
> > Apologies if I am misunderstanding but is this not another example
> > of the advantages of probing when the device enumerates? If I
> > understand correctly the problem those patches are solving is
> > resources that become available outside of a probe break deferred
> > probe. By tying the probe of the auxiliaries to the enumeration
> > of the device, we ensure that link between probe and resource
> > availability. I think the point Greg is making in that thread
> > is that the kernel expects resources are available once probed,
> > so if one is going to break that assumption it should really
> > be handled exclusively in the driver that does that. But the
> > simplest solution to my mind is just to not break that assumption
> > then everything works as expected.
> 
> 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?

> 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.

> Assuming a perfect behavior where all resources are available
> at probe time is naive IMHO. In the specific case of the
> machine driver probed with ACPI information that isn't tied
> to the bus status, it's a guaranteed fail.

Well I do love a good bit of being naive until it bites me :-)
Ultimately the machine driver has to call snd_soc_register_card
which can probe defer if the card components aren't ready. What
parts cause the issue here?

Thanks,
Charles