On Tue, Jun 09, 2020 at 11:00:33AM +0100, Robin Murphy wrote: > Ah, I think I understand what's going on now. That's... really ugly :( > Looking at the SPI core code, I think a better way to handle this would be > to have your fallback path call spi_unmap_buf() directly (or perform the > same actions, if exporting that to drivers is unacceptable), then make sure > ->can_dma() returns false after that such that spi_unmap_msg() won't try to > unmap it again. That's a lot more reasonable than trying to fake up a > DMA_TO_DEVICE transfer in the middle of a DMA_FROM_DEVICE operation on the > same buffer. Ideally the driver would be checking in can_dma() if the DMA controller is able to perform transactions rather than letting things run as far as trying to actually do the transfer, that's a whole lot cleaner and more manageable than running into an error doing the transfer. I'm surprised that there's no DMA API way to figure this out TBH. We'll also need some handling for this changing at runtime, we're not expecting this to be dynamic at all - we're expecting it to be a static property of the controller/transfer combination, we didn't contemplate this varying randomly at runtime. Instead of rechecking can_dma() we ought to have a flag saying if we did the mapping (which the bodge Robin suggests above could clear).
Attachment:
signature.asc
Description: PGP signature
