Re: [PATCH v3 3/3] arm64: dts: ti: var-som-am62: Add support for Variscite Symphony Board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The PCA9534 I2C GPIO expander interrupt is configured as edge-triggered (IRQ_TYPE_EDGE_FALLING) instead of level-triggered (IRQ_TYPE_LEVEL_LOW), which will lead to permanently missed interrupts.
--

--- Patch [3]: [PATCH v3 3/3] arm64: dts: ti: var-som-am62: Add support for Variscite Symphony Board ---
commit bd58b379bc670274a1ca977bcbbbb50a0e0f09a6
Author: Stefano Radaelli <stefano.r@variscite.com>

arm64: dts: ti: var-som-am62: Add support for Variscite Symphony Board

This commit adds device tree support for the Variscite Symphony carrier
board with the VAR-SOM-AM62 system on module.

Link: https://www.variscite.it/product/single-board-computers/symphony-board/

> diff --git a/arch/arm64/boot/dts/ti/k3-am625-var-som-symphony.dts b/arch/arm64/boot/dts/ti/k3-am625-var-som-symphony.dts
> new file mode 100644
> index 0000000000000..e2fba95d9b948
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am625-var-som-symphony.dts

[ ... ]

> +&main_i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c0>;
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	/* GPIO expander */
> +	pca9534: gpio@20 {
> +		compatible = "nxp,pca9534";
> +		reg = <0x20>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pca9534>;
> +		#gpio-cells = <2>;
> +		gpio-controller;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <30 IRQ_TYPE_EDGE_FALLING>;

[Severity: Medium]
Will this edge-triggered configuration cause permanently missed interrupts?

The PCA9534 INT output is an open-drain active-low signal that remains low
as long as unhandled interrupt events exist. If a new GPIO event occurs
while the CPU is processing a previous interrupt (like a rapid subsequent
button press or a contact bounce on the configured gpio-keys), the INT
line will stay logically low.

Because the interrupt controller is configured for EDGE_FALLING, it won't
detect the subsequent event without a new falling edge, leaving the input
device stuck and unresponsive.

Should this be configured as IRQ_TYPE_LEVEL_LOW instead?

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