From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Rojewski, Cezary" <cezary.rojewski@intel.com>,
Takashi Iwai <tiwai@suse.de>
Cc: Hans de Goede <hdegoede@redhat.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices
Date: Tue, 17 Nov 2020 16:53:08 -0600 [thread overview]
Message-ID: <0badb36f-3089-dc34-f7b0-75a73b856f0d@linux.intel.com> (raw)
In-Reply-To: <0286c6975f24432082f609d45adaa14c@intel.com>
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.
next prev parent reply other threads:[~2020-11-17 22:54 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 22:38 [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 01/14] ASoC: Intel: broadwell: add missing pm_ops Pierre-Louis Bossart
2020-11-13 11:17 ` Rojewski, Cezary
2020-11-12 22:38 ` [PATCH 02/14] ASoC: Intel: bdw-rt5677: " Pierre-Louis Bossart
2020-11-13 11:19 ` Rojewski, Cezary
2020-11-12 22:38 ` [PATCH 03/14] ALSA: hda: intel-dsp-config: add helper for ACPI DSP driver selection Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 04/14] ASoC: soc-acpi: add helper to identify parent driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 05/14] ASoC: Intel: boards: byt/cht: set card and driver name at run time Pierre-Louis Bossart
2021-04-25 18:13 ` youling257
2021-04-26 15:12 ` Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 06/14] ASoC: Intel: byt/cht: set pm ops dynamically Pierre-Louis Bossart
2020-11-17 17:18 ` Mark Brown
2020-11-17 17:39 ` Pierre-Louis Bossart
2020-11-18 13:31 ` Mark Brown
2020-11-12 22:38 ` [PATCH 07/14] ASoC: SOF: acpi: add dynamic selection of DSP driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 08/14] ASoC: Intel: Atom: " Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 09/14] ASoC: SOF: Intel: allow for coexistence between SOF and Atom/SST drivers Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 10/14] ALSA: hda: intel-dsp-config: add Broadwell ACPI DSP driver selection Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 11/14] ASoC: Intel: broadwell: set card and driver name dynamically Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 12/14] ASoC: Intel: catpt: add dynamic selection of DSP driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 13/14] ASoC: SOF: Intel: allow for coexistence between SOF and catpt drivers Pierre-Louis Bossart
2020-11-19 14:06 ` Mark Brown
2020-11-19 17:52 ` Pierre-Louis Bossart
2020-11-19 18:25 ` Mark Brown
2020-11-12 22:38 ` [PATCH 14/14] ALSA: hda: intel-dsp-config: ignore dsp_driver parameter for PCI legacy devices Pierre-Louis Bossart
2020-11-12 23:04 ` [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices Rojewski, Cezary
2020-11-13 13:06 ` Rojewski, Cezary
2020-11-13 14:40 ` Pierre-Louis Bossart
2020-11-13 16:49 ` Mark Brown
2020-11-13 17:06 ` Hans de Goede
2020-11-16 15:39 ` Rojewski, Cezary
2020-11-16 17:47 ` Pierre-Louis Bossart
2020-11-17 14:04 ` Takashi Iwai
2020-11-17 17:31 ` Mark Brown
2020-11-17 17:46 ` Takashi Iwai
2020-11-17 22:13 ` Rojewski, Cezary
2020-11-17 22:53 ` Pierre-Louis Bossart [this message]
2020-11-18 20:15 ` Rojewski, Cezary
2020-11-18 20:25 ` Pierre-Louis Bossart
2020-11-20 15:40 ` Rojewski, Cezary
2020-11-20 16:48 ` Mark Brown
2020-11-20 17:10 ` Rojewski, Cezary
2020-11-20 18:06 ` Mark Brown
2020-11-20 21:02 ` Rojewski, Cezary
2020-11-23 17:35 ` Mark Brown
2020-11-24 11:56 ` Rojewski, Cezary
2020-11-24 14:01 ` Mark Brown
2020-11-24 14:15 ` Takashi Iwai
2020-11-24 16:07 ` Rojewski, Cezary
2020-11-24 16:14 ` Mark Brown
2020-11-24 16:14 ` Takashi Iwai
2020-11-24 16:12 ` Mark Brown
2020-11-18 7:49 ` Takashi Iwai
2020-11-18 20:59 ` Rojewski, Cezary
2020-11-20 21:29 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0badb36f-3089-dc34-f7b0-75a73b856f0d@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=hdegoede@redhat.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).