Re: [PATCH 5/8] arm64: dts: ti: k3-am64: Enable IO expander interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The IO expander interrupt is incorrectly configured with IRQ_TYPE_LEVEL_HIGH polarity for an active-low open-drain output.
- [Medium] The pad configuration for the SK board removes the internal pull-up, potentially leaving the open-drain interrupt line floating.
--

--- Patch [5]: [PATCH 5/8] arm64: dts: ti: k3-am64: Enable IO expander interrupt ---
commit 846c9ea4531cda7562459d539ef568783fb1e41c
Author: Judith Mendez <jm@ti.com>

arm64: dts: ti: k3-am64: Enable IO expander interrupt

On AM64 EVM and SK boards, MMC1_SDWP is used for IO expander interrupt,
remove from MMC1 pinmux node and setup as exp1 IO expander interrupt.

> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
[ ... ]
> @@ -481,6 +487,12 @@ exp1: gpio@22 {
>  		bootph-all;
>  		compatible = "ti,tca6424";
>  		reg = <0x22>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&main_gpio1_ioexp_intr_pins_default>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <78 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will setting this interrupt to IRQ_TYPE_LEVEL_HIGH cause an interrupt storm?

Since the TCA6424 IO expander has an active-low open-drain interrupt output,
an active-high configuration might trigger continuously when the line is
idle, eventually causing the kernel to disable the interrupt.

> +		interrupt-controller;
> +		#interrupt-cells = <2>;
>  		gpio-controller;

> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> @@ -198,7 +198,6 @@ &main_pmx0 {
>  	main_mmc1_pins_default: main-mmc1-default-pins {
>  		bootph-all;
>  		pinctrl-single,pins = <
> -			AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0) /* (C20) MMC1_SDWP */
>  			AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0) /* (D19) MMC1_SDCD */
>  			AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0) /* (J19) MMC1_CMD */
[ ... ]
> @@ -210,6 +209,13 @@ AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0) /* (K18) MMC1_DAT3 */
>  		>;
>  	};
>  
> +	main_gpio1_ioexp_intr_pins_default: main-gpio1-ioexp-intr-default-pins {
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x029c, PIN_INPUT, 7) /* (C20) MMC1_SDWP.GPIO1_78 */

[Severity: Medium]
Does dropping the internal pull-up on this pad risk leaving the interrupt
line floating?

The previous configuration for this pad on the SK board used
PIN_INPUT_PULLUP. If the board lacks a dedicated external pull-up resistor
for this open-drain interrupt, using PIN_INPUT might lead to spurious edge
detections.

> +		>;
> +		bootph-all;
> +	};
[ ... ]
> @@ -383,6 +389,12 @@ exp1: gpio@70 {
>  		bootph-all;
>  		compatible = "nxp,pca9538";
>  		reg = <0x70>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&main_gpio1_ioexp_intr_pins_default>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <78 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Could this also trigger an interrupt storm on the SK board?

Similar to the EVM board, the PCA9538 IO expander typically has an
active-low open-drain interrupt. An active-high configuration will likely
trigger unconditionally on boot.

> +		interrupt-controller;
> +		#interrupt-cells = <2>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729195958.671147-1-jm@ti.com?part=5