Re: [PATCH v2 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The capacitive touch panel node `ft5x06_ts` lacks a `reset-gpios` (or `wake-gpios`) property, stranding a configured pinctrl pad and potentially causing probing failures.
- [Medium] The pinctrl for the USB VBUS regulator GPIO is incorrectly assigned to the USB controller node instead of the regulator node.
- [Low] The PCIe node uses the deprecated `reset-gpio` property instead of `reset-gpios`.
- [Low] The LED node name `led-hearthbeat` contains a typo.
--

--- Patch [3]: [PATCH v2 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board ---
commit f84a05986e6ac58f10d1a6e2091672e4f1bf919b
Author: Stefano Radaelli <stefano.r@variscite.com>

arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

This commit adds device tree support for the Variscite Symphony carrier board
with the VAR-SOM-MX8 QuadMax system on module. It configures interfaces
including SD card, USB, Ethernet, I2C, SPI, RTC, TPM, CAN, and PCIe.

Link: https://variscite.com/carrier-boards/symphony-board/

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
> new file mode 100644
> index 0000000000000..bf66786378301
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
[ ... ]
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		led-hearthbeat {

[Severity: Low]
This isn't a bug, but there is a typo in the node name (hearthbeat instead
of heartbeat).

> +			function = LED_FUNCTION_STATUS;
> +			color = <LED_COLOR_ID_GREEN>;
> +			gpios = <&pca9534 0 GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
[ ... ]
> +	/* Capacitive touch */
> +	ft5x06_ts: touchscreen@38 {
> +		compatible = "edt,edt-ft5406";
> +		pinctrl-names = "default";
> +		reg = <0x38>;
> +		pinctrl-0 = <&pinctrl_captouch>;
> +		interrupt-parent = <&lsio_gpio0>;
> +		interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
> +		touchscreen-size-x = <800>;
> +		touchscreen-size-y = <480>;
> +		touchscreen-inverted-x;
> +		touchscreen-inverted-y;
> +		wakeup-source;
> +	};

[Severity: Medium]
Is this touchscreen node missing a reset-gpios property?

The pinctrl_captouch group configures LSIO_GPIO0_IO16 for the touch
controller, but it is not assigned to reset-gpios here. 

Will the edt-ft5406 driver be able to toggle the reset line without it, or
could this lead to initialization failures?

[ ... ]
> +&pciea{
> +	phys = <&hsio_phy 0 PHY_TYPE_PCIE 0>;
> +	phy-names = "pcie-phy";
> +	reset-gpio = <&pca6408 1 GPIO_ACTIVE_LOW>;

[Severity: Low]
Should this use reset-gpios instead of the deprecated reset-gpio property?

> +	status = "okay";
> +};
[ ... ]
> +&usbotg1 {
> +	dr_mode = "host";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg1>;
> +	vbus-supply = <&reg_usb_otg1_vbus>;
> +	srp-disable;
> +	hnp-disable;
> +	adp-disable;
> +	disable-over-current;
> +	status = "okay";
> +};

[Severity: Medium]
Is pinctrl_usbotg1 assigned to the wrong node?

The reg_usb_otg1_vbus regulator uses the GPIO to provide power, but the
pinctrl to configure the pad is placed here on the usbotg1 controller.

Could this cause the GPIO pad to be incorrectly muxed when the fixed
regulator framework tries to enable power before the USB driver probes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784059139.git.stefano.r@variscite.com?part=3