From: Jiale Yao <yaojiale02@163.com>
To: Nas Chung <nas.chung@chipsnmedia.com>,
Jackson Lee <jackson.lee@chipsnmedia.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Sebastian Fricke <sebastian.fricke@collabora.com>,
Hans Verkuil <hverkuil@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: [PATCH v3 4/4] media: wave5: handle runtime resume failure when closing
Date: Wed, 21 Oct 2026 23:15:51 +0800 [thread overview]
Message-ID: <20261021151552.428590-5-yaojiale02@163.com> (raw)
In-Reply-To: <20261021151552.428590-1-yaojiale02@163.com>
The decoder and encoder close paths ignore runtime resume failures and
proceed to firmware commands. If enabling the VPU clocks failed, those
commands access unavailable registers, and the paths later drop a
runtime PM reference that was not acquired.
Returning the resume error directly also prevents release_device() from
calling wave5_cleanup_instance(). The instance has already been removed
from the device list and its mem2mem context released, so its host-side
resources leak.
On a resume failure, skip the firmware command and hardware lock, free
the close-path resources, and return -EIO. Use a decoder cleanup helper
so auxiliary-buffer cleanup cannot overwrite the resume failure status.
This lets release_device() continue with its common instance cleanup
without unlocking an unheld mutex or issuing an unmatched runtime PM put.
Fixes: 2092b3833487 ("media: chips-media: wave5: Support runtime suspend/resume")
Cc: stable@vger.kernel.org
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
.../platform/chips-media/wave5/wave5-vpuapi.c | 47 ++++++++++++-------
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
index 4c1842f02c..31be2581ae 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
@@ -206,13 +206,26 @@ static int reset_auxiliary_buffers(struct vpu_instance *inst, unsigned int index
return 0;
}
-int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
+static void wave5_vpu_dec_free_resources(struct vpu_instance *inst)
{
struct dec_info *p_dec_info = &inst->codec_info->dec_info;
+ int i;
+
+ wave5_vdi_free_dma_memory(inst->dev, &p_dec_info->vb_work);
+
+ for (i = 0; i < MAX_REG_FRAME; i++)
+ if (reset_auxiliary_buffers(inst, i))
+ break;
+
+ wave5_vdi_free_dma_memory(inst->dev, &p_dec_info->vb_task);
+ mutex_destroy(&inst->feed_lock);
+}
+
+int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
+{
int ret;
int retry = 0;
struct vpu_device *vpu_dev = inst->dev;
- int i;
struct dec_output_info dec_info;
int ret_mutex;
@@ -220,7 +233,11 @@ int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
if (!inst->codec_info)
return -EINVAL;
- pm_runtime_resume_and_get(inst->dev->dev);
+ ret = pm_runtime_resume_and_get(inst->dev->dev);
+ if (ret < 0) {
+ wave5_vpu_dec_free_resources(inst);
+ return -EIO;
+ }
ret_mutex = mutex_lock_interruptible(&vpu_dev->hw_lock);
if (ret_mutex) {
@@ -258,20 +275,7 @@ int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
} while (ret != 0);
dev_dbg(inst->dev->dev, "%s: dec_finish_seq complete\n", __func__);
-
- wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_work);
-
- for (i = 0 ; i < MAX_REG_FRAME; i++) {
- ret = reset_auxiliary_buffers(inst, i);
- if (ret) {
- ret = 0;
- break;
- }
- }
-
- wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
-
- mutex_destroy(&inst->feed_lock);
+ wave5_vpu_dec_free_resources(inst);
unlock_and_return:
mutex_unlock(&vpu_dev->hw_lock);
@@ -750,7 +754,11 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32 *fail_res)
if (!inst->codec_info)
return -EINVAL;
- pm_runtime_resume_and_get(inst->dev->dev);
+ ret = pm_runtime_resume_and_get(inst->dev->dev);
+ if (ret < 0) {
+ ret = -EIO;
+ goto free_resources;
+ }
ret = mutex_lock_interruptible(&vpu_dev->hw_lock);
if (ret) {
@@ -774,6 +782,7 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32 *fail_res)
dev_dbg(inst->dev->dev, "%s: enc_finish_seq complete\n", __func__);
+free_resources:
wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_work);
if (inst->std == W_HEVC_ENC || inst->std == W_AVC_ENC) {
@@ -784,6 +793,8 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32 *fail_res)
}
wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
+ if (ret == -EIO)
+ return ret;
unlock_and_return:
mutex_unlock(&vpu_dev->hw_lock);
--
2.34.1
next prev parent reply other threads:[~2026-10-21 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 15:15 [PATCH v3 0/4] media: wave5: fix runtime PM error handling Jiale Yao
2026-10-21 15:15 ` [PATCH v3 1/4] media: wave5: handle remaining decoder runtime resume failures Jiale Yao
2026-10-22 15:29 ` Brandon Brnich
2026-10-21 15:15 ` [PATCH v3 2/4] media: wave5: use m2m buffer completion helper Jiale Yao
2026-10-22 15:51 ` Brandon Brnich
2026-10-21 15:15 ` [PATCH v3 3/4] media: wave5: handle encoder runtime resume failures Jiale Yao
2026-10-21 15:15 ` Jiale Yao [this message]
2026-10-22 0:51 ` [PATCH v3 4/4] media: wave5: handle runtime resume failure when closing jackson.lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261021151552.428590-5-yaojiale02@163.com \
--to=yaojiale02@163.com \
--cc=hverkuil@kernel.org \
--cc=jackson.lee@chipsnmedia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nas.chung@chipsnmedia.com \
--cc=nicolas.dufresne@collabora.com \
--cc=sebastian.fricke@collabora.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®