Sarthak-Pandey opened a new pull request, #20587:
URL: https://github.com/apache/nuttx/pull/20587
## Summary
Fixes #19305
The SPI DMA exchange path in `rp23xx_spi.c` previously waited for DMA
completion using two back-to-back untimed, uninterruptible semaphore waits
(`nxsem_wait_uninterruptible()`). If a DMA transfer never completes (e.g.
stalled slave device or bus glitch), the calling thread sleeps indefinitely
without timeout.
In network drivers such as W5500 Ethernet on SPI0 running from the LP work
queue while holding `net_lock`, this stalled wait causes the LP worker to sleep
forever while holding the network lock, wedging the whole network stack (`ping`
hangs, network shell commands block, and driver TX-timeout recovery cannot run).
This patch addresses the issue for both ARM and RISC-V ports of rp23xx:
- Uses bounded waiting with `nxsem_tickwait_uninterruptible()` and a dynamic
timeout calculated from transfer size, SPI clock frequency, and a safety margin
(100 ms).
- On timeout/failure:
- Stops both TX and RX DMA channels via `rp23xx_dmastop()`.
- Disables DMA requests in the SPI control register (`SSPDMACR`).
- Resets the semaphore count (`nxsem_reset(&priv->dmasem, 0)`) to avoid
residual posts corrupting subsequent transfers.
- Flushes any stale bytes remaining in the RX FIFO.
- Logs the error via `spierr()` and returns instead of hanging forever.
## Impact
- **Architecture**: ARM and RISC-V (`arch/arm/src/rp23xx/rp23xx_spi.c`,
`arch/risc-v/src/rp23xx-rv/rp23xx_spi.c`).
- **User Impact**: Prevents system-wide network stack deadlocks when an SPI
transfer stalls. The network driver can gracefully degrade, release `net_lock`,
and run its TX timeout recovery handlers.
- **Compatibility**: Fully backwards-compatible.
## Testing
- Verified syntax and NuttX coding style compliance using `nxstyle`.
- Tested build and static verification against RP23xx SPI DMA paths.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]