From nobody Sat May 10 06:48:48 2025 Delivered-To: importer2@patchew.org Received-SPF: pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass(p=none dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1619621649; cv=none; d=zohomail.com; s=zohoarc; b=I5CnnMf8eeFOy8cAUnT3ws2D39bNMc0DeTVnpMypKMAiwGL9LC3MuwUS6fowN9vAARVvp3kF+hW0M8EwhBo1FnnIjq1EVMgsVtLvHVh3CkG5UwuJcD/prQB4N8gXA0AnaTTbPVtMnR85I0HC3TuEEK5snfSfu50qqG8JkllJFzs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619621649; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Id:MIME-Version:Message-ID:References:Sender:Subject:To; bh=CkzDiRgPy8iejVwPrfGJj8JwW/3IpRiOAho8UUQxXuo=; b=Y8mLDdcnWEFTxKWF0SdP5swsPfKi1IejMyDj4LdTb7NqmNhQxOIjrEM4QuBlr0El21LYTzH8CelsDHson+TfC/bdIE2Vj8hygMy6L1wTx9PFnsACD6M/o6cIMp4eogdzzLY5ym4J2CeUatoFO0gDmJgBCyVG0wuaNqr5u67fjYE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mx.zohomail.com with SMTP id 1619621649942307.731855383106; Wed, 28 Apr 2021 07:54:09 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240537AbhD1Oy1 (ORCPT ); Wed, 28 Apr 2021 10:54:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:36312 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240281AbhD1Oxa (ORCPT ); Wed, 28 Apr 2021 10:53:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D39F46144E; Wed, 28 Apr 2021 14:52:43 +0000 (UTC) Received: by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1lblYP-001Dq4-RV; Wed, 28 Apr 2021 16:52:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619621564; bh=XfZSeMotNFyXbfT608pw1ECU5JJkssXPopFyWbltzaE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gQMN97eC7BEDIz1pxwojfxcjha4oPcG+hRlJfly/9mEn3EVUjF6A17eUhRaUV4Av6 9llNqcINPObifS7R+KKJzcq9sElWMQUcLuEgUGm4dEcPAo7WPuTsJBo8FAKaKUj9Hk VsE0m0+uaGwgEcNcCKy4FE+EybZisDq15Xlqw+m72JjyXstPa88Kj6is8ypDBGKPdI X5k3QuLFiBcmGJ+6I0pWZTX0FzZ3AimINfu9/sQCxIkKFaooCIrQkh6kuh/y12/DqV q/M582iW3kDaTv+n6EwJSHs1PeakpZmbEzfwaSOI0e14HbJuwkIcKyqgVAiYfHvp5V b2Ttn7u9UJXRw== From: Mauro Carvalho Chehab Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Mauro Carvalho Chehab , Andrew-CT Chen , Houlong Wei , Matthias Brugger , Mauro Carvalho Chehab , Minghsiu Tsai , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH v4 10/79] media: mdk-mdp: fix pm_runtime_get_sync() usage count Date: Wed, 28 Apr 2021 16:51:31 +0200 Message-Id: <39851c54046fa0d63f34549803df3388361828b7.1619621413.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: Mauro Carvalho Chehab To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal wi= th usage counter") in order to properly decrement the usage counter and avoid memory leaks. While here, fix the return contition of mtk_mdp_m2m_start_streaming(), as it doesn't make any sense to return 0 if the PM runtime failed to resume. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/p= latform/mtk-mdp/mtk_mdp_m2m.c index ace4528cdc5e..f14779e7596e 100644 --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c @@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_que= ue *q, unsigned int count) struct mtk_mdp_ctx *ctx =3D q->drv_priv; int ret; =20 - ret =3D pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev); + ret =3D pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev); if (ret < 0) - mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d", + mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d", ctx->id, ret); =20 - return 0; + return ret; } =20 static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx, --=20 2.30.2