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=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 45ED0C5519F for ; Wed, 18 Nov 2020 20:26:49 +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 C1A052145D for ; Wed, 18 Nov 2020 20:26:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="O4uzq6dA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1A052145D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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 AA8CA1710; Wed, 18 Nov 2020 21:25:54 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz AA8CA1710 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1605731205; bh=89HJvYlqRKUiIthTxD53iVkEAkYEDE6FKvl+JEbZdJg=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=O4uzq6dAll/lP42BB9rjSJmM2UzRnbagJ1yiUr8VOyA7f5RjdSfJK49eFdil2GUJf wrM6I/niKC/T0CDCJOJCaVSsazO8Cyl3n+PaG3SyY+Z3n+T2v2iDQVoFX2r6iDPj/c Ht5r5Nl37KaqAETI5Yvrs9NH0wv8jeAiBR9jdEu8= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 43F97F80168; Wed, 18 Nov 2020 21:25:54 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E59B7F8016C; Wed, 18 Nov 2020 21:25:52 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 75DD4F8010A for ; Wed, 18 Nov 2020 21:25:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 75DD4F8010A IronPort-SDR: gOWNjwhRKxwRtpF94afWwXUOBdFlgToMgaSTdqjbdtb9AFLeKnllIqMWGdxh3jVhRF3TXu2jCJ jy56cZ2NeKAw== X-IronPort-AV: E=McAfee;i="6000,8403,9809"; a="170399314" X-IronPort-AV: E=Sophos;i="5.77,488,1596524400"; d="scan'208";a="170399314" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 12:25:41 -0800 IronPort-SDR: nN+GntVSPZKDDuUozuO4HqA+RAe34zGu0qTMTiig5miumtGlOBeclFqv4Co9Jk3Z+3vRBeedqa cD9rz2a7JY9A== X-IronPort-AV: E=Sophos;i="5.77,488,1596524400"; d="scan'208";a="534473410" Received: from sowmyave-mobl.amr.corp.intel.com (HELO [10.212.131.189]) ([10.212.131.189]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 12:25:40 -0800 Subject: Re: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices To: "Rojewski, Cezary" , Takashi Iwai 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> <0badb36f-3089-dc34-f7b0-75a73b856f0d@linux.intel.com> From: Pierre-Louis Bossart Message-ID: Date: Wed, 18 Nov 2020 14:25:39 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: Hans de Goede , "alsa-devel@alsa-project.org" , Mark Brown , "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" >>>> 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? >> >> To be clear: there is *no plan* to *remove* the Atom/sst code any time >> 'soon', only to *deprecate* it. >> >> In the best case distributions would transition in 2021. Some distros >> are faster than others, neither you nor I have any control over this. >> >> Removing code from the kernel is not something we can do unless there is >> demonstrated evidence that the number of impacted users is close to zero >> and distributions no longer support that code. The case of Baytrail >> legacy is telling, you removed it earlier this Fall but after a >> recommended alternative was provided for more than 3 years. >> >> Again, there is no planned 'switch' but a gradual transition, and that >> patchset helps with the transition. > > Hmm, then maybe I misunderstood Hans. Given his feedback it seemed like > Fedora is about to switch to SOF right now. > > Indeed, before I've sent patches removing Baytrail, basically every > support-team had been asked about its usage and the answers were > negative. /atom/ was covering basically every case anyway like you > pointed out so /baytrail/ solution felt more like a duplication. > > As SOF is the desired solution for atom-based products, I can see the > need for some sort of selection mechanism. The same cannot be said for > hsw/bdw though. Let's leave catpt out this, shall we? It helps everyone to have a single build, e.g. 'make allmodconfig' or 'make allyesconfig' would select all possible drivers and bots can run wild.