From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: clk: qcom: common: ensure runtime PM suspend completes on probe Date: Tue, 28 Apr 2026 15:05:23 +1000 Message-ID: In-Reply-To: <20260427-gfx-clk-fixes-v2-3-797e54b3d464@oss.qualcomm.com> References: <20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com> <20260427-gfx-clk-fixes-v2-3-797e54b3d464@oss.qualcomm.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Author:** Taniya Das ```c - pm_runtime_put(dev); + pm_runtime_put_sync(dev); ``` The commit message has a minor formatting artifact: `"putV` appears to be a copy-paste error for `"put"`. Otherwise the change is straightforward and the rationale is sound -- the async `pm_runtime_put()` can race with a subsequent `pm_runtime_disable()` called by the gxclkctl probe in patch 4. **Minor concern:** This is a generic change to `qcom_cc_really_probe()` which affects all Qualcomm clock controllers using `use_rpm`, not just gxclkctl. The commit message says "This does not have any functional impact" but `pm_runtime_put_sync()` will block in probe, which could add latency for all qcom clock controllers. This deserves a comment from the clock maintainers about whether the broader impact is acceptable, or whether this change should be scoped to gxclkctl only. Note also that `put_rpm:` is used for both the success path and the error path. On the error path, synchronous completion may not matter. On the success path for other clock controllers, blocking unnecessarily could delay boot. --- --- Generated by Claude Code Patch Reviewer