Re: [PATCH v4 13/14] arm64: dts: st: support Engicam MicroGEA-STM32MP257-RMM board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Touchscreen coordinate limits do not match the explicitly configured display panel resolution, leading to skewed touch mapping.
- [High] Incorrect SPI chip select polarity configured for the ILI9806E panel on the spi1 bus.
--

commit 854048d228db5381ac3f46c66e9b5c98347cf9f6
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>

arm64: dts: st: support Engicam MicroGEA-STM32MP257-RMM board

This commit adds device tree support for the Engicam MicroGEA-STM32MP257-RMM
board. It defines various peripherals including an LCD panel with a
touchscreen, an audio codec, CAN, LEDs, and an SD card.

> diff --git a/arch/arm64/boot/dts/st/stm32mp257-engicam-microgea-rmm.dts b/arch/arm64/boot/dts/st/stm32mp257-engicam-microgea-rmm.dts
> new file mode 100644
> index 0000000000000..0212c03aae1ac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/st/stm32mp257-engicam-microgea-rmm.dts

[ ... ]

> +	touchscreen@38 {
> +		compatible = "edt,edt-ft5306";
> +		reg = <0x38>;
> +		interrupt-parent = <&gpiob>;
> +		interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&gpiod 1 GPIO_ACTIVE_LOW>;
> +		touchscreen-size-x = <1280>;
> +		touchscreen-size-y = <800>;

[Severity: High]
Are these touchscreen coordinate limits correct for the configured display
panel?

The device tree configures the display panel below as
rocktech,rk050hr345-ct106a, which is a 480x854 portrait panel.

However, the touchscreen size is explicitly set to 1280x800 here. The input
subsystem and userspace will scale touch events assuming these larger
hardware coordinates. Since the actual touchscreen overlaid on a 480x854
panel will report coordinates matching the panel's physical dimensions,
will touches be incorrectly scaled down?

> +	};

[ ... ]

> +&spi1 {
> +	pinctrl-names = "default", "sleep";
> +	pinctrl-0 = <&spi1_pins_a>;
> +	pinctrl-1 = <&spi1_sleep_pins_a>;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	cs-gpios = <&gpioh 8 GPIO_ACTIVE_HIGH>, <&gpioh 3 GPIO_ACTIVE_HIGH>;

[Severity: High]
Will the physical polarity of the SPI chip select lines conflict with the
panel's active-low requirement?

The cs-gpios property is configured with the GPIO_ACTIVE_HIGH flag. The
display panel node display@0 below does not specify the spi-cs-high
property, meaning the SPI device expects an active-low chip select.

Since the Linux gpiolib and SPI subsystem rules do not invert the logical
polarity when an active-high GPIO is used for an active-low SPI device,
the SPI core will drive the physical line HIGH when asserting the chip
select.

Because the ILI9806E panel requires an active-low chip select, will it
receive a HIGH signal during SPI transfers and ignore the initialization
commands? Should the cs-gpios property specify GPIO_ACTIVE_LOW instead?

> +	status = "okay";
> +
> +	display: display@0 {
> +		compatible = "rocktech,rk050hr345-ct106a", "ilitek,ili9806e";
> +		reg = <0>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605121957.78409-1-dario.binacchi@amarulasolutions.com?part=13