From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757967AbdKONQv (ORCPT ); Wed, 15 Nov 2017 08:16:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:50360 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753277AbdKONQm (ORCPT ); Wed, 15 Nov 2017 08:16:42 -0500 Date: Wed, 15 Nov 2017 14:16:41 +0100 Message-ID: From: Takashi Iwai To: Mark Brown Cc: Linus Torvalds , Vinod Koul , Pierre-Louis Bossart , Liam Girdwood , Linux Kernel Mailing List , alsa-devel@alsa-project.org Subject: Re: [GIT PULL] sound updates for 4.15-rc1 In-Reply-To: <20171115121648.jjbs4jdpjoyhkbqo@sirena.org.uk> References: <20171115113742.27b2nvfsbtvv7gfs@sirena.org.uk> <20171115121648.jjbs4jdpjoyhkbqo@sirena.org.uk> 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Nov 2017 13:16:48 +0100, Mark Brown wrote: > > On Wed, Nov 15, 2017 at 12:58:40PM +0100, Takashi Iwai wrote: > > Mark Brown wrote: > > > On Wed, Nov 15, 2017 at 08:34:09AM +0100, Takashi Iwai wrote: > > > > Though transitioning back would probably just create more misery. > > > It's a real shame that ACPI doesn't have standards for the machine > > > descriptions here like DT does, it'd cut down on the amount of stuff > > > that needs configuring. > > > True. Although I don't think ACPI is the center of the mess in this > > case, but rather too many kconfigs is it. > > It's the source of all the individual board Kconfigs - we can't just > have an equivalent of the of-graph card - and then the explosion of > board configs then pushes to have more of the other options user > selectable to let people make the list more manageable. OK, point taken. > > We should begin with thinking of which entries (and layer) to be > > selectable, and which not. > > I'd say either just all the individual machines like it was or all the > SoCs. If it's the SoCs it prevents people making really tiny configs, > though I'm not sure who cares. If it's the machines then you get a lot > of options but I don't know that this is a problem, it's not like end > users are routinely configuring their kernel. It might sound contradicting to my previous statement, but the number of selections itself isn't a big problem. The problem is rather that multiple options have to be selected for reaching to the point to enable one feature on your machine. So, I agree that these two representations would be suitable, and the usual solution is the firmer, to expose *only* individual machine drivers as selectable. (Or, at most, we can have kconfig entries just filtering in addition.) Takashi