Messages in this thread | | | Date | Wed, 25 Apr 2018 20:15:10 +0200 | From | Takashi Iwai <> | Subject | Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig |
| |
On Mon, 02 Apr 2018 19:06:14 +0200, Pierre-Louis Bossart wrote: > > The split between ACPI and PCI platforms generated issues with randconfig: > > with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and > SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure: > > ERROR: "sst_context_init" > [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined! > > ERROR: "sst_context_cleanup" > [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined! > > ERROR: "sst_alloc_drv_context" > [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined! > > ERROR: "intel_sst_pm" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] > undefined! > > ERROR: "sst_configure_runtime_pm" > [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined! > > To keep things simple, let's expose two configs for > SND_SST_ATOM_HIFI2_PLATFORM_PCI and SND_SST_ATOM_HIFI2_PLATFORM_ACPI, > which select a common SND_SST_ATOM_HIFI2_PLATFORM option. To avoid > breaking existing solutions with the semantics change, > SND_SST_ATOM_HIFI2_PLATFORM_ACPI uses "default ACPI" so that "make > oldnoconfig" and "make olddefconfig" still work as expected.
So now it reached to my tree, and noticed this "default ACPI".
After reading the patch description, I understand the reason behind it, but still I'd say this would confuse users. For example, I was quite surprised and almost proceeded to build this unnecessary just because of the expectation to be default "N" in a standard config.
The distros would enable in anyway, so you don't have to care much. The question is which target should we satisfy more: users who don't need to turn this on, or users who need this. In probability, I'd bet the former :)
Takashi
| |