From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag
Date: Wed, 11 Feb 2026 16:42:58 +1000
Message-ID: <review-patch1-20260210070821.570062-1-andyshrk@163.com>
In-Reply-To: <20260210070821.570062-1-andyshrk@163.com>
References: <20260210070821.570062-1-andyshrk@163.com> <20260210070821.570062-1-andyshrk@163.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: Claude Code Patch Reviewer

Patch Review

**Commit Message Review:**

The commit message correctly identifies the issue:
```
According to the documentation: Bridges that set this flag shall
implement the &drm_bridge_funcs->get_modes callback.

But the lt9611 driver does not implement the get_modes callback,
so remove this flag.
```

This is accurate and follows the kernel commit message style. The reasoning is sound.

**Code Review:**

```c
-	lt9611->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
-			     DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_MODES |
-			     DRM_BRIDGE_OP_HDMI | DRM_BRIDGE_OP_HDMI_AUDIO |
-			     DRM_BRIDGE_OP_HDMI_SPD_INFOFRAME;
+	lt9611->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
+			     DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_HDMI |
+			     DRM_BRIDGE_OP_HDMI_AUDIO | DRM_BRIDGE_OP_HDMI_SPD_INFOFRAME;
```

**Positive aspects:**
1. The change correctly removes `DRM_BRIDGE_OP_MODES` from the operations bitmask
2. Reformatting is clean and maintains readability
3. The driver retains `DRM_BRIDGE_OP_EDID`, which is the standard mechanism for mode enumeration

**Technical considerations:**

1. **Mode enumeration path**: The driver sets `DRM_BRIDGE_OP_EDID`, which means it should rely on the DRM core's EDID-based mode enumeration through `drm_bridge_edid_read()`. This is the standard path for HDMI bridges that read EDID.

2. **Functionality preservation**: The change should not affect functionality because:
   - The driver never implemented `get_modes` callback
   - Mode enumeration will continue through the EDID path
   - The flag was misleading documentation/API compliance issue

3. **Consistency check**: The driver implements:
   - `lt9611_bridge_detect()` (for DETECT flag) ✓
   - `lt9611_bridge_edid_read()` (for EDID flag) ✓  
   - HPD support via `lt9611_hpd_work()` (for HPD flag) ✓
   - No `get_modes` implementation (MODES flag was incorrect) ✓

**Questions/Concerns:**

1. **Testing**: Has this been tested to ensure mode enumeration still works correctly? The EDID path should handle this, but runtime verification would be valuable.

2. **Other lt9611 variants**: There's also a lt9611uxc driver (`lontium-lt9611uxc.c`). Should that driver be checked for the same issue?

**Minor observation:**

The reformatting of the multi-line statement is slightly different (bringing `DRM_BRIDGE_OP_HPD` to the same line as `EDID`), but this is a cosmetic improvement that maintains proper alignment.

**Verdict:**

**Reviewed-by**: The patch is technically correct and fixes a real documentation/API compliance issue.

**Tested-by**: Would appreciate confirmation that mode enumeration works correctly after this change (though theoretically it should work via EDID path).

**Suggested follow-up**: Check if `lontium-lt9611uxc.c` has the same issue.

---
Generated by Claude Code Patch Reviewer