* [PATCH] drm/tegra: gr3d: fix autosuspend cleanup during teardown
@ 2026-08-08 14:22 Guangshuo Li
2026-08-08 14:34 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Guangshuo Li @ 2026-08-08 14:22 UTC (permalink / raw)
To: Thierry Reding, Mikko Perttunen, David Airlie, Simona Vetter,
Jonathan Hunter, dri-devel, linux-tegra, linux-kernel
Cc: Guangshuo Li, stable
gr3d_probe() calls pm_runtime_use_autosuspend(), but gr3d_remove()
does not call the matching pm_runtime_dont_use_autosuspend() during
teardown.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped.
The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().
Add the missing pm_runtime_dont_use_autosuspend() call to the driver
remove path.
This issue was found by manual code inspection.
Fixes: 62fa0a985e2c ("drm/tegra: Enable runtime PM during probe")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/gpu/drm/tegra/gr3d.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 1ec6ced959e4..5fd1fd32fcc0 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -534,6 +534,7 @@ static void gr3d_remove(struct platform_device *pdev)
{
struct gr3d *gr3d = platform_get_drvdata(pdev);
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
pm_runtime_disable(&pdev->dev);
host1x_client_unregister(&gr3d->client.base);
}
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] drm/tegra: gr3d: fix autosuspend cleanup during teardown
2026-08-08 14:22 [PATCH] drm/tegra: gr3d: fix autosuspend cleanup during teardown Guangshuo Li
@ 2026-08-08 14:34 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-08-08 14:34 UTC (permalink / raw)
To: Guangshuo Li; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Unreachable Code / Broken Power Management due to incorrect placement of pm_runtime_enable()
- [Medium] Guideline Violation: missing pm_ptr() wrapper for dev_pm_ops assignment
--
--- Patch [1]: [PATCH] drm/tegra: gr3d: fix autosuspend cleanup during teardown ---
commit 94bf3f52211b3cc132d2cfe856cc599ac46c8751
Author: Guangshuo Li <lgs201920130244@gmail.com>
drm/tegra: gr3d: fix autosuspend cleanup during teardown
This commit adds a missing pm_runtime_dont_use_autosuspend() call during
driver removal.
> gr3d_probe() calls pm_runtime_use_autosuspend(), but gr3d_remove()
> does not call the matching pm_runtime_dont_use_autosuspend() during
> teardown.
[Severity: High]
This is a pre-existing issue, but does the runtime PM initialization
actually work as described?
It appears pm_runtime_enable() and autosuspend configurations are placed in
gr3d_runtime_resume() rather than gr3d_probe():
drivers/gpu/drm/tegra/gr3d.c:gr3d_runtime_resume() {
...
pm_runtime_enable(dev);
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, 500);
...
}
Since the PM core initializes devices with runtime PM disabled, won't this
callback never be invoked, leaving the device permanently in RPM_SUSPENDED
from the PM core's perspective? Should these initialization calls be moved
to gr3d_probe()?
> diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
> index 42e9656ab80c9..518bd21f52e2d 100644
> --- a/drivers/gpu/drm/tegra/gr3d.c
> +++ b/drivers/gpu/drm/tegra/gr3d.c
> @@ -524,6 +524,7 @@ static void gr3d_remove(struct platform_device *pdev)
> {
> struct gr3d *gr3d = platform_get_drvdata(pdev);
>
> + pm_runtime_dont_use_autosuspend(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> host1x_client_unregister(&gr3d->client.base);
> }
[Severity: Medium]
This is a pre-existing issue, but when CONFIG_PM is disabled, does
unconditionally assigning the dev_pm_ops structure create dead code?
drivers/gpu/drm/tegra/gr3d.c:tegra_gr3d_driver {
...
.pm = &tegra_gr3d_pm,
...
}
Should this use the pm_ptr() wrapper like .pm = pm_ptr(&tegra_gr3d_pm) to
ensure the callback functions do not get linked into the kernel when they can
never execute?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260808142217.2893936-1-lgs201920130244@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-08 14:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-08 14:22 [PATCH] drm/tegra: gr3d: fix autosuspend cleanup during teardown Guangshuo Li
2026-08-08 14:34 ` sashiko-bot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.