[PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices

[Pierre-Louis Bossart]

>>>> I guess Cezary mean the modprobe blacklist?  This was used in the
>>>> early stage of ASoC Skylake driver development, but in the end, it's
>>>> more cumbersome because user needs to change multiple places.  The
>>>> single module parameter was easier to handle.
>>>>
>>>
>>> Thanks for joining the discussion, Takashi.
>>>
>>> If the switch of solution for atom-based products is imminent, why add
>>> code which becomes redundant soon after?
>>
>> To be clear: there is *no plan* to *remove* the Atom/sst code any time
>> 'soon', only to *deprecate* it.
>>
>> In the best case distributions would transition in 2021. Some distros
>> are faster than others, neither you nor I have any control over this.
>>
>> Removing code from the kernel is not something we can do unless there is
>> demonstrated evidence that the number of impacted users is close to zero
>> and distributions no longer support that code. The case of Baytrail
>> legacy is telling, you removed it earlier this Fall but after a
>> recommended alternative was provided for more than 3 years.
>>
>> Again, there is no planned 'switch' but a gradual transition, and that
>> patchset helps with the transition.
> 
> Hmm, then maybe I misunderstood Hans. Given his feedback it seemed like
> Fedora is about to switch to SOF right now.
> 
> Indeed, before I've sent patches removing Baytrail, basically every
> support-team had been asked about its usage and the answers were
> negative. /atom/ was covering basically every case anyway like you
> pointed out so /baytrail/ solution felt more like a duplication.
> 
> As SOF is the desired solution for atom-based products, I can see the
> need for some sort of selection mechanism. The same cannot be said for
> hsw/bdw though. Let's leave catpt out this, shall we?

It helps everyone to have a single build, e.g. 'make allmodconfig' or 
'make allyesconfig' would select all possible drivers and bots can run wild.