Re: [PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The LVDS bridge device tree node uses an unsupported `compatible` string (`"lontium,lt9211c"`), which will prevent the driver from matching and probing, and lacks a fallback compatible string.
- [Low] The compatible strings `"lontium,lt9211c"` and `"boe,dv215fhm-r01"` are used but not documented in any device tree bindings schema.
- [Low] The `panel-lvds` node defines multiple ports inside a `ports` container, violating the `panel-lvds` DT binding schema.
--

--- Patch [3]: [PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay ---
commit 8bcbc23969051c16954909a078c84444cd4362af
Author: Vishnu Saini <vishnu.saini@oss.qualcomm.com>

arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay

This commit adds a DTBO overlay for the QCS6490 RB3 Gen2 industrial mezzanine
to support LVDS display output via the Lontium LT9211C DSI-to-LVDS bridge.
It wires up the LT9211C bridge on I2C1 and adds a dual-channel panel-lvds node.

> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
> new file mode 100644
> index 0000000000000..65af688503429
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
> @@ -0,0 +1,110 @@
[ ... ]
> +	hdmi-connector {
> +		status = "disabled";
> +	};
> +
> +	panel_lvds: panel-lvds {
> +		compatible = "boe,dv215fhm-r01", "panel-lvds";

[Severity: Low]
Are these compatible strings documented in the device tree bindings?

A search of the tree reveals no schema definitions for boe,dv215fhm-r01
in the panel bindings. This will cause make dtbs_check validation to fail.

> +		data-mapping = "vesa-24";
> +		width-mm = <476>;
> +		height-mm = <268>;
> +
> +		status = "okay";
[ ... ]
> +		panel-timing {
> +			clock-frequency = <148500000>;
[ ... ]
> +			de-active = <1>;
> +		};
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;

[Severity: Low]
Will this ports container cause a device tree validation failure?

This overlay matches the generic panel-lvds binding, which strictly requires
and only allows a single port property. Panels requiring dual LVDS ports
typically use dedicated schemas that explicitly support a ports container
instead of falling back to the strictly single-port panel-lvds.

> +
> +			port@0 {
> +				reg = <0>;
[ ... ]
> +&i2c1 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	status = "okay";
> +
> +	lvds_bridge: lvds-bridge@29 {
> +		compatible = "lontium,lt9211c";

[Severity: High]
Will the display bridge driver successfully probe with this compatible string?

The upstream Lontium LT9211 driver and its match tables only support and match
the lontium,lt9211 compatible string. Because the overlay specifies
lontium,lt9211c without providing a supported fallback like:

    compatible = "lontium,lt9211c", "lontium,lt9211";

the I2C subsystem might fail to bind the driver to the device,
resulting in a dead display output.

[Severity: Low]
Additionally, is the lontium,lt9211c compatible string documented?

It does not appear to be present in the lontium,lt9211.yaml schema,
which will also trigger dtbs_check warnings during device tree validation.

> +		reg = <0x29>;
> +		reset-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com?part=3