linux-kernel - Re: [PATCH v2 1/2] spi: tegra210-quad: Fix timeout handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21078f4e-cb55-42c3-b3bc-2bdf8ce38aa2@nvidia.com>
Date: Thu, 16 Oct 2025 14:44:26 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Vishwaroop A <va@...dia.com>, Mark Brown <broonie@...nel.org>,
 Thierry Reding <thierry.reding@...il.com>,
 Sowjanya Komatineni <skomatineni@...dia.com>,
 Laxman Dewangan <ldewangan@...dia.com>, smangipudi@...dia.com,
 kyarlagadda@...dia.com
Cc: linux-spi@...r.kernel.org, linux-tegra@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thierry Reding <treding@...dia.com>
Subject: Re: [PATCH v2 1/2] spi: tegra210-quad: Fix timeout handling


On 16/10/2025 14:29, Vishwaroop A wrote:
> When the CPU that the QSPI interrupt handler runs on (typically CPU 0)
> is excessively busy, it can lead to rare cases of the IRQ thread not
> running before the transfer timeout is reached.
> 
> While handling the timeouts, any pending transfers are cleaned up and
> the message that they correspond to is marked as failed, which leaves
> the curr_xfer field pointing at stale memory.
> 
> To avoid this, clear curr_xfer to NULL upon timeout and check for this
> condition when the IRQ thread is finally run.
> 
> While at it, also make sure to clear interrupts on failure so that new
> interrupts can be run.
> 
> A better, more involved, fix would move the interrupt clearing into a
> hard IRQ handler. Ideally we would also want to signal that the IRQ
> thread no longer needs to be run after the timeout is hit to avoid the
> extra check for a valid transfer.
> 
> Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
> Signed-off-by: Thierry Reding <treding@...dia.com>
> Signed-off-by: Vishwaroop A <va@...dia.com>
> ---
>   drivers/spi/spi-tegra210-quad.c | 23 ++++++++++++++++++++---
>   1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
> index 3be7499db21e..10e56d8ef678 100644
> --- a/drivers/spi/spi-tegra210-quad.c
> +++ b/drivers/spi/spi-tegra210-quad.c
> @@ -1024,8 +1024,10 @@ static void tegra_qspi_handle_error(struct tegra_qspi *tqspi)
>   	dev_err(tqspi->dev, "error in transfer, fifo status 0x%08x\n", tqspi->status_reg);
>   	tegra_qspi_dump_regs(tqspi);
>   	tegra_qspi_flush_fifos(tqspi, true);
> -	if (device_reset(tqspi->dev) < 0)
> +	if (device_reset(tqspi->dev) < 0) {
>   		dev_warn_once(tqspi->dev, "device reset failed\n");
> +		tegra_qspi_mask_clear_irq(tqspi);
> +	}
>   }
>   
>   static void tegra_qspi_transfer_end(struct spi_device *spi)
> @@ -1173,12 +1175,14 @@ static int tegra_qspi_combined_seq_xfer(struct tegra_qspi *tqspi,
>   					dma_ctl &= ~QSPI_DMA_EN;
>   					tegra_qspi_writel(tqspi, dma_ctl,
>   							  QSPI_DMA_CTL);
> -				}
> +			}

The above does not look correct.

Jon

-- 
nvpublic