Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Handling `nwl_dsi_mode_set()` error by jumping to `runtime_put` causes a `pm_runtime` usage counter underflow. --
--- Patch [4]: [PATCH v2 4/4] drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set() --- commit 7d9af739876057a4f21f4e98151a3fe153456a02 Author: Esben Haabendal <[email protected]> drm/bridge: nwl-dsi: Add error handling of nwl_dsi_mode_set() This commit introduces error handling for nwl_dsi_mode_set() in nwl_dsi_bridge_mode_set(). If the function fails, it jumps to the runtime_put label to release the PM runtime reference. > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c > b/drivers/gpu/drm/bridge/nwl-dsi.c > index 226036d22e3f8..08e87d166b17a 100644 > --- a/drivers/gpu/drm/bridge/nwl-dsi.c > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c > @@ -942,7 +942,9 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge, > } > > /* Step 2 from DSI reset-out instructions */ > - nwl_dsi_mode_set(dsi); > + ret = nwl_dsi_mode_set(dsi); > + if (ret < 0) > + goto runtime_put; [Severity: Medium] Since nwl_dsi_bridge_mode_set() returns void, does the DRM core know that this setup failed? If the DRM core continues treating the bridge as active, it will unconditionally call nwl_dsi_bridge_atomic_disable() during teardown, which also drops the reference: drivers/gpu/drm/bridge/nwl-dsi.c:nwl_dsi_bridge_atomic_disable() { ... pm_runtime_put(dsi->dev); ... } Could this double-put cause a pm_runtime usage counter underflow, since we already dropped the reference in this new error path? > > /* Step 3 from DSI reset-out instructions */ > ret = reset_control_deassert(dsi->rst_esc); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
