[PATCH 0/3] media: wave5: Fix critical issues in driver remove path

[PATCH 0/3] media: wave5: Fix critical issues in driver remove path

[Xulin Sun]

This patch series fixes three critical issues in the wave5 VPU driver's
remove path that cause kernel warnings and system crashes.

The issues were discovered and consistently reproduced on kernel 6.12.58-rt6
with the TI AM62A platform. While testing on kernel 6.18 shows the issues
are harder to trigger, the underlying logic problems still exist in the code.

Patch 1: Fixes PM runtime reference count underflow
Patch 2: Fixes kthread worker destruction warning  
Patch 3: Fixes kernel panic due to incorrect cleanup order

All patches have been tested with 50+ consecutive encoding operations and
multiple modprobe/rmmod cycles without any warnings or crashes on 6.12.58-rt6.

Xulin Sun (3):
  media: wave5: Fix PM runtime usage count underflow
  media: wave5: Fix kthread worker destruction in polling mode
  media: wave5: Fix device cleanup order to prevent kernel panic

 drivers/media/platform/chips-media/wave5/wave5-vpu.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

-- 
2.49.1

[PATCH 1/3] media: wave5: Fix PM runtime usage count underflow

[Xulin Sun]

Symptom:
  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98
  ...
  vdec 30210000.video-codec: Runtime PM usage count underflow!

Root cause:
  The driver calls pm_runtime_put_sync() unconditionally in remove, but
  the device may already be suspended due to autosuspend configured in
  probe. When autosuspend has already suspended the device, the usage
  count is 0, and pm_runtime_put_sync() decrements it to -1, causing
  the underflow warning.

Fix:
  Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend()
  which properly pairs with pm_runtime_use_autosuspend() from probe.
  This allows pm_runtime_disable() to handle reference count cleanup
  correctly regardless of current suspend state. The disable function
  internally handles the usage count properly without causing underflow.

Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
---
 drivers/media/platform/chips-media/wave5/wave5-vpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
index e1715d3f43b0..23aa3ab51a0e 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
@@ -356,7 +356,7 @@ static void wave5_vpu_remove(struct platform_device *pdev)
 		hrtimer_cancel(&dev->hrtimer);
 	}
 
-	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	mutex_destroy(&dev->dev_lock);
-- 
2.49.1

[PATCH 2/3] media: wave5: Fix kthread worker destruction in polling mode

[Xulin Sun]

Symptom:
  ------------[ cut here ]------------
  WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98
  Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ...
  Call trace:
   kthread_destroy_worker+0x84/0x98
   wave5_vpu_remove+0xc8/0xe0 [wave5]
   platform_remove+0x30/0x58
  ...
  ---[ end trace 0000000000000000 ]---

Root cause:
  In polling mode (irq < 0), the driver uses hrtimer to periodically
  trigger wave5_vpu_timer_callback() which queues work via
  kthread_queue_work(). The kthread_destroy_worker() function validates
  that both work queues are empty:
  * WARN_ON(!list_empty(&worker->work_list))
  * WARN_ON(!list_empty(&worker->delayed_work_list))

  The original code called kthread_destroy_worker() before hrtimer_cancel(),
  creating a race condition where the timer could fire during worker
  destruction and queue new work, triggering the WARN_ON.

Fix:
  Reorder cleanup sequence:
  1) Cancel hrtimer first - stops the timer from firing and prevents
     new work from being queued
  2) Cancel current work with kthread_cancel_work_sync() - ensures any
     in-flight work completes
  3) Destroy worker - now both work queues are guaranteed empty, so
     kthread_destroy_worker() won't trigger warnings

Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
---
 drivers/media/platform/chips-media/wave5/wave5-vpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
index 23aa3ab51a0e..0bcd48df49d0 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
@@ -352,8 +352,9 @@ static void wave5_vpu_remove(struct platform_device *pdev)
 	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
 
 	if (dev->irq < 0) {
-		kthread_destroy_worker(dev->worker);
 		hrtimer_cancel(&dev->hrtimer);
+		kthread_cancel_work_sync(&dev->work);
+		kthread_destroy_worker(dev->worker);
 	}
 
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-- 
2.49.1

[PATCH 3/3] media: wave5: Fix device cleanup order to prevent kernel panic

[Xulin Sun]

Symptom:
  Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
  Modules linked in: wave5 rpmsg_ctrl rpmsg_char ...
  CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G   M    W
  pc : wave5_vdi_read_register+0x10/0x38 [wave5]
  lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5]

  Call trace:
   wave5_vdi_read_register+0x10/0x38 [wave5]
   kthread_worker_fn+0xd8/0x238
   kthread+0x104/0x120
   ret_from_fork+0x10/0x20
  Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000)
  ---[ end trace 0000000000000000 ]---
  Kernel panic - not syncing: synchronous external abort: Fatal exception

Root cause:
  In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback()
  which queues work to the kthread worker. The worker executes
  wave5_vpu_irq_work_fn() which reads hardware registers via
  wave5_vdi_read_register().

  The original cleanup order was:
  1) Disable PM runtime and power down hardware
  2) Unregister video devices

  When autosuspend triggers and powers off the hardware, the video
  devices are still registered and the worker thread can still be
  triggered by the hrtimer, causing it to attempt reading registers
  from powered-off hardware. This results in a bus error (synchronous
  external abort) and kernel panic.

Fix:
  Move video device unregistration (wave5_vpu_enc_unregister_device,
  wave5_vpu_dec_unregister_device, v4l2_device_unregister) to the beginning
  of wave5_vpu_remove(), before worker cleanup and PM runtime disable.

  This ensures video operations stop before any hardware access mechanisms
  are cleaned up, following the pattern used by other V4L2 drivers (pisp_be, rga).

Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
---
 drivers/media/platform/chips-media/wave5/wave5-vpu.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
index 0bcd48df49d0..77d6c934d0b9 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
@@ -351,6 +351,10 @@ static void wave5_vpu_remove(struct platform_device *pdev)
 {
 	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
 
+	wave5_vpu_enc_unregister_device(dev);
+	wave5_vpu_dec_unregister_device(dev);
+	v4l2_device_unregister(&dev->v4l2_dev);
+
 	if (dev->irq < 0) {
 		hrtimer_cancel(&dev->hrtimer);
 		kthread_cancel_work_sync(&dev->work);
@@ -364,9 +368,6 @@ static void wave5_vpu_remove(struct platform_device *pdev)
 	mutex_destroy(&dev->hw_lock);
 	reset_control_assert(dev->resets);
 	clk_bulk_disable_unprepare(dev->num_clks, dev->clks);
-	wave5_vpu_enc_unregister_device(dev);
-	wave5_vpu_dec_unregister_device(dev);
-	v4l2_device_unregister(&dev->v4l2_dev);
 	wave5_vdi_release(&pdev->dev);
 	ida_destroy(&dev->inst_ida);
 }
-- 
2.49.1

Re: [PATCH 0/3] media: wave5: Fix critical issues in driver remove path

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Hi,


Le mercredi 03 décembre 2025 à 12:09 +0800, Xulin Sun a écrit :
> This patch series fixes three critical issues in the wave5 VPU driver's
> remove path that cause kernel warnings and system crashes.
> 
> The issues were discovered and consistently reproduced on kernel 6.12.58-rt6
> with the TI AM62A platform. While testing on kernel 6.18 shows the issues
> are harder to trigger, the underlying logic problems still exist in the code.
> 
> Patch 1: Fixes PM runtime reference count underflow
> Patch 2: Fixes kthread worker destruction warning  
> Patch 3: Fixes kernel panic due to incorrect cleanup order

Thanks, applicable to all your patches, please reformat your commits message to
follow the guidelines. Avoid the "Symptoms:/Root cause:/Fix:" titles, reader can
figure-out what this is. And then reverse the order, what is fixed in the first
paragraph, explanation of the root cause in the second and what users would get
(symptoms) at the end.

Also for all your patches, add the missing Fixes: tags, these are important for
backports.

> 
> All patches have been tested with 50+ consecutive encoding operations and
> multiple modprobe/rmmod cycles without any warnings or crashes on 6.12.58-rt6.

I don't think its going to be a big deal, but please, retest on media-
committers/next (currently 6.18-rc5) branch and report.

With all this covered, you can add my Rb to your v2.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>

regards,
Nicolas

> 
> Xulin Sun (3):
>   media: wave5: Fix PM runtime usage count underflow
>   media: wave5: Fix kthread worker destruction in polling mode
>   media: wave5: Fix device cleanup order to prevent kernel panic
> 
>  drivers/media/platform/chips-media/wave5/wave5-vpu.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]