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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
