From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example Date: Wed, 04 Mar 2026 07:36:19 +1000 Message-ID: In-Reply-To: <20260303-v6-18-topic-imx93-parallel-display-v11-1-1b03733c8461@pengutronix.de> References: <20260303-v6-18-topic-imx93-parallel-display-v11-0-1b03733c8461@pengutronix.de> <20260303-v6-18-topic-imx93-parallel-display-v11-1-1b03733c8461@pengutronix.de> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review This patch adds the `dpi-bridge` subnode schema and a binding example. **Observations:** The binding looks well-structured. It properly references `graph.yaml` and `video-interfaces.yaml` for ports and endpoint properties. The `bus-width` enum restricts to valid values `[16, 18, 24]` and the documentation explains the truncation behavior clearly. One minor question: the binding defines both `nxp,imx91-pdfc` and `nxp,imx93-pdfc` as compatible strings, but the driver (patch 2) only matches `nxp,imx93-pdfc`. The DTS (patch 3) uses `nxp,imx93-pdfc` in the common dtsi for both SoCs. If the imx91 compatible is intended for future use, that's fine, but if someone were to use `nxp,imx91-pdfc` in a device tree today, the driver would not probe. It would be cleaner to either add `nxp,imx91-pdfc` to the driver's `of_device_id` table now, or document that imx91 should use a fallback compatible pair. No issues with the binding schema itself. --- Generated by Claude Code Patch Reviewer