CVE-2026-72134: spi: imx: reconfigure for PIO when DMA cannot be started

In the Linux kernel, the following vulnerability has been resolved:

spi: imx: reconfigure for PIO when DMA cannot be started

When spiimxcandma() selects DMA, the ECSPI is configured for DMA: spiimxsetupxfer() sets CTRL.SMC and clears dynamicburst, and spiimxdmatransfer() programs the dynamic-burst BURSTLENGTH and the SDMA watermarks.

If the DMA descriptor cannot be prepared (dmaengineprepslavesingle() returns NULL), the transfer is failed with SPITRANSFAILNOSTART and falls back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of the SPI core's mapping, so xfer->{tx,rx}sgmapped are not set and the core's DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst length and dynamicburst cleared, and the transferred data is corrupted.

This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin): every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns shifted TPM2GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is never created.

Set controller->fallback before re-running spiimxsetupxfer() so the ECSPI is reconfigured exactly like a normal PIO transfer. With controller->fallback set, spiimxsetupxfer() sees spiimxcandma() return false, so it clears spiimx->usedma and reprograms the controller (clears CTRL.SMC, restores dynamicburst and the PIO burst length). No explicit spiimx->usedma = false is needed: setupxfer() already updates it from the candma() result.