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.8 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 D487DC433DF for ; Fri, 24 Jul 2020 19:56:07 +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 5CE87206F0 for ; Fri, 24 Jul 2020 19:56:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="I1GRdqkd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CE87206F0 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 BC06A167C; Fri, 24 Jul 2020 21:55:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz BC06A167C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1595620565; bh=5KQ1WmKzCidLjZQN8WjCeZPm47gWSDcRvLDn0Qp0hKg=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=I1GRdqkdkvMfjFmeN5184FqLd7ETDX2wz69n+k/dkX+GKggZaRzGxZhccs8OTMNyF jArk6/wAcrvgAvcU/iVygC2srJYBV8GM6xO0F2rHzEPHeokGYbfGRoXn8Hsa8BEym0 27vcvoCeMpbH47sdxsgKXQ1UoMiaw97khDZSqgRk= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 47415F80141; Fri, 24 Jul 2020 21:55:15 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 74574F8014C; Fri, 24 Jul 2020 21:55:13 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 A1354F800DF for ; Fri, 24 Jul 2020 21:55:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz A1354F800DF IronPort-SDR: qYHNOl9RW8V37yyjmaCOVJCxxDFF7JdSS/uqnK4UoswKxoSfXUaSSy+gTIaaUQsv2BPPIcJ3Ji JP09zNvG28HQ== X-IronPort-AV: E=McAfee;i="6000,8403,9692"; a="168904457" X-IronPort-AV: E=Sophos;i="5.75,391,1589266800"; d="scan'208";a="168904457" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2020 12:55:04 -0700 IronPort-SDR: K9HoBDnheYlwXP2NIAqdfWqqtaNbqJ9pv48dA92xjJ0gxc/Ldofx0HulkWkgjkzAvVAXUmML7Y zl8OTcA6c1Rw== X-IronPort-AV: E=Sophos;i="5.75,391,1589266800"; d="scan'208";a="289090696" Received: from tuanado-mobl1.amr.corp.intel.com (HELO [10.254.79.47]) ([10.254.79.47]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2020 12:55:03 -0700 Subject: Re: [PATCH] ASoC: core: use less strict tests for dailink capabilities To: Jerome Brunet , alsa-devel@alsa-project.org References: <20200723180533.220312-1-pierre-louis.bossart@linux.intel.com> <1jlfj98gb4.fsf@starbuckisacylon.baylibre.com> From: Pierre-Louis Bossart Message-ID: <576823fb-a8a8-1f74-b7e2-d33b734022a7@linux.intel.com> Date: Fri, 24 Jul 2020 14:05:55 -0500 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: <1jlfj98gb4.fsf@starbuckisacylon.baylibre.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: tiwai@suse.de, broonie@kernel.org 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" > Again, this is changing the original meaning of the flag from "playback > allowed" to "playback required". > > This patch (or the orignal) does not explain why this change of meaning > is necessary ? The point I was making here [0] still stands. > > If your evil plan is to get rid of 2 of the 4 flags, why go through the > trouble of the changing the meaning and effect of one them ? My intent was to have a non-ambiguous definition. I don't know 'playback allowed' means. What is the point of using this flag if it may or may not accurately describe what is actually implemented? And how can we converge the use of flags since in the contrary 'playback_only' is actually a clear indication of what the link does. We've got to align on the semantics, and I really don't see the point of watering-down definitions. When things are optional or poorly defined, the confusion continues. WFIW, my 'evil' plan was to rename 'dpcm_playback' as 'can_playback' (same for capture) and replace 'playback_only' by 'can_playback = 1; can_capture = 0'. So this first step was really to align them on the expected behavior and minimal requirements.