Re: [PATCH v5 1/3] spi: tegra210-quad: Convert to hard IRQ with high-priority workqueue

[Vishwaroop A]

On Wed, Jul 08, 2026 at 05:15:25AM -0700, Breno Leitao wrote:
> I am still quite confused what tqspi->lock protects. In the code above,
> you get the lock, then you dereference tqspi->curr_xfer, and then it
> releases the lock, and use t later without any lock.

Just the pointer read against the writers - tegra_qspi_setup_transfer_one()
which publishes curr_xfer, and the completion paths which clear it.
After the snapshot, t refers to the transfer that was current at that
moment; later writes to tqspi->curr_xfer don't change t.

The spi_transfer object itself is kept alive by the SPI core, not by
this lock: tegra_qspi_{combined,non_combined}_seq_xfer() is parked in
wait_for_completion_timeout(&tqspi->xfer_completion) for this xfer,
so spi_finalize_current_message() cannot run and the message (and
its spi_transfers) cannot be handed back to the caller until we - or
the timeout path - signal xfer_completion.

> if tqspi->lock() is protecting curr_xfer, shouldn't you hold it for
> longer?

Can't - wait_for_completion_interruptible_timeout() below sleeps, so
holding spin_lock_irqsave() across it would trip
scheduling-while-atomic and stall IRQs for the duration.
handle_cpu_based_xfer() gets a single lock scope because it never
sleeps; the DMA path has to split.

Since v5, tegra_qspi_handle_timeout() also does
cancel_work_sync(&tqspi->irq_work) before invoking
handle_dma_based_xfer() itself (Mark's v4 concern), so the work
handler and the timeout handler can't both be inside this function
on the same transfer.

Thanks,
Vishwaroop