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: Re: [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg
Date: Fri, 13 Mar 2026 14:18:06 +1000	[thread overview]
Message-ID: <review-patch1-abLGKjvKMorbb3Vb@stanley.mountain> (raw)
In-Reply-To: <abLGKjvKMorbb3Vb@stanley.mountain>

Patch Review

**Correctness**: The patch is functionally correct. Where `modifier` was empty, the macro expansion `modifier((data_type)va_arg(...))` would produce `((data_type)va_arg(...))` — just the expression in parentheses. With `fbtft_identity`, it produces `(((data_type)va_arg(...)))` — an extra layer of parentheses that has no semantic effect.

**Issue 1: Blank line removal**

The patch removes the blank line between the `EXPORT_SYMBOL(func);` end of the macro definition and the first invocation:

```c
-
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+#define fbtft_identity(x) (x)
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_identity)
```

The `#define` is jammed right up against the end of the preceding macro. It would be cleaner to keep a blank line separator before the new `#define`, improving readability:

```c
EXPORT_SYMBOL(func);

#define fbtft_identity(x) (x)
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_identity)
```

**Issue 2: Naming and scope**

`fbtft_identity` is defined in a `.c` file and used only locally, so the scope is fine. However, the name `fbtft_identity` is a bit unusual. A more conventional kernel approach might be to check if there's already a no-op/identity macro available, or to name it something more descriptive like `fbtft_noop_modifier`. This is minor and stylistic.

**Issue 3: Commit message**

The commit message says "This fixes the error reported by scripts/checkpatch.pl" but doesn't quote the actual checkpatch warning. It would be better practice to include the specific warning text so reviewers can evaluate whether this is the right fix. For staging code especially, checkpatch fixes are common and welcome, but stating the exact warning is standard practice.

**Overall**: The patch is a straightforward, correct cleanup. The suggestions above are minor. It could also be worth checking if a series-wide cleanup of this file is planned (since this is staging code), but as a standalone fix it's fine.

---
Generated by Claude Code Patch Reviewer

  reply	other threads:[~2026-03-13  4:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-12 11:18 [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg Zile Xiong
2026-03-12 13:56 ` Dan Carpenter
2026-03-13  4:18   ` Claude Code Review Bot [this message]
2026-03-13  4:18   ` 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-abLGKjvKMorbb3Vb@stanley.mountain \
    --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