Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] drm/bridge: runtime PM usage counter underflow on atomic_enable error --
commit f6da183dff281321349d56635d572cdbbecf6393 Author: Wentao Liang <[email protected]> drm/bridge: microchip-lvds: Fix runtime PM leak in mchp_lvds_enable() This patch attempts to fix a runtime PM usage counter leak in mchp_lvds_atomic_enable() by dropping the reference when pm_runtime_get_sync() fails. > diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c > b/drivers/gpu/drm/bridge/microchip-lvds.c > index dd4ffc9f4df3f..f30ebeea4a4da 100644 > --- a/drivers/gpu/drm/bridge/microchip-lvds.c > +++ b/drivers/gpu/drm/bridge/microchip-lvds.c > @@ -144,6 +144,7 @@ static void mchp_lvds_atomic_enable(struct drm_bridge > *bridge, > ret = pm_runtime_get_sync(lvds->dev); > if (ret < 0) { > dev_err(lvds->dev, "failed to get pm runtime: %d\n", ret); > + pm_runtime_put_noidle(lvds->dev); [Severity: Medium] Will this lead to a runtime PM usage counter underflow when the bridge is disabled? The DRM bridge API's atomic_enable callback returns void, so the DRM core cannot be notified of a failure. If pm_runtime_get_sync() fails, the DRM core still considers the bridge enabled and will unconditionally call mchp_lvds_atomic_disable() during the next modeset or pipeline teardown. Since this patch locally drops the PM reference here on the error path, the unconditional pm_runtime_put() in mchp_lvds_atomic_disable() will decrement the usage count a second time, causing an underflow. Before this patch, the reference left by the failing get_sync() balanced the unconditional put in the disable path. > return; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
