On 11/17/20 4:13 PM, Rojewski, Cezary wrote:
On 2020-11-17 3:04 PM, Takashi Iwai wrote:
On Mon, 16 Nov 2020 18:47:22 +0100,
Pierre-Louis Bossart wrote:
Explicit 'ifs' asking whether we're dealing with SOF or other solution
is at best a code smell. I believe this is unnecessary complexity added
to the code especially once you realize user needs to play with module
parameters to switch between solutions. If we assume user is able to
play with module parameters then why not simply make use of blacklist
mechanism?
Been there, done that. We don't want to use either denylist of kernel
parameters.
denylists create confusion for users, it's an endless stream of false
errors and time lost in bug reports.
The use of the kernel parameter is ONLY for expert users who want to
tinker with the system or debug issues, the average user should not
have to play with either denylists or kernel parameters.
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.
