public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/sysfb: Fix efidrm error handling and memory type mismatch
Date: Thu, 12 Mar 2026 07:16:10 +1000	[thread overview]
Message-ID: <review-patch1-20260311064652.2903449-1-nichen@iscas.ac.cn> (raw)
In-Reply-To: <20260311064652.2903449-1-nichen@iscas.ac.cn>

Patch Review

**Correctness of the fix:**

The restructuring is sound. Each branch now:
- Declares `screen_base` with the correct type (`void __iomem *` for WC/UC, `void *` for WT/WB)
- Uses the correct error check (`!screen_base` for `devm_ioremap*()` which returns NULL on failure, `IS_ERR()` for `devm_memremap()` which returns ERR_PTR)
- Calls the correct `iosys_map` setter (`iosys_map_set_vaddr_iomem` for iomem, `iosys_map_set_vaddr` for system memory)

**Minor issues:**

1. **Error code change for WC/UC paths**: The original code returned `-ENOMEM` when `devm_ioremap*()` failed. The patch changes this to `-ENXIO`:
```c
+		if (!screen_base)
+			return ERR_PTR(-ENXIO);
```
This is arguably fine (`-ENXIO` = "no such device or address" is reasonable for a failed ioremap), but the commit message doesn't mention or justify this change. `-ENOMEM` was also defensible since `ioremap` failures are typically due to resource exhaustion. This is a minor nit — either error code is acceptable.

2. **Missing `else` fall-through error for invalid `mem_flags`**: In the original code, when `mem_flags` matched none of the branches, it printed an error but then fell through to `if (!screen_base)` which returned `-ENOMEM`. The patch now explicitly returns `-EINVAL` for this case:
```c
+	} else {
+ 		drm_err(dev, "invalid mem_flags: 0x%llx\n", mem_flags);
+		return ERR_PTR(-EINVAL);
+	}
```
This is a good improvement — the error code is now more meaningful and the flow is explicit.

3. **Code duplication**: The WC and UC branches are nearly identical, as are the WT and WB branches. This could be slightly reduced, but given the small number of lines and clarity of the current structure, it's acceptable.

**Commit message quality**: The commit message clearly explains both bugs and the fix approach. The `Fixes:` tag is present and correct.

**Overall**: This is a correct and well-structured fix for real bugs. The patch looks good to merge. The only suggestion would be to briefly note in the commit message why `-ENXIO` was chosen over `-ENOMEM` for the ioremap failure paths, or simply keep `-ENOMEM` to minimize the behavioral change.

---
Generated by Claude Code Patch Reviewer

  parent reply	other threads:[~2026-03-11 21:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11  6:46 [PATCH v2] drm/sysfb: Fix efidrm error handling and memory type mismatch Chen Ni
2026-03-11  7:44 ` Thomas Zimmermann
2026-03-11 21:16 ` Claude Code Review Bot [this message]
2026-03-11 21:16 ` Claude review: " Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch1-20260311064652.2903449-1-nichen@iscas.ac.cn \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox