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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

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

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

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