Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp754612iog; Fri, 17 Jun 2022 12:52:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tqmGu3Mr0svn5LyFNme3ILy6+WEU2SvcnJEbNMSte+yQNnQcryY1fVHhIwy8SoiDTK0pym X-Received: by 2002:a17:903:2308:b0:167:7030:6847 with SMTP id d8-20020a170903230800b0016770306847mr11128407plh.122.1655495553744; Fri, 17 Jun 2022 12:52:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655495553; cv=none; d=google.com; s=arc-20160816; b=bi6iYniGFTR5YdnMfdDOTdbIgXUnAANWpRlPBnxOMpXQ/yFpzitFsnJnkd8QxBUL43 vpcYMUS+IdHUm92ks4KthStDGbY6E7WGUX0p2N4W1C/j09AArNnpPh9AXYto4hLeYWzZ J6SZcGxKyb6bxLRLxhRCP6UhN+YnYYBU2k5aA8rluK4iKa+de5yTr8oGtaGrtdjhJQdc YY9PiAW50kKRvuytsjcXg4EPltg1XtjAWYF6kgognYV1/07aFL1p+ZQvXcir1hjYp59M LS3eJZSssbp5HCbu7moQ68Lj5QA5zTSFJVSeYSsQp8qR4fMRtM/wQ0rgbXo5j0FY79JR dXPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=bmYRY16Ksi7pgeSioW3/NHfW4cOAkNck3f8eJi3lRj4=; b=A88E6/9m7vzGq0CqPSbqch7mhNkvCGEHtYhc5FBgaL03APF1eaHvVrOpzpd/YUBjmm j09pHVyNokDP1ti8qcp5Qlkf2WdjJ7Iz69OV81GnbQRBuv8RAQ4tfvvz/KaLob8I4AQ9 +BY4YtlBPZaW0MLKUQzjJUsOrbcdd7NW/2FiRjneuogu1JQ+qNxXsoyMGOPc0CLEaDSz zSB5OMBliYJqSlfXG/vDUcuGTlUmhQztpKLDE8F+GUZS3W1jVbNrkvIFcitQZfGlPodk BhhEufZ2iubBpdH3t2Jqklql4o1Eh+lzNLxx4mY96iKafsE3cfPAllVoENhjYJth6jyh zGyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c8qjOmPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p3-20020a62d003000000b005189da52427si7564179pfg.345.2022.06.17.12.52.22; Fri, 17 Jun 2022 12:52:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c8qjOmPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234673AbiFQTro (ORCPT + 99 others); Fri, 17 Jun 2022 15:47:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230011AbiFQTrm (ORCPT ); Fri, 17 Jun 2022 15:47:42 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1CCB64F2 for ; Fri, 17 Jun 2022 12:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655495260; x=1687031260; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=UArsJI0e93/zPeU0GTpsxAfxvbVJorGPGyLoU1Vq9ig=; b=c8qjOmPndDbIRr1L1dWL+6OJp83oJTrUAjSysGucTcjT/gEm7nnBadny vAF18F/UCam8I7zAIa4AaP2m2qr0Qzh6LRZdWRSDCbSF2xu2GVo1vUkut tnJUGp1zn44dNhzFe7mDkR7l3CxGNZyL8uf7gyIYfx6+9ZisXl8VuiGFW Snl6N3o9X5lbi5tN12RBNvJO9zQHtEBSvEYlMBwgRI14bc3c6UvyMEtZk +bsUAiF3H4tk2njas6oZ/NWQWX1hQ7OOfjwkJQdYYCD1CLo02p86NiQnS fu9xhNnl50LhStsOm4g2gIfYBQs2+G+UyBHeJocWqgt944ILC7igxeY7i Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10380"; a="279607011" X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="279607011" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2022 12:47:40 -0700 X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="642163174" Received: from patelman-mobl1.amr.corp.intel.com (HELO [10.212.115.29]) ([10.212.115.29]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2022 12:47:39 -0700 Message-ID: Date: Fri, 17 Jun 2022 14:47:39 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.9.1 Subject: Re: [PATCH 03/11] ASoC: soc-component: use pm_runtime_resume_and_get() Content-Language: en-US To: alsa-devel@alsa-project.org Cc: Cezary Rojewski , Kai Vehmanen , Liam Girdwood , tiwai@suse.de, open list , Takashi Iwai , Ranjani Sridharan , broonie@kernel.org, =?UTF-8?Q?Amadeusz_S=c5=82awi=c5=84ski?= , Bard Liao References: <20220616220427.136036-1-pierre-louis.bossart@linux.intel.com> <20220616220427.136036-4-pierre-louis.bossart@linux.intel.com> From: Pierre-Louis Bossart In-Reply-To: <20220616220427.136036-4-pierre-louis.bossart@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/16/22 17:04, Pierre-Louis Bossart wrote: > simplify the flow. No functionality change, except that on -EACCESS > the reference count will be decreased. This patch turns out to be incorrect and should not be merged. I missed the fact that the component pm_runtime_put() will decrease the reference count that is already decreased with pm_runtime_resume_and_get() when pm_runtime is not enabled. This leads to warnings: snd-soc-dummy snd-soc-dummy: Runtime PM usage count underflow! Unfortunately we missed those warnings during validation, that's not so good. pm_runtime_resume_and_get() really needs to be used ONLY when the get/put are part of the same function and the reference count can be checked. When the get/put are in different functions, it's asking for trouble. Also the check on -EACCES is problematic when the component is handled by a framework, it's not clear if that can happen or not. The rest of the patches follow the pattern get_sync/put and don't have a problem. Sorry for the noise. > > Signed-off-by: Pierre-Louis Bossart > Reviewed-by: Bard Liao > Reviewed-by: Kai Vehmanen > Reviewed-by: Ranjani Sridharan > --- > sound/soc/soc-component.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/sound/soc/soc-component.c b/sound/soc/soc-component.c > index e12f8244242b9..cb92e002c38bc 100644 > --- a/sound/soc/soc-component.c > +++ b/sound/soc/soc-component.c > @@ -1213,11 +1213,11 @@ int snd_soc_pcm_component_pm_runtime_get(struct snd_soc_pcm_runtime *rtd, > int i; > > for_each_rtd_components(rtd, i, component) { > - int ret = pm_runtime_get_sync(component->dev); > - if (ret < 0 && ret != -EACCES) { > - pm_runtime_put_noidle(component->dev); > + int ret = pm_runtime_resume_and_get(component->dev); > + > + if (ret < 0 && ret != -EACCES) > return soc_component_ret(component, ret); > - } > + > /* mark stream if succeeded */ > soc_component_mark_push(component, stream, pm); > }