From: "Rojewski, Cezary" <cezary.rojewski@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>, Hans de Goede <hdegoede@redhat.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: RE: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices
Date: Fri, 20 Nov 2020 17:10:30 +0000 [thread overview]
Message-ID: <758af664b89545c5be83ca2bc81078fb@intel.com> (raw)
In-Reply-To: <20201120164841.GF6751@sirena.org.uk>
On 2020-11-20 5:48 PM, Mark Brown wrote:
> On Fri, Nov 20, 2020 at 03:40:21PM +0000, Rojewski, Cezary wrote:
>> On 2020-11-18 9:25 PM, Pierre-Louis Bossart wrote:
>
>>> 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.
>
>> Why should bots care about not recommended code?
>> I'm against adding external dependency (intel-dsp-config) for
>> catpt for reasons I'd mentioned several times already.
>
> People care about any code that's in the kernel, especially people doing
> anything treewide. The fewer configurations people need to build to get
> code coverage the better.
>
Sure, but in this particular case there really shouldn't be "another
option". If catpt is the sole option, why add intel-dsp-config
dependency? The alternative shouldn't even exist in the kernel and be
instead removed just like /haswell/ and /baytrail/ were.
Czarek
next prev parent reply other threads:[~2020-11-20 17:11 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
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 [this message]
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=758af664b89545c5be83ca2bc81078fb@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=hdegoede@redhat.com \
--cc=pierre-louis.bossart@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.