[PATCH] drm/amd/display: Fix a benign uninitialized variable warning

[PATCH] drm/amd/display: Fix a benign uninitialized variable warning

[Calvin Owens]

This warning shows up with GCC at W=2:

    drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:3229:32: warning: ‘r’ may be used uninitialized [-Wmaybe-uninitialized]
     3229 |                         return r;
          |                                ^
    drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:3133:13: note: ‘r’ was declared here
     3133 |         int r;
          |             ^

The compiler can't know drm_atomic_helper_suspend() doesn't return NULL,
so GCC is technically correct, that case would return `r` uninitialized.

Fix the warning by using PTR_ERR_OR_ZERO() on the return value from
drm_atomic_helper_suspend() like i915 does.

Signed-off-by: Calvin Owens <calvin@wbinvd.org>
---
This is pretty nitpicky and obviously benign IMO, I just happened to
spot it while debugging [1]. No argument from me if you don't want it :)

[1] https://lore.kernel.org/lkml/ef7266eb7802ce6d68ebd9356477e9671f0c94e0.1773116305.git.calvin@wbinvd.org/#t

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b3d6f2cd8ab6..9c5dce8d38b6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3133,12 +3133,11 @@ static int dm_cache_state(struct amdgpu_device *adev)
 	int r;
 
 	adev->dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev));
-	if (IS_ERR(adev->dm.cached_state)) {
-		r = PTR_ERR(adev->dm.cached_state);
+	r = PTR_ERR_OR_ZERO(adev->dm.cached_state);
+	if (r)
 		adev->dm.cached_state = NULL;
-	}
 
-	return adev->dm.cached_state ? 0 : r;
+	return r;
 }
 
 static void dm_destroy_cached_state(struct amdgpu_device *adev)
-- 
2.47.3

Claude review: drm/amd/display: Fix a benign uninitialized variable warning

[Claude Code Review Bot]

Patch Review

**Status: Looks good**

The original code was:

```c
adev->dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev));
if (IS_ERR(adev->dm.cached_state)) {
    r = PTR_ERR(adev->dm.cached_state);
    adev->dm.cached_state = NULL;
}

return adev->dm.cached_state ? 0 : r;
```

GCC correctly identifies that if `drm_atomic_helper_suspend()` returns a valid (non-NULL, non-ERR) pointer, the `IS_ERR` branch is not taken and `r` remains uninitialized — yet the final `return` expression `adev->dm.cached_state ? 0 : r` would use `r` if `cached_state` were NULL. In practice this path is unreachable (a valid pointer is not NULL), but the compiler can't prove that.

The fix replaces this with:

```c
r = PTR_ERR_OR_ZERO(adev->dm.cached_state);
if (r)
    adev->dm.cached_state = NULL;

return r;
```

This is logically equivalent and cleaner:
- `PTR_ERR_OR_ZERO()` returns 0 for valid pointers and the error code for `IS_ERR` pointers, so `r` is always initialized.
- The `if (r)` branch correctly NULLs out the cached state on error.
- `return r` returns 0 on success, the negative error code on failure — same behavior as before.

**Minor observations:**
- The commit message is well-written and honest about the cosmetic nature of the fix.
- The `int r` declaration could now be combined with initialization (`int r = PTR_ERR_OR_ZERO(...)`) to further simplify, but keeping the declaration separate is fine and matches kernel style in this file.
- No functional change, no risk of regression.

**Reviewed-by worthy.**

---
Generated by Claude Code Patch Reviewer

Claude review: drm/amd/display: Fix a benign uninitialized variable warning

[Claude Code Review Bot]

Overall Series Review

Subject: drm/amd/display: Fix a benign uninitialized variable warning
Author: Calvin Owens <calvin@wbinvd.org>
Patches: 1
Reviewed: 2026-03-11T13:10:19.674718

---

This is a single, simple patch that fixes a GCC `-Wmaybe-uninitialized` warning (visible at `W=2`) in `dm_cache_state()`. The fix is correct, clean, and well-motivated.

**Verdict: Good to merge.**

---
Generated by Claude Code Patch Reviewer