Re: [PATCH v4 7/7] arm64: dts: renesas: rzg2l(c)/rzv2l hb-iiot: add dsi panel dt overlay

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The device tree overlay intentionally misrepresents the reset GPIO polarity to work around a Linux driver bug.
- [Medium] The panel node omits the exact hardware compatible string, using only a fallback compatible string from a different vendor's panel.
- [Low] Missing 'reg' property in node 'port@1'.
--

commit 8ad6ab9479d146e186e59ea48122ed17c1b07e32
Author: Josua Mayer <josua@solid-run.com>

arm64: dts: renesas: rzg2l(c)/rzv2l hb-iiot: add dsi panel dt overlay

This commit adds a device tree overlay for the Winstar WJ70N3TYJHMNG0
1024x600 DSI panel used on the SolidRun Hummingboard IIoT. The overlay
enables the MIPI-DSI connector and configures the panel, touchscreen,
and backlight for supported RZ/G2L, RZ/G2LC, and RZ/V2L targets.

[ ... ]

> diff --git a/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso
> new file mode 100644
> index 0000000000000..e43a38d5330e6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso
> @@ -0,0 +1,74 @@

[ ... ]

> +&dsi {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	status = "okay";
> +
> +	panel@0 {
> +		/* This is a Winstar panel, but the ronbo panel uses same controls. */
> +		compatible = "ronbo,rb070d30";

[Severity: Medium]
Is it possible to include the exact hardware compatible string for the Winstar
WJ70N3TYJHMNG0 panel before the fallback?

Core Devicetree principles require the compatible property to identify the
specific hardware part first, followed by any fallback identifiers. Providing
only the fallback string masks the true hardware identity. This might make it
difficult for the OS to apply future device-specific quirks or optimizations
without modifying the DT.

> +		reg = <0>;
> +		/* reset is active-low but driver inverts it internally */
> +		reset-gpios = <&tca6408_u48 1 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Does this property intentionally misrepresent the physical hardware state
(active-low reset) as active-high to accommodate a defect in the driver logic?

The device tree is intended to describe hardware accurately and
OS-independently. Encoding a software workaround into the hardware description
couples the DT to a specific buggy version of the Linux panel driver. This
breaks compatibility with other operating systems and will cause the panel to
break in Linux if the driver is ever fixed to properly handle standard reset
semantics.

> +		backlight = <&dsi_backlight>;
> +		power-gpios = <&tca6408_u48 2 GPIO_ACTIVE_HIGH>;
> +		shlr-gpios = <&tca6408_u48 4 GPIO_ACTIVE_LOW>;
> +		updn-gpios = <&tca6408_u48 5 GPIO_ACTIVE_HIGH>;
> +		vcc-lcd-supply = <&reg_dsi_panel>;
> +
> +		port {
> +			dsi_in_panel: endpoint {
> +				remote-endpoint = <&mipi_dsi_out>;
> +			};
> +		};
> +	};
> +
> +	ports {
> +		port@1 {

[Severity: Low]
Is this node missing a 'reg = <1>;' property?

The Device Tree specification requires that any node with a unit address (e.g.,
@1) must have a matching reg property. Missing this property causes the Device
Tree Compiler (dtc) to emit a unit_address_vs_reg warning during the build.

> +			mipi_dsi_out: endpoint {
> +				data-lanes = <1 2 3 4>;
> +				remote-endpoint = <&dsi_in_panel>;
> +			};
> +		};
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-rzg2-sr-boards-v4-0-4a456a422fee@solid-run.com?part=7