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: drm/scdc-helper: Add scdc_status debugfs entry
Date: Wed, 27 May 2026 15:01:44 +1000	[thread overview]
Message-ID: <review-patch2-20260526-scdc-link-health-v3-2-59e4a4aaead1@collabora.com> (raw)
In-Reply-To: <20260526-scdc-link-health-v3-2-59e4a4aaead1@collabora.com>

Patch Review

This is the core patch. Several observations:

**Bitfield portability (issue):** The `drm_scdc_status_flags` struct uses a union of `bool` bitfields with `u8 data`:

```c
union {
    struct {
        bool clock_detected : 1;
        bool ch0_locked : 1;
        bool ch1_locked : 1;
        bool ch2_locked : 1;
        ...
    } flags __packed;
    u8 data;
} status0;
```

Bitfield ordering within a storage unit is implementation-defined. GCC allocates from LSB on little-endian targets and from MSB on big-endian targets. On a big-endian system, `clock_detected` would map to bit 7, not bit 0 as the SCDC register defines (`SCDC_CLOCK_DETECT` = `(1 << 0)`). The kernel handles this elsewhere (e.g., `struct iphdr`) using `#if defined(__LITTLE_ENDIAN_BITFIELD)` / `#elif defined(__BIG_ENDIAN_BITFIELD)` guards. The DRM subsystem doesn't currently use this pattern (no hits in `include/drm/`), but these bitfields directly overlay a hardware register byte, which is where it matters. Consider using explicit bit masks and shifts instead, or adding endianness guards.

**Conditional reads from update flags (design concern):** In `drm_scdc_read_state`, status flags and error counters are only read when the corresponding update flags are set:

```c
if (upd_flags[0] & SCDC_STATUS_UPDATE) {
    ret = drm_scdc_read_status0_flags(connector, &state->stf);
    ...
}
if (upd_flags[0] & SCDC_CED_UPDATE) {
    ret = drm_scdc_read_error_counters(connector, state->error_count);
    ...
}
```

Since the state persists in `scdc_debugfs_priv`, on the first debugfs read (or if no updates have occurred), the status and error fields will be zero. Subsequent reads will show stale data from the last update. For a polling-oriented debugfs interface, always reading status flags (which have no side effects besides clearing the notification bit) would produce more useful output. Error counters have clear-on-read semantics so the conditional approach is more defensible there.

**Update flag clearing order:** `drm_scdc_read_status0_flags` clears the `SCDC_STATUS_UPDATE` flag *before* reading the status register. This is fine because status registers always reflect current state (they aren't latched on the update flag), but it differs from the typical spec-described flow of read-then-clear. Not a bug, just worth noting.

**Minor: doc typo in `drm_scdc_state`:**

```c
/** @scramling_enabled: true if TMDS scrambling is on */
```

Should be `@scrambling_enabled`.

**Connector refcounting:** The `scdc_status_show` function correctly releases the connector ref after `drm_scdc_read_state` and before printing the state (which only accesses the local state copy). This is fine.

**Exported symbols:** `drm_scdc_read_status0_flags`, `drm_scdc_read_error_counters`, and `drm_scdc_read_state` are all `EXPORT_SYMBOL`. If these are only used by the debugfs show function, they could remain static to avoid expanding the kernel symbol surface. If they're intended for future driver use, the exports are reasonable.

---
Generated by Claude Code Patch Reviewer

  parent reply	other threads:[~2026-05-27  5:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 10:19 [PATCH v3 0/4] Add SCDC information to connector debugfs Nicolas Frattaroli
2026-05-26 10:19 ` [PATCH v3 1/4] drm/scdc-helper: Don't use ssize_t return type for scdc_read/write Nicolas Frattaroli
2026-05-26 11:35   ` Luca Ceresoli
2026-05-27  5:01   ` Claude review: " Claude Code Review Bot
2026-05-26 10:19 ` [PATCH v3 2/4] drm/scdc-helper: Add scdc_status debugfs entry Nicolas Frattaroli
2026-05-26 10:48   ` Jani Nikula
2026-05-27  5:01   ` Claude Code Review Bot [this message]
2026-05-26 10:19 ` [PATCH v3 3/4] drm/display: bridge_connector: init scdc debugfs for HDMI Nicolas Frattaroli
2026-05-27  5:01   ` Claude review: " Claude Code Review Bot
2026-05-26 10:20 ` [PATCH v3 4/4] drm/scdc-helper: Implement parsing and printing HDMI 2.1 fields Nicolas Frattaroli
2026-05-26 10:52   ` Jani Nikula
2026-05-26 12:25     ` Nicolas Frattaroli
2026-05-26 13:56       ` Jani Nikula
2026-05-27  5:01   ` Claude review: " Claude Code Review Bot
2026-05-27  5:01 ` Claude review: Add SCDC information to connector debugfs Claude Code Review Bot
  -- strict thread matches above, loose matches on Subject: below --
2026-05-27 14:03 [PATCH v4 0/4] " Nicolas Frattaroli
2026-05-27 14:03 ` [PATCH v4 2/4] drm/scdc-helper: Add scdc_status debugfs entry Nicolas Frattaroli
2026-05-28  2:16   ` Claude review: " Claude Code Review Bot
2026-05-20 13:35 [PATCH v2 0/3] Add SCDC information to connector debugfs Nicolas Frattaroli
2026-05-20 13:35 ` [PATCH v2 1/3] drm/scdc-helper: Add scdc_status debugfs entry Nicolas Frattaroli
2026-05-25 11:49   ` 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-patch2-20260526-scdc-link-health-v3-2-59e4a4aaead1@collabora.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