From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/bridge: fsl-ldb: support downstream bridges in addition to panels
Date: Sun, 12 Apr 2026 12:59:08 +1000 [thread overview]
Message-ID: <review-patch1-20260408072802.3947600-1-xiaolei.wang@windriver.com> (raw)
In-Reply-To: <20260408072802.3947600-1-xiaolei.wang@windriver.com>
Patch Review
**Correctness: Good**
The core logic is correct. `devm_drm_of_get_bridge()` internally calls `drm_of_find_panel_or_bridge()`, and if a panel is found, wraps it with `devm_drm_panel_bridge_add()` — so existing panel-only device trees continue to work unchanged. If a bridge is found, it's returned directly. Either way the result is a `struct drm_bridge *`, which is exactly what `fsl_ldb->panel_bridge` stores and what `fsl_ldb_attach()` passes to `drm_bridge_attach()`.
**Port selection logic: Correct**
```c
fsl_ldb->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
fsl_ldb->ch0_enabled ? 1 : 2, 0);
```
This correctly mirrors the original logic:
```c
panel_node = of_node_get(remote1 ? remote1 : remote2);
```
where `remote1` is from port 1 and `remote2` is from port 2. In the dual-link case (both channels enabled), both ports connect to the same downstream device, so picking port 1 is correct.
**Nit 1: Stale error message**
```c
if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
return dev_err_probe(dev, -ENXIO, "No panel node found");
```
Since the driver now supports bridges too, this message should say something like `"No panel or bridge node found"` or simply `"No remote node found"`.
**Nit 2: Unused include**
After this patch, nothing in the file uses `struct drm_panel`, `of_drm_find_panel()`, or any other symbol from `<drm/drm_panel.h>`. The include at the top of the file could be dropped since `devm_drm_of_get_bridge()` is declared in `<drm/drm_bridge.h>` (already included).
**Nit 3: Needs rebase**
The patch is based on tree state `5c3cf37200bc`, but current drm-next has additional code between the removed `of_node_put(panel_node)` and `devm_drm_panel_bridge_add()` calls — specifically the `nxp,enable-termination-resistor` property check at `fsl-ldb.c:347-348`. The patch will need a trivial rebase to resolve this context conflict. The `nxp,enable-termination-resistor` block should remain in place after the rebase.
**Non-issue (for context):** The struct member `panel_bridge` is now slightly misnamed since it can hold a non-panel bridge, but renaming it would be gratuitous churn and is fine to leave.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-04-12 2:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 7:28 [PATCH] drm/bridge: fsl-ldb: support downstream bridges in addition to panels Xiaolei Wang
2026-04-12 2:59 ` Claude review: " Claude Code Review Bot
2026-04-12 2:59 ` Claude Code Review Bot [this message]
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-20260408072802.3947600-1-xiaolei.wang@windriver.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