[PATCH] drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag

[PATCH] drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag

[Andy Yan]

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.

Signed-off-by: Andy Yan <andyshrk@163.com>
---

 drivers/gpu/drm/bridge/lontium-lt9611.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 0628d8e737ab..d916784af1ea 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -1149,9 +1149,8 @@ static int lt9611_probe(struct i2c_client *client)
 
 	lt9611->bridge.of_node = client->dev.of_node;
 	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;
+			     DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_HDMI |
+			     DRM_BRIDGE_OP_HDMI_AUDIO | DRM_BRIDGE_OP_HDMI_SPD_INFOFRAME;
 	lt9611->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 	lt9611->bridge.vendor = "Lontium";
 	lt9611->bridge.product = "LT9611";
-- 
2.43.0

base-commit: 310326bb7df4bba094a3fc60364c641c547fd923
branch: drm-misc-next

Claude review: drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag

[Claude Code Review Bot]

Overall Series Review

Subject: drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag
Author: Andy Yan <andyshrk@163.com>
Patches: 1
Reviewed: 2026-02-11T16:42:58.215535

---

This is a single-patch series that addresses a documentation compliance issue in the lt9611 DRM bridge driver. The patch removes the `DRM_BRIDGE_OP_MODES` flag from the bridge operations because the driver does not implement the required `get_modes` callback.

**Summary Assessment:**
- **Correctness**: The patch correctly identifies and fixes a flag/implementation mismatch
- **Scope**: Minimal, focused change affecting only the operations bitmask
- **Testing concern**: Needs verification that mode enumeration still works correctly through the EDID path
- **Commit message**: Clear and accurate

**Recommendation**: The patch is technically correct but requires runtime testing to ensure mode enumeration functionality is preserved through alternative mechanisms (EDID).

---
Generated by Claude Code Patch Reviewer

Claude review: drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag

[Claude Code Review Bot]

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