From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: accel/amdxdna: Add IOCTL to retrieve realtime NPU power estimate
Date: Tue, 03 Mar 2026 14:37:39 +1000 [thread overview]
Message-ID: <review-patch1-20260228061109.361239-2-superm1@kernel.org> (raw)
In-Reply-To: <20260228061109.361239-2-superm1@kernel.org>
Patch Review
**Commit message nit**: The line `(Update comment to indicate power and utilization)` between the Reviewed-by tags and the Signed-off-by is unusual. This annotation should go below the `---` separator or in the cover letter, not in the permanent commit message area.
**`AIE2_GET_PMF_NPU_DATA` macro — dead assignment on error** (`aie2_pci.h`):
```c
#define AIE2_GET_PMF_NPU_DATA(field, val) \
({ \
struct amd_pmf_npu_metrics _npu_metrics; \
int _ret; \
\
_ret = amd_pmf_get_npu_data(&_npu_metrics); \
val = _ret ? U32_MAX : _npu_metrics.field; \
(_ret); \
})
```
When `_ret` is non-zero, `val` is set to `U32_MAX`, but the caller immediately returns:
```c
ret = AIE2_GET_PMF_NPU_DATA(npu_power, sensor.input);
if (ret)
return ret;
```
So the `U32_MAX` assignment is dead code. This is harmless but the macro design is misleading — it suggests the caller might continue with a fallback value.
**`#else` stub — fragile naming convention** (`aie2_pci.h`):
```c
#define SENSOR_DEFAULT_npu_power U32_MAX
#define AIE2_GET_PMF_NPU_DATA(field, val) \
({ \
val = SENSOR_DEFAULT_##field; \
(-EOPNOTSUPP); \
})
```
The token-pasting `SENSOR_DEFAULT_##field` requires a matching `#define` for every field name used. Currently only `npu_power` has one. This is brittle and the whole construct is unnecessary since the macro always returns `-EOPNOTSUPP` and the caller returns immediately on error — the value assigned to `val` is never used. This could be simplified to just:
```c
#define AIE2_GET_PMF_NPU_DATA(field, val) (-EOPNOTSUPP)
```
**`unitm` / `units` inconsistency** (`aie2_pci.c`):
```c
sensor.unitm = -3;
scnprintf(sensor.units, sizeof(sensor.units), "mW");
```
Per the UAPI documentation: `unitm` translates values via `pow(10, unitm) * value`. The PMF struct has `u16 npu_power`. If the raw value is already in milliwatts, then `unitm` should be `0` and `units = "mW"`, or `unitm = -3` and `units = "W"`. Having `unitm = -3` with `units = "mW"` means userspace would compute `pow(10, -3) * value` in milliwatts, yielding microwatts — likely not the intent. Please clarify which is correct.
**Missing `buffer_size` check parity with other handlers**: `aie2_get_clock_metadata()` doesn't validate `buffer_size` before `copy_to_user` — it just copies. Here `aie2_get_sensors()` does validate. Inconsistent, but the validation here is the right thing to do; just noting the discrepancy.
**No `#include <linux/limits.h>` justification**: The patch adds `#include <linux/limits.h>` to `aie2_pci.h`, presumably for `U32_MAX`, but `U32_MAX` is defined in `<linux/limits.h>` only indirectly. It's actually in `<linux/types.h>` or `<linux/kernel.h>` which are likely already pulled in. Minor, but worth verifying the include is actually needed.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-03-03 4:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 6:10 [PATCH 0/2] Add some sensor data to amdxdna Mario Limonciello (AMD)
2026-02-28 6:10 ` [PATCH 1/2] accel/amdxdna: Add IOCTL to retrieve realtime NPU power estimate Mario Limonciello (AMD)
2026-03-03 4:37 ` Claude Code Review Bot [this message]
2026-02-28 6:10 ` [PATCH 2/2] accel/amdxdna: Support sensors for column utilization Mario Limonciello (AMD)
2026-02-28 19:56 ` Lizhi Hou
2026-03-03 4:37 ` Claude review: " Claude Code Review Bot
2026-03-03 4:37 ` Claude review: Add some sensor data to amdxdna 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-20260228061109.361239-2-superm1@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