public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer_half()
@ 2025-12-26 11:35 Alper Ak
  2026-01-02 17:28 ` Jarkko Sakkinen
  0 siblings, 1 reply; 2+ messages in thread
From: Alper Ak @ 2025-12-26 11:35 UTC (permalink / raw)
  To: peterhuewe, jarkko
  Cc: Alper Ak, Jason Gunthorpe, Krishna Yarlagadda, linux-integrity,
	linux-kernel

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


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer_half()
  2025-12-26 11:35 [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer_half() Alper Ak
@ 2026-01-02 17:28 ` Jarkko Sakkinen
  0 siblings, 0 replies; 2+ messages in thread
From: Jarkko Sakkinen @ 2026-01-02 17:28 UTC (permalink / raw)
  To: Alper Ak
  Cc: peterhuewe, Jason Gunthorpe, Krishna Yarlagadda, linux-integrity,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-01-02 17:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-26 11:35 [PATCH] tpm: tpm_tis_spi: Initialize ret variable in tpm_tis_spi_transfer_half() Alper Ak
2026-01-02 17:28 ` Jarkko Sakkinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox