Re: [PATCH 4/5] spi: cadence-xspi: Don't use infinite timeout in register poll

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] spi: cadence-xspi: deadlock in panic writes due to non-atomic poll macro
--

commit 3f62b2245460c33dcb6fb6615d7fdf03de827776
Author: Tanmay Jagdale <tanmay@xxxxxxxxxxx>

spi: cadence-xspi: Don't use infinite timeout in register poll

The commit modifies the register polling functions to enforce a non-zero
timeout even when the sleep argument is false. This prevents busy-waits from
switching to infinite timeouts. The change anticipates future panic write
handling support.

> diff --git a/drivers/spi/spi-cadence-xspi.c b/drivers/spi/spi-cadence-xspi.c
> index 7cf52bcb05df6..09ed2afbd4af3 100644
> --- a/drivers/spi/spi-cadence-xspi.c
> +++ b/drivers/spi/spi-cadence-xspi.c
> @@ -374,7 +374,7 @@ static bool cdns_xspi_is_stig_ready(struct cdns_xspi_dev *cdns_xspi, bool sleep)
>  		ctrl_stat,
>  		((ctrl_stat & BIT(3)) == 0),
>  		sleep ? MRVL_XSPI_POLL_DELAY_US : 0,
> -		sleep ? MRVL_XSPI_POLL_TIMEOUT_US : 0);
> +		MRVL_XSPI_POLL_TIMEOUT_US);

[Severity: High]
Does this unconditionally trigger timekeeping functions in panic contexts?

When sleep is false, the panic write handler can deadlock.

The readl_relaxed_poll_timeout() macro expands to poll_timeout_us(), which
unconditionally calls ktime_get() when a non-zero timeout is provided.

In a panic context, timekeeping is suspended.

If a system panic occurs while another CPU holds the timekeeping seqlock
(tk_core.seq) and is stopped, ktime_get() will spin endlessly in
read_seqcount_begin(), deadlocking the system.

This prevents oops/kmsg crash logs from being written to flash, which is why
the <linux/iopoll.h> API contract explicitly forbids using it in atomic
contexts with a non-zero timeout.

To safely poll without sleeping in panic contexts, should the driver
conditionally use readl_relaxed_poll_timeout_atomic(), which relies on
udelay() and cycle counting instead of ktime_get()?

>  }
>  
>  static bool cdns_xspi_is_sdma_ready(struct cdns_xspi_dev *cdns_xspi, bool sleep)
> @@ -386,7 +386,7 @@ static bool cdns_xspi_is_sdma_ready(struct cdns_xspi_dev *cdns_xspi, bool sleep)
>  		ctrl_stat,
>  		(ctrl_stat & CDNS_XSPI_SDMA_TRIGGER),
>  		sleep ? MRVL_XSPI_POLL_DELAY_US : 0,
> -		sleep ? MRVL_XSPI_POLL_TIMEOUT_US : 0);
> +		MRVL_XSPI_POLL_TIMEOUT_US);

[Severity: High]
Can the same deadlock occur in the SDMA polling loop since this also calls
readl_relaxed_poll_timeout() with a non-zero timeout when sleep is false?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005081141.33688-1-paul.cercueil@xxxxxxxxxxx?part=4