From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig Date: Wed, 25 Apr 2018 20:15:10 +0200 Message-ID: References: <20180402170614.5599-1-pierre-louis.bossart@linux.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20180402170614.5599-1-pierre-louis.bossart@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org, Arnd Bergmann , Daniel Drake , Harsha Priya N , Naveen M , Vinod Koul , Mark Brown , Andy Shevchenko , liam.r.girdwood@linux.intel.com, linux-kernel@vger.kernel.org List-Id: alsa-devel@alsa-project.org 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