Received: by 10.192.165.148 with SMTP id m20csp1023005imm; Wed, 25 Apr 2018 11:17:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx49eKoy5ftJ0pjGQUNCiriYc9bpxI10qP8srS+A6AXy8DNvvwhHmRXfW7U7r1TTpBclOnAQe X-Received: by 10.101.83.8 with SMTP id m8mr24231229pgq.28.1524680233547; Wed, 25 Apr 2018 11:17:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524680233; cv=none; d=google.com; s=arc-20160816; b=sAAcKOr8cl96yWQ5ivhScnkilin1nuiAu4EIDUdDCDh2OlGhZU2DIfbWAF8f2YtgnN CCdrB+u1uE0Z9FMoOyDlWo1TrZjytf0PacRz6P6INFRt3SrKuverAljhpPx/gJGkban5 HewcUtEoaTaJvPVqfX1VyIwMgFdk0n3PNZvLrlWb8m+32jOhEps2J5PithcuXCVNuNES y3oZbP/w/R/eoPiVks2jZ7NysArUDdShhd/+RXc21LgZZMfVw5YGtWl37gW94Vi4dy7b zSJefcjgVui71ZO18n9uk1DEeUMXKww5/XWWrIkyxuboDjdNsnAza078ABhWWsBoq82l Nibw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date :arc-authentication-results; bh=V7/6q+DeMxTA4Ins2qE/iOY/s/9uwsIr2U3xX5Vdxqg=; b=c9OxepSETInndU7wSm/2vh/TpaPxd2+O7LyBXeZzYxyemFQT529v+Ze8PVHsKc6qrW 1OJikt7NH0svjeLgvXDhhGOcD80bBQrGcJbdiyl3LfRa+97OuStBnXzkrfNASR5G6Kkc sQjZvs5u9fk7R+oGyrTzywsNYJ1EshdWLHHzV4rH1Yau0kD2SXerGZnwMrC+Y6rutoHc A9i0I/YdHnDXcz2G+dwbJdrGij6zduJRDu42ByKo5cqfUsA56W7o/7RQoVvIZ/W1NL3G KpmvvKG3bLZLPpduSzWDGcRbKj7MQsvrvQ/K/d6u2vwVv/tvD7bsY2eypwl7WuKFfQtq nYbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r22-v6si1138256pls.591.2018.04.25.11.16.59; Wed, 25 Apr 2018 11:17:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756196AbeDYSPR (ORCPT + 99 others); Wed, 25 Apr 2018 14:15:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:39546 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755371AbeDYSPN (ORCPT ); Wed, 25 Apr 2018 14:15:13 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DC568ADB7; Wed, 25 Apr 2018 18:15:11 +0000 (UTC) Date: Wed, 25 Apr 2018 20:15:10 +0200 Message-ID: From: Takashi Iwai To: "Pierre-Louis Bossart" Cc: , "Arnd Bergmann" , "Daniel Drake" , "Harsha Priya N" , "Naveen M" , "Vinod Koul" , "Mark Brown" , "Andy Shevchenko" , , Subject: Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig In-Reply-To: <20180402170614.5599-1-pierre-louis.bossart@linux.intel.com> References: <20180402170614.5599-1-pierre-louis.bossart@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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