Re: [PATCH v1 2/3] arm64: dts: imx8mm-var-dart: add TPM support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] arm64: dts: incorrect polarity for TPM reset gpio
- [Medium] arm64: dts: missing pinctrl for TPM reset gpio
--

commit b6842f762ba714e622e3da081d4b664400c4462d
Author: Stefano Radaelli <stefano.r@variscite.com>

arm64: dts: imx8mm-var-dart: add TPM support

Add support for the TPM available on the Variscite DART-MX8M-MINI SOM.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> index c7a9eb23e5e88..9fc0f7e551ca7 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi

[ ... ]

> @@ -138,6 +138,13 @@ &i2c1 {
>  	sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
>  	status = "okay";
>  
> +	st33ktpm2xi2c_som: tpm@2e {
> +		compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
> +		reg = <0x2e>;
> +		label = "tpm";
> +		reset-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Will this reset line work without a corresponding pinctrl configuration?

The node requests &gpio4 31 (pad SAI3_TXFS) as its reset line but lacks a
pinctrl-0 property to configure the pad's multiplexer to GPIO mode.

Since the i.MX pinctrl driver does not implement .gpio_request_enable(),
the GPIO subsystem cannot automatically reconfigure the pad when requested.

Does this leave the pad in its default or bootloader-assigned state,
causing software toggling of the GPIO to silently fail and breaking
the hardware reset capability?

[Severity: High]
Is the reset GPIO polarity correct for the ST33K TPM hardware?

The STMicroelectronics ST33K TPM hardware reset line is active-low
(RST_N), but the reset-gpios property specifies GPIO_ACTIVE_HIGH.

When the driver attempts to release the device from reset by logically
de-asserting the GPIO, won't gpiolib drive the physical line LOW (0V)?

Driving the active-low hardware pin LOW will hold the TPM in reset
permanently, causing device initialization to fail entirely. Should this
be configured as GPIO_ACTIVE_LOW instead?

> +	};
> +
>  	pmic@4b {
>  		compatible = "rohm,bd71847";
>  		reg = <0x4b>;

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