Re: [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer_half()

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Dec 26, 2025 at 02:35:04PM +0300, Alper Ak wrote:
> When len is 0, the while loop in tpm_tis_spi_transfer_half() is never
> entered and the function returns an uninitialized ret variable.
> 
> Initialize ret to 0 to correctly handle this case. This is consistent
> with tpm_tis_spi_transfer_full(), which already initializes ret to 0
> before the loop.
> 
> Fixes: a86a42ac2bd6 ("tpm_tis_spi: Add hardware wait polling")
> Signed-off-by: Alper Ak <alperyasinak1@gmail.com>
> ---
>  drivers/char/tpm/tpm_tis_spi_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c
> index 61b42c83ced8..1b6d79662ca1 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -85,7 +85,7 @@ static int tpm_tis_spi_transfer_half(struct tpm_tis_data *data,	u32 addr,
>  	struct spi_transfer spi_xfer[3];
>  	struct spi_message m;
>  	u8 transfer_len;
> -	int ret;
> +	int ret = 0;
>  
>  	while (len) {
>  		transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE);
> -- 
> 2.43.0
> 

OK, despite agreeing that 'ret' should be initialized I did not find a
call path where 'len' would end up being zero.

While acking the change in the sense that this function should be robust
enough to handle zero value for 'len', I'm just trying to figure out if
this is a regression from reproducability perspective, or just an 
improvement.

BR, Jarkko