Re: [PATCH v2] arm64: dts: ti: k3-am64: Enable IO expander interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Configuring a level-sensitive IO expander interrupt as edge-triggered creates a race condition that can permanently drop interrupts.
- [Medium] The internal pull-up is disabled for the open-drain IO expander interrupt line, potentially causing the pin to float if no external pull-up is present.
- [Low] The IO expander node has `bootph-all` but its new `interrupt-parent` (`main_gpio1`) does not, leading to a dangling phandle in the bootloader's DTB.
--

--- Patch [1]: [PATCH v2] arm64: dts: ti: k3-am64: Enable IO expander interrupt ---
commit 17dd1ed4722bb7802cfb997027eb263adde31a41
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.

Link: https://lore.kernel.org/linux-devicetree/20260729195958.671147-1-jm@ti.com/

> 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 +488,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>;

[Severity: Low]
Does this create a dangling phandle in the bootloader's DTB?

The exp1 node contains the bootph-all property, meaning U-Boot's fdtgrep
tool will extract it into the SPL device tree. However, it seems the
main_gpio1 node lacks the bootph-all property and will be stripped out of
the SPL DTB, leaving this interrupt-parent pointing to a missing node.

> +		interrupts = <78 IRQ_TYPE_EDGE_FALLING>;

[Severity: High]
Could configuring this as an edge-triggered interrupt cause a race condition
that permanently stalls the IO expander?

The IO expanders (TCA6424 and PCA9538) generate an active-low, level-sensitive
interrupt that remains asserted (low) as long as unacknowledged events exist.
If an input changes state while an existing interrupt is already being serviced,
the line will remain low.

Because it is edge-triggered here, no subsequent falling edge will be observed,
and since the consumer driver doesn't poll the pending state before returning,
it appears the interrupt controller will miss all future events.

> +		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 +199,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 */
[ ... ]
> +	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]
Will this disabled internal pull-up cause the interrupt line to float?

The IO expanders drive an active-low, open-drain interrupt line which requires
a pull-up. The original configuration explicitly used PIN_INPUT_PULLUP.

By changing this to PIN_INPUT, the internal pull-up is disabled. If the board
does not have a physical external pull-up resistor, the open-drain line could
float and generate spurious falling edges.

> +		>;
> +		bootph-all;
> +	};

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