summaryrefslogtreecommitdiff
path: root/include/linux/input
diff options
context:
space:
mode:
authorBreno Leitao <leitao@debian.org>2026-01-26 09:50:26 -0800
committerMark Brown <broonie@kernel.org>2026-01-30 13:53:12 +0000
commitaabd8ea0aa253d40cf5f20a609fc3d6f61e38299 (patch)
tree9773d74f90b4e13c7af5b89632ad0fa05538afe7 /include/linux/input
parent63804fed149a6750ffd28610c5c1c98cce6bd377 (diff)
spi: tegra210-quad: Return IRQ_HANDLED when timeout already processed transfer
When the ISR thread wakes up late and finds that the timeout handler has already processed the transfer (curr_xfer is NULL), return IRQ_HANDLED instead of IRQ_NONE. Use a similar approach to tegra_qspi_handle_timeout() by reading QSPI_TRANS_STATUS and checking the QSPI_RDY bit to determine if the hardware actually completed the transfer. If QSPI_RDY is set, the interrupt was legitimate and triggered by real hardware activity. The fact that the timeout path handled it first doesn't make it spurious. Returning IRQ_NONE incorrectly suggests the interrupt wasn't for this device, which can cause issues with shared interrupt lines and interrupt accounting. Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling") Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Usama Arif <usamaarif642@gmail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-1-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'include/linux/input')
0 files changed, 0 insertions, 0 deletions