From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/msm/adreno: Coredump on GPU/GMU init failures
Date: Wed, 25 Mar 2026 07:32:09 +1000
Message-ID: <review-patch5-20260324-a8xx-gpu-batch2-v1-5-fc95b8d9c017@oss.qualcomm.com>
In-Reply-To: <20260324-a8xx-gpu-batch2-v1-5-fc95b8d9c017@oss.qualcomm.com>
References: <20260324-a8xx-gpu-batch2-v1-0-fc95b8d9c017@oss.qualcomm.com> <20260324-a8xx-gpu-batch2-v1-5-fc95b8d9c017@oss.qualcomm.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Locking concern in `adreno_load_gpu()`**: The mutex_lock is moved before =
`pm_runtime_get_sync()` and the unlock is split into two paths. Looking at =
the error path:
```c
err_put_rpm:
    pm_runtime_put_sync_suspend(&pdev->dev);
err_disable_rpm:
    pm_runtime_disable(&pdev->dev);
    mutex_unlock(&gpu->lock);
    return NULL;
```
If `pm_runtime_get_sync()` fails, we jump to `err_disable_rpm` where `mutex=
_unlock` is called =E2=80=94 this is correct. If `msm_gpu_hw_init()` fails,=
 we jump to `err_put_rpm` which falls through to `err_disable_rpm` and also=
 unlocks =E2=80=94 also correct. The success path unlocks after `pm_runtime=
_put_autosuspend`. So the locking looks correct on all paths.

**Concern in `adreno_gpu.c`**: Adding `mutex_lock(&gpu->lock)` around the `=
MSM_PARAM_TIMESTAMP` path in `adreno_get_param()` =E2=80=94 this may introd=
uce lock ordering issues if callers already hold locks. This should be docu=
mented or verified against all call sites.

**In `msm_gpu.c`**: Calling `msm_gpu_crashstate_capture()` from `msm_gpu_su=
bmit()` when `msm_gpu_hw_init()` fails =E2=80=94 is `gpu->lock` held here? =
The submit path typically holds `gpu->lock`, so this should be fine for the=
 crashstate_capture assertion.

---
Generated by Claude Code Patch Reviewer