From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/bridge: Fix refcount shown via debugfs for encoder_bridges_show()
Date: Fri, 13 Mar 2026 14:28:01 +1000 [thread overview]
Message-ID: <review-patch1-20260312-drm-misc-next-2026-03-05-fix-encoder-bridges-refcount-v1-1-b9ba3d844732@nxp.com> (raw)
In-Reply-To: <20260312-drm-misc-next-2026-03-05-fix-encoder-bridges-refcount-v1-1-b9ba3d844732@nxp.com>
Patch Review
**Correctness: The fix is correct.** The `drm_for_each_bridge_in_chain_scoped()` macro (defined at `include/drm/drm_bridge.h:1490`) calls `drm_bridge_chain_get_first_bridge()` and `drm_bridge_get_next_bridge_and_put()`, holding an extra reference on the current bridge during each iteration. This inflates the `kref_read()` value by 1 in the debugfs output.
**Style nit — prefer `refcount - 1` over `--refcount`:**
```c
drm_printf(p, "\trefcount: %u%s\n",
scoped ? --refcount : refcount,
lingering ? " [lingering]" : "");
```
Using pre-decrement (`--refcount`) on a local variable is unnecessarily side-effectful. Since `refcount` is never used again, it works, but `refcount - 1` would be clearer and more idiomatic for a display-only adjustment.
**Over-engineering concern:** The patch adds 20+ lines (a `__` prefixed inner function, two wrappers, and a new `bool scoped` parameter) to fix a one-line display issue. A simpler approach would avoid the extra abstraction entirely. For example, `encoder_bridges_show()` could just call the existing function and the refcount adjustment could be handled more locally, or the original function could simply take the offset as a parameter:
```c
static void drm_bridge_debugfs_show_bridge(struct drm_printer *p,
struct drm_bridge *bridge,
unsigned int idx,
bool lingering,
unsigned int refcount_adj)
{
unsigned int refcount = kref_read(&bridge->refcount) - refcount_adj;
...
```
This avoids needing both a `__` function and two thin wrappers, and it's more transparent about what's happening (subtracting an adjustment rather than a boolean that means "subtract 1").
Alternatively, the simplest possible fix would be to just adjust the refcount inline in `encoder_bridges_show()` without changing the helper at all — though that would mean duplicating the format string.
**Conceptual question:** Debugfs is a debugging interface. Arguably, showing the *actual* refcount (including the iterator's reference) is the most truthful thing to do, and the "expected" value of 3 is a convention, not a contract. A comment in the output or in the code explaining the +1 from the scoped iterator might be more appropriate than silently adjusting the value. That said, consistency between `allbridges_show` and `encoder_bridges_show` for the same bridge is a reasonable goal, so the fix is defensible.
**Summary:** The fix is correct and addresses a real inconsistency. Recommend simplifying the implementation (drop the double-wrapper pattern, use `refcount - 1` instead of `--refcount`) before merging.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-03-13 4:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 6:05 [PATCH] drm/bridge: Fix refcount shown via debugfs for encoder_bridges_show() Liu Ying
2026-03-12 17:30 ` Luca Ceresoli
2026-03-13 4:28 ` Claude review: " Claude Code Review Bot
2026-03-13 4:28 ` 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-20260312-drm-misc-next-2026-03-05-fix-encoder-bridges-refcount-v1-1-b9ba3d844732@nxp.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