From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E347C5519F for ; Wed, 18 Nov 2020 07:50:52 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1724C2468D for ; Wed, 18 Nov 2020 07:50:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="f+ALR4eK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1724C2468D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id A8CA816FA; Wed, 18 Nov 2020 08:49:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A8CA816FA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1605685848; bh=CbDSdrwwKdGs9QRBw/vgiAjlRLfdRuLFDQ3MX9CoslU=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=f+ALR4eKeJn9xH3Fadg8UInlm9Ak3WZkRzlJT/xBNlE5my/A/iGBRHUIbU1kR4XDl XYWe3xivVKpBc8XqHs3nxGF7FU3eEmebx1vsYX3u6nya1I+4ATfKm8scPwmRznkKW4 5vNhMNNSnvlwvLPlKVpCCVT7eUMR+MgYSN/oAxyo= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 3FAB9F80168; Wed, 18 Nov 2020 08:49:58 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id EC6E5F8016C; Wed, 18 Nov 2020 08:49:56 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0C38DF80158 for ; Wed, 18 Nov 2020 08:49:45 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0C38DF80158 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2FC3BABDE; Wed, 18 Nov 2020 07:49:45 +0000 (UTC) Date: Wed, 18 Nov 2020 08:49:45 +0100 Message-ID: From: Takashi Iwai To: "Rojewski, Cezary" Subject: Re: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices In-Reply-To: <0286c6975f24432082f609d45adaa14c@intel.com> References: <20201112223825.39765-1-pierre-louis.bossart@linux.intel.com> <0a0854d1ddaf4f9b81ef5569a7d501a5@intel.com> <20201113164946.GD4828@sirena.org.uk> <2cf7075b-bd51-21a5-2058-3a98e6c488a7@redhat.com> <0286c6975f24432082f609d45adaa14c@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 Cc: Hans de Goede , "alsa-devel@alsa-project.org" , Mark Brown , Pierre-Louis Bossart , "andriy.shevchenko@linux.intel.com" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 17 Nov 2020 23:13:13 +0100, Rojewski, Cezary wrote: > > On 2020-11-17 3:04 PM, Takashi Iwai wrote: > > On Mon, 16 Nov 2020 18:47:22 +0100, > > Pierre-Louis Bossart wrote: > >> > >>> Explicit 'ifs' asking whether we're dealing with SOF or other solution > >>> is at best a code smell. I believe this is unnecessary complexity added > >>> to the code especially once you realize user needs to play with module > >>> parameters to switch between solutions. If we assume user is able to > >>> play with module parameters then why not simply make use of blacklist > >>> mechanism? > >> > >> Been there, done that. We don't want to use either denylist of kernel > >> parameters. > >> > >> denylists create confusion for users, it's an endless stream of false > >> errors and time lost in bug reports. > >> > >> The use of the kernel parameter is ONLY for expert users who want to > >> tinker with the system or debug issues, the average user should not > >> have to play with either denylists or kernel parameters. > > > > I guess Cezary mean the modprobe blacklist? This was used in the > > early stage of ASoC Skylake driver development, but in the end, it's > > more cumbersome because user needs to change multiple places. The > > single module parameter was easier to handle. > > > > Thanks for joining the discussion, Takashi. > > If the switch of solution for atom-based products is imminent, why add > code which becomes redundant soon after? > > Yes, indeed I meant the modprobe blacklisting as it solves the problem > without addition of any code. Doubt alsa-driver entries are scattered in > /etc/modprobe.d/ so switching between one solution to another via > blacklist becomes as easy as changing 'options intel-dsp-config > ==' entry. Ideally blacklist would work well, but practically it can be more problematic. When you *switch* between multiple drivers via blacklist, you'll have to mask one of them while keeping another untouched, so either: blacklist A or blacklist B Now, imagine that distro sets "blacklist A" to choose B as the default. What user has to do? They have to modify "blacklist A" line with "blacklist B". But it can't be done with an additional modprobe.d/*.config file; otherwise this blacklist remains. It means they have to scratch the system configuration file itself -- which might be again overridden by a package update or whatever. This will be more complex if there are more than three choices, of course. Admittedly, the situation with the system config file be same for module option if distro sets the option in modprobe.d/*, too. But, there is another difference: the default option value can be set in the kernel code, while the blacklist approach is to let all open and choose via blacklist. IOW, devs have some control for choosing the default value for the module option but for blacklist they are all done by user-space side. > In regard to catpt, solution is even simpler: just remove > sound/soc/sof/intel/bdw.c as that code is not valid & recommended > anyway and linux kernel is not place for such. There shouldn't be really > any options for not recommended stuff. Leave the selection explicit. > > >>> And last but not least: intel-dsp-config is (as already stated) a mean > >>> for solving the HDA-runtime-driver-selection problem. Mixing it with > >>> ACPI devices is another layer of confusion. > >> > >> Why? Who said it was PCI only? We already take care of DMIC, > >> SoundWire, Google Chromebooks, open platforms, why not ACPI? It's just > >> one API to be used when more than one driver can register to the same > >> device. > > > > Well, currently intel-dsp-config sits in sound/hda, which isn't really > > intuitive. Though, Intel driver file paths are already fairly > > scattered, so it doesn't matter too much :) > > > > I don't mind to move it to another directory, but which one...? > > x86 might match, but shuffling the place won't help for maintenance. > > > > I personally find this move good, at least it makes things easier for > > distros. There are small details like the above, but technically > > seen, I see no big problem. > > Well, if non-Intel guys see the localization of code counter-intuitive > then how about those who play with it daily.. I play it and maintain it daily, that's why I find unintuitive :) I guess most users don't notice the file path, as the module loading or option is done only by the module name. > The new "sof-parent" checks won't make maintaining any easier and I > believe there are easier solutions as written above. If you find a good way to overcome the disadvantage, that's great. Let's see. thanks, Takashi