From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: video/fbdev/via: check ioremap return value in viafb_lcd_get_mobile_state
Date: Wed, 11 Mar 2026 13:49:46 +1000 [thread overview]
Message-ID: <review-patch1-tencent_5706A404B952870FEAC83A04EEFC8348A305@qq.com> (raw)
In-Reply-To: <tencent_5706A404B952870FEAC83A04EEFC8348A305@qq.com>
Patch Review
**The bug is real.** At `lcd.c:956`, `ioremap()` is called and the result is used immediately at line 957 via `readw(biosptr)` without any NULL check. If `ioremap()` fails, this would cause a NULL pointer dereference.
**Issues:**
1. **Commit message says `-ENOMEM` but the code returns `false`.** The commit message states:
> This patch adds a proper NULL check after ioremap() and returns -ENOMEM in case of failure.
But the actual code returns `false`, which is consistent with the function's `bool` return type. The commit message is wrong and should be corrected to say it returns `false`.
2. **DEBUG_MSG format string has a leading space:**
```c
DEBUG_MSG(KERN_ERR " Failed to remap BIOS memory\n");
```
The space after `KERN_ERR` before `"Failed"` looks like a typo. It should be:
```c
DEBUG_MSG(KERN_ERR "Failed to remap BIOS memory\n");
```
3. **Use of `DEBUG_MSG` with `KERN_ERR`:** Looking at existing error paths in this function, neither of the existing `return false` paths (line 988) logs anything. Using `DEBUG_MSG` (which is typically compiled out) with `KERN_ERR` is a bit contradictory — if this is truly an error worth reporting, `pr_err()` would be more appropriate and wouldn't be compiled away. That said, using the existing codebase conventions is also reasonable; the author should clarify intent.
4. **Minor: the `*mobile` output parameter is left uninitialized on the error path.** This matches the existing behavior when the BIOS signature doesn't match (the `else` branch at line 986-988 also returns `false` without setting `*mobile`), so this is a pre-existing issue, not something this patch introduces.
**The fix itself is correct in substance** — the NULL check is placed in the right location, the return value is appropriate for the function signature, and the existing `iounmap()` calls in later paths don't need adjustment since we never successfully mapped in this error case.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-03-11 3:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 1:14 [PATCH] video/fbdev/via: check ioremap return value in viafb_lcd_get_mobile_state Wang Jun
2026-03-10 16:36 ` Helge Deller
2026-03-11 3:49 ` Claude review: " Claude Code Review Bot
2026-03-11 3:49 ` Claude Code Review Bot [this message]
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-tencent_5706A404B952870FEAC83A04EEFC8348A305@qq.com \
--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