Re: [PATCH v1 7/7] ARM: tegra: lg-x3: Add backlight LED controller node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] drm: display probe deferral due to missing lm3533 DT support
- [Medium] mfd: lm3533: GPIO lookup failure due to mismatched property name
- [Low] dt-bindings: missing schemas for new compatible strings
--

commit 6d421d459ccd001174a12d39a40edbf6cba8d6fc
Author: Svyatoslav Ryhel <clamor95@gmail.com>

    ARM: tegra: lg-x3: Add backlight LED controller node
    
    Add node for TI LM3533 LED controller used in this device for panel
    backlight.

> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
> index f888987ce1340..3a5e66d869b1b 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
> @@ -155,6 +155,8 @@ panel@1 {
>  				vdd-supply = <&vcc_3v0_lcd>;
>  				vddio-supply = <&iovcc_1v8_lcd>;
>  
> +				backlight = <&backlight>;

[Severity: High]
Does this cause the display panel to permanently defer probing?

When the lm3533 driver probes, it unconditionally calls dev_get_platdata()
and returns -EINVAL if pdata is missing:

drivers/mfd/lm3533-core.c:lm3533_device_init() {
    ...
	if (!pdata) {
		dev_err(lm3533->dev, "no platform data\n");
		return -EINVAL;
	}
    ...
}

Since the driver lacks Device Tree parsing logic entirely, the backlight
fails to probe, which causes the panel to return -EPROBE_DEFER indefinitely.

[ ... ]
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> index c7ad3819c21d9..781cf38e9f183 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> @@ -1170,6 +1170,30 @@ rmi4-f11@11 {
>  			};
>  		};
>  
> +		led-controller@36 {
> +			compatible = "ti,lm3533";

[Severity: Low]
Are we missing Device Tree schemas for this new compatible string?

Adding a new compatible string without updating or creating Device Tree
bindings bypasses schema validation, leaving hardware variant capabilities
undocumented. Additionally, the imagis,isa1200 compatible string lacks
both a schema and kernel driver support.

> +			reg = <0x36>;
> +
> +			enable-gpios = <&gpio TEGRA_GPIO(N, 6) GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Will this GPIO lookup fail due to a mismatched property name?

The driver requests the GPIO with a NULL connection ID:

drivers/mfd/lm3533-core.c:lm3533_device_init() {
    ...
	lm3533->hwen = devm_gpiod_get(lm3533->dev, NULL, GPIOD_OUT_LOW);
    ...
}

This causes gpiolib to strictly search for the base names gpios or
gpio, meaning it will receive -ENOENT instead of matching the provided
enable-gpios property.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924090608.28734-1-clamor95@gmail.com?part=7