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.
