From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used
Date: Wed, 11 Feb 2026 17:06:48 +1000 [thread overview]
Message-ID: <review-patch1-20260209122714.1037915-10-sashal@kernel.org> (raw)
In-Reply-To: <20260209122714.1037915-10-sashal@kernel.org>
Patch Review
**Commit Metadata:**
- Author: Brahmajit Das <listout@listout.xyz>
- Upstream: 1beee8d0c263b3e239c8d6616e4f8bb700bed658
- Maintainer: Thierry Reding (NVIDIA)
- Target: Stable backport to 6.18-5.10
**Commit Message Review:**
The commit message is functional but has issues:
```
The variable j is set, however never used in or outside the loop, thus
resulting in dead code.
Building with GCC 16 results in a build error due to
-Werror=unused-but-set-variable= enabled by default.
This patch clean up the dead code and fixes the build error.
```
Issues:
- Grammar: "This patch clean up" should be "This patch cleans up"
- The message doesn't explain WHY `j` existed or whether this reveals a bug
- Contains "LLM Generated explanations" section (lines 92-195) which is highly unusual for kernel patches and should not be in the commit
**Code Review:**
**File 1: drivers/gpu/drm/tegra/hdmi.c**
Original code:
```c
size_t i, j;
...
for (i = 3, j = 0; i < size; i += 7, j += 8) {
```
Modified code:
```c
size_t i;
...
for (i = 3; i < size; i += 7) {
```
**Analysis:**
- Loop processes data in 7-byte chunks (i += 7)
- Variable `j` was incrementing by 8 (j += 8) - one byte more than the chunk size
- The comment at hdmi.c:686-692 explains the data packing format but doesn't mention why chunks are 7 bytes
**Concern:** The mismatch between incrementing by 7 (bytes) and incrementing by 8 (potentially bits * byte?) suggests `j` might have been intended for bit offset tracking but was never completed. This could indicate:
1. Dead code from refactoring
2. Incomplete implementation
3. Copy-paste error
**File 2: drivers/gpu/drm/tegra/sor.c**
Identical changes to hdmi.c:
```c
size_t i, j;
...
for (i = 3, j = 0; i < size; i += 7, j += 8) {
```
Changed to:
```c
size_t i;
...
for (i = 3; i < size; i += 7) {
```
**Same concern applies** - the code appears to be duplicated between hdmi.c and sor.c with the same potential issue.
**Technical Issues:**
1. **Code Duplication:** The functions `tegra_hdmi_write_infopack()` and `tegra_sor_hdmi_write_infopack()` appear to have identical logic. This duplication should be refactored into a common helper function.
2. **Missing Investigation:** The patch doesn't explain:
- When was `j` last used (if ever)?
- Was this a regression or always dead code?
- Does the infopack packing work correctly without this variable?
3. **Build vs Runtime:** While this fixes the build, we should verify:
- Are HDMI infopacks being written correctly?
- Should there be any validation that doesn't happen now?
**Positive Aspects:**
1. **Obviously Safe:** Removing truly unused variables cannot introduce runtime bugs
2. **Fixes Real Problem:** GCC 16 build breakage is legitimate
3. **Proper Signoff Chain:** Has author SoB and maintainer SoB
4. **Targeted:** Changes only what's necessary
**Questions for Maintainer:**
1. Can you verify HDMI infopack transmission works correctly on affected hardware?
2. Was `j` intended for debugging/validation that was never implemented?
3. Should these two functions be consolidated into shared code?
4. Why is there "LLM Generated explanations" in the commit message?
**Verdict:**
**Acked-by conditionally** - The code change is correct for fixing the build, but:
- The commit message should be cleaned up (remove LLM section, fix grammar)
- Investigation should be done into whether the original code was incomplete
- Consider filing a follow-up to deduplicate the hdmi.c and sor.c functions
**Risk Assessment:** Low risk for stable backport - this is purely removing dead code.
**Testing Recommendation:** Verify HDMI output on Tegra platforms (ideally Jetson boards) to ensure infopack handling remains correct.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-02-11 7:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260209122714.1037915-1-sashal@kernel.org>
2026-02-09 12:26 ` [PATCH AUTOSEL 6.18-5.10] drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used Sasha Levin
2026-02-11 7:06 ` Claude Code Review Bot [this message]
2026-02-11 7:06 ` 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-20260209122714.1037915-10-sashal@kernel.org \
--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