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: 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

      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