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

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

On Tue, Dec 09, 2025 at 12:47:06PM +0000, Pierre-Louis Bossart wrote:
> > That is some scary stuff there, that is basically working around
> > the fact that with those drivers the soundcard is created before
> > the hardware is actually ready. But its one aspect of that and
> > there are likely many knock on effects/races hiding in there. At
> > some point we should probably revisit the whole enumeration
> > thing in soundwire it does cause a lot of scary code.
> I don't see how we can revisit this, the codec probe happens
> based on ACPI information even before the bus is started. The
> card driver is also probed when the PCI driver creates a platform
> device.

I mean in general the fact SoundWire probes devices before they
are available. It introduces a lot of scary things, as basically
the whole kernel is setup to believe that when a device is probed
it is ready. I mean I know why we did it, because we might need
to setup some things (resets/regulators) to cause the SoundWire
device to enumerate, but it does result in scaryness.

> > That said... the class driver doesn't have the same problem
> > however, because of the two layer nature of the auxiliary driver
> > stuff. The soundwire driver binds to the device and completes
> > probe, but it is the auxiliary drivers that are used in the
> > soundcard and those are only probed once the device itself has
> > enumerated in class_boot_work(). This means the sound card is
> > only created after the device has enumerated, so the same problem
> > isn't present and we can have a more normal PM runtime startup.
> Humm, that's an important detail indeed that I completely missed...
> 
> You could also have registered the function subdevices based on
> ACPI information *before* the whole enumeration. I can see why
> you took that function-register-after-device-enumeration route,
> but I have mixed feelings about having separate mechanisms for
> vendor- and class-drivers.

At least currently you have separate mechanisms regardless
of the choice of probe time since all existing vendor drivers
register a single driver and the class driver registers many
through auxiliary. The difference is only in the secondary
drivers that the vendor drivers don't have anyway.

Personally I like the only registering the functions when the
device has enumerated approach as keeps interactions with other
kernel subsystems within the expectations those subsystems have
of the driver. There is a lot less to think about.

Ultimately, I think the long game solution here is probably that
we move SoundWire to internally have two devices. An initial
device the gets registered and does the probe setup and then a
child device that probes on enumeration. Basically, the same
setup as we have for the auxiliaries in SDCA but internal to
SoundWire. But in the mean time I think using MFD/auxiliary to
introduce a 2 step probe seems like a really neat solution.

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.

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

Thanks,
Charles