Re: [PATCH v2 1/4] arm64: dts: imx93-var-som-symphony: add TPM support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The TPM device relies on a GPIO hog from a sibling I2C GPIO expander to be enabled, but lacks a structural device dependency, leading to a probe race condition and potential initialization failures.
--

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

arm64: dts: imx93-var-som-symphony: add TPM support

This commit adds the ST33KTPM2XI2C TPM device to the Symphony carrier
board. It uses a GPIO hog on the PCAL6408 GPIO expander to assert the
TPM enable line, since the binding lacks a dedicated enable GPIO property.

> diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> index c0842fb3cfa33..f541308ebf6b8 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
[ ... ]
> @@ -208,6 +208,26 @@ &lpi2c1 {
>  	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
>  	status = "okay";
>  
> +	pcal6408: gpio@21 {
> +		compatible = "nxp,pcal6408";
> +		reg = <0x21>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		status = "okay";
> +
> +		tpm-enable-hog {
> +			gpio-hog;
> +			gpios = <4 GPIO_ACTIVE_HIGH>;
> +			output-high;
> +			line-name = "tpm_en";
> +		};
> +	};
> +
> +	st33ktpm2xi2c: tpm@2e {
> +		compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
> +		reg = <0x2e>;
> +	};

[Severity: High]
Since there is no explicit structural dependency between the TPM device and
the GPIO expander, could this introduce a probe order race condition?

Because fw_devlink is unaware of this relationship, if the drivers are
loaded asynchronously and the tpm_tis_i2c driver probes before the
gpio-pca953x driver, the enable line will remain deasserted. 

The TPM driver's initial I2C read might receive a NACK and return a
permanent error like -ENXIO instead of returning -EPROBE_DEFER.

Does this setup inadvertently rely on undefined probe ordering to ensure
the TPM is enabled before it is initialized?

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