summaryrefslogtreecommitdiff
path: root/rust/kernel/interop/git@git.tavy.me:linux-stable.git
diff options
context:
space:
mode:
authorBreno Leitao <leitao@debian.org>2026-04-08 06:45:43 -0700
committerMark Brown <broonie@kernel.org>2026-04-10 13:20:24 +0100
commit5b94c94caafcad3c77cc6b1d213a93bf5dc0a98e (patch)
tree46c96d56eeb34eb87b76c4c85e6c04e96937593e /rust/kernel/interop/git@git.tavy.me:linux-stable.git
parent6dd13023ec49dcbe9dd6781de524d9e63bb27a49 (diff)
spi: tegra210-quad: Fix false positive WARN on interrupt timeout with transfer complete
The WARN_ON_ONCE/WARN_ON fired unconditionally on any completion timeout, including the recoverable case where the interrupt was lost but the hardware actually finished the transfer. This produced a noisy splat with a full call trace even though the driver successfully recovered via tegra_qspi_handle_timeout(). Since tegra210 uses threaded interrupts, the transfer completion can be signaled before the interrupt fires, making this false positive case common in practice. Almost all the hosts I sysadmin in my fleet produce the following splat: WARNING: CPU: 47 PID: 844 at drivers/spi/spi-tegra210-quad.c:1226 tegra_qspi_transfer_one_message+0x8a4/0xba8 .... tegra-qspi NVDA1513:00: QSPI interrupt timeout, but transfer complete Move WARN_ON_ONCE/WARN_ON to fire only on real unrecoverable timeouts, i.e., when tegra_qspi_handle_timeout() confirms the hardware did NOT complete. This makes the warning actionable instead of just polluting the metrics. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260408-tegra_warn-v1-1-669a3bc74d77@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'rust/kernel/interop/git@git.tavy.me:linux-stable.git')
0 files changed, 0 insertions, 0 deletions