Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2645698pxa; Mon, 24 Aug 2020 22:07:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfI6HPu9/OQN7c2HraR0cCDRiRyv7W1R3NdhB/LiV06K69g3xpYzvJf8xVWb7qsxPonAWT X-Received: by 2002:a17:906:1a0a:: with SMTP id i10mr9203530ejf.204.1598332032443; Mon, 24 Aug 2020 22:07:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598332032; cv=none; d=google.com; s=arc-20160816; b=qqSBMmiRpzLDyv5iy2fa1+oRmT4zoZxmWZJEzCp2LLF3ifwNzqexQ4Helm3oeOY2xv YhoSpv3ARkjSHqPkF/PhZFdrTW77/cwyat/RJghSJYY0FRDeLfdWXrRb5zPMEz8W2jev eZ9rMqdIJptBFryIO+/rL/YhfR3GikMOWMPiOpgStwhI5gBmbfImozGV/G1P1V4/uM1B NPilQUC2fnIQ5NIA5zZ9eDrNNa6mOuDZkTioI52B9uDNywPlAGuJw46DW7k92lxAcs5O wTusSCR9HM85R8rpo86oBIEIfeveaMzV+3IS7SK4SYZvggnzuyB73skhFfnx+243FuHT 7j8g== 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; bh=F6Rme//WGsgHWNK5aF0Nk/A0oG8zb+id90tpIv6RRVw=; b=GjUnSTZRzFoKMvlZBEAazmF0Y1mwEFDa7ygBsQ79RTn9RiZCmepnA6oVmv5w7uu3uL 7Gdosb9bVzDnx1tA0Y5SKx9r4uZrYvcLzsLZpOIZIYd1g2Roc6csMCmWUMQsdPsdYclz DSmIWCYCtRS8rw9tpHD9LjLmQAGtNMYy6lfAF2CbVqm6ZzAV5onZOsfxkb4V64axTPOH LzTtd/RpH9sElP7NtBuAK8t8T/MaxCy2OguRFbYlG/EjwluslJ1Ap41rXc/Cs4T3qp0J 4yHTevv82I0Wwi4JI6S+DngxTA+jRz1ivF6/LtmSqnMr6zuumNKIZ8Iq2iypuILaUV5S lHWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id me20si2112266ejb.270.2020.08.24.22.06.49; Mon, 24 Aug 2020 22:07:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728352AbgHYEy3 (ORCPT + 99 others); Tue, 25 Aug 2020 00:54:29 -0400 Received: from relmlor1.renesas.com ([210.160.252.171]:21098 "EHLO relmlie5.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725792AbgHYEy3 (ORCPT ); Tue, 25 Aug 2020 00:54:29 -0400 Date: 25 Aug 2020 13:54:28 +0900 X-IronPort-AV: E=Sophos;i="5.76,351,1592838000"; d="scan'208";a="55442315" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie5.idc.renesas.com with ESMTP; 25 Aug 2020 13:54:28 +0900 Received: from mercury.renesas.com (unknown [10.166.252.133]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id D029641C6063; Tue, 25 Aug 2020 13:54:27 +0900 (JST) Message-ID: <87sgcbwcnf.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Sameer Pujar Cc: , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 3/9] ASoC: audio-graph: Identify 'no_pcm' DAI links for DPCM In-Reply-To: <2d3aa11e-3c56-1f7a-3d41-2457f973d55b@nvidia.com> References: <1596605064-27748-1-git-send-email-spujar@nvidia.com> <1596605064-27748-4-git-send-email-spujar@nvidia.com> <87pn7ofs19.wl-kuninori.morimoto.gx@renesas.com> <97f325a6-96cc-11c5-8027-8c0a159e3da0@nvidia.com> <2d3aa11e-3c56-1f7a-3d41-2457f973d55b@nvidia.com> User-Agent: Wanderlust/2.15.9 Emacs/26.3 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") 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 Hi Sameer > +static bool soc_component_is_pcm(struct snd_soc_dai_link_component *dlc) > +{ > + struct snd_soc_dai *dai = snd_soc_find_dai(dlc); > + > + if (dai && (dai->component->driver->pcm_construct || > + dai->driver->pcm_new)) > + return true; > + > + return false; > +} (snip) > I tried testing this with LOCKDEP config enabled at my end. > It seems I don't see warning originated from above function. > Are you suggesting that, in general, snd_soc_find_dai() > should be called with client_mutex held? Hmm ? strange... snd_soc_find_dai() is using lockdep_assert_held() struct snd_soc_dai *snd_soc_find_dai(...) { ... => lockdep_assert_held(&client_mutex); ... } and lockdep_assert_held() will indicate WARN_ON() -- lockdep.h -- ... #ifdef CONFIG_LOCKDEP ... #define lockdep_assert_held(l) do { \ => WARN_ON(debug_locks && !lockdep_is_held(l)); \ } while (0) > May be snd_soc_dai_link_set_capabilities() requires similar fix? Yes, I'm posting fixup patch. https://patchwork.kernel.org/patch/11719919/ Thank you for your help !! Best regards --- Kuninori Morimoto