Re: [PATCH v4 1/2] arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: Invalid compatible 'lontium,lt9611uxd' lacks driver support
- [High] dts: Incorrect reset-gpios polarity holds LT9611 bridge in reset
--

commit d181c75b1ca5c7813638aeaae19d81602f7108ef
Author: Mohit Dsor <mohit.dsor@oss.qualcomm.com>

arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support

Enable the Shikra MDSS display subsystem on the Qualcomm Shikra IQS
EVK board and add the Lontium LT9611UXD DSI-to-HDMI bridge node.

> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> index 5df30ad8211f8..fee93410b2e43 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
[ ... ]
> @@ -23,6 +24,98 @@ aliases {
[ ... ]
> +&i2c4 {
> +	status = "okay";
> +
> +	lt9611uxd: lt9611uxd@41 {
> +		compatible = "lontium,lt9611uxd";

[Severity: High]
Does this compatible string have a corresponding driver implementation and DT
binding?

There is no of_device_id match for "lontium,lt9611uxd" in any driver in the
kernel (the Lontium bridge drivers in drivers/gpu/drm/bridge/ only support
"lontium,lt9611" and "lontium,lt9611uxc"), nor is there an associated DT
binding. Because no driver will bind to this node, the display output will
silently fail to initialize.

> +		reg = <0x41>;
> +		interrupts-extended = <&tlmm 85 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;

[Severity: High]
Does this reset polarity interact correctly with the driver's hardcoded reset
sequence?

The existing Lontium bridge drivers (lt9611 and lt9611uxc) are implemented
with an inverted reset sequence. They call
gpiod_set_value_cansleep(reset_gpio, 1) at the end of their reset routine
(lt9611_reset()) to take the device out of reset, assuming the DT specifies
GPIO_ACTIVE_HIGH as a workaround.

When GPIO_ACTIVE_LOW is used instead, the gpiolib subsystem translates the
logical 1 to a physical 0 (LOW). This will drive the reset pin physically LOW
at the end of initialization, trapping the bridge in reset indefinitely and
causing probe failures and I2C communication timeouts.

> +		vcc-supply = <&vreg_disp_3p3>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-master_lt9611uxd-v4-0-9986704e2a7b@oss.qualcomm.com?part=1