From nobody Sat May 10 06:33:32 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=1619518494; cv=none; d=zohomail.com; s=zohoarc; b=nPr49wtYwpuUBdCeBea3BJi+B/N6Ozq/LrQcvJyVih97P1nJox6xLfN0Ezwv6WsLWQj6g10gQHMijazCHpZo1KeptUfBxRMNcQe50EcTKbozAoGlJiBJjytuyVdofQ2dfGq+1WW4v542s/5guENimwzFUKUMwzvuJzHoSOF2YQ8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619518494; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Id:MIME-Version:Message-ID:References:Sender:Subject:To; bh=CkzDiRgPy8iejVwPrfGJj8JwW/3IpRiOAho8UUQxXuo=; b=n9vSA0IQj/OwUbH5HL0Bv5yYWRyNA80Q+ibHliZOm0bOwHTyHoPNts7oxHPnmWrGgDa093DLxa8tbBqWiERZuj1vXYnelXQeS1eZG4NFOwqvtFj/1KKxYtmdqPCMmSmqc4Ns1upv0+xikd31ZxkbOLOfIFSMNFYP0dSjfI7jO9U= 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 1619518494393617.8665824322758; Tue, 27 Apr 2021 03:14:54 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237469AbhD0KPf (ORCPT ); Tue, 27 Apr 2021 06:15:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:34866 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235366AbhD0KOf (ORCPT ); Tue, 27 Apr 2021 06:14:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E6F2B613C9; Tue, 27 Apr 2021 10:13:50 +0000 (UTC) Received: by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1lbKiy-000j51-J8; Tue, 27 Apr 2021 12:13:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619518431; bh=XfZSeMotNFyXbfT608pw1ECU5JJkssXPopFyWbltzaE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nr2lUUMOHAMasRjwlY5qX3qVA4oegZ5AgUvpL6usdP7kYYZZZM6TsC32yW50v4n6u tcvNRQPCPk6KdTQhVAuWpm8L6wfnAnIjOKNjBAs6jwHBPaBboSwVTtHXpbVHICzTcc 1lBOKpP8EbMRNwPR8QTTYS2F24GO8hT3AURqYHmbXcQqcXviY2sO/li0wDxoeiLi33 nc5lIPv6zUXjHIDqnptAPfdDLqX7OdAffVBQPSFke/Wxl7TBV7w+dNNYe8y48V1rZU mz502CLIOs0MXwwcj+kyRx0Ho46obWLtWanADRaK/TUGgaFs6xRbkw6cpbsKRwfj97 jsoJG5CIc2oSA== 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 v2 09/79] media: mdk-mdp: fix pm_runtime_get_sync() usage count Date: Tue, 27 Apr 2021 12:12:36 +0200 Message-Id: <36568b7ce611dfaf4abc3233c76018a137f934c8.1619518193.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