| Message ID | a4ee24cc9dac4f94b27fa521092ceb9cac2d5de2.1550514265.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | dmaengine: mv_xor: Use correct device for DMA API | expand |
Hello Robin, Thanks a lot for fixing this! On Mon, 18 Feb 2019 18:27:06 +0000 Robin Murphy <robin.murphy@arm.com> wrote: > Using dma_dev->dev for mappings before it's assigned with the correct > device is unlikely to work as expected, and with future dma-direct > changes, passing a NULL device may end up crashing entirely. I don't > know enough about this hardware or the mv_xor_prep_dma_interrupt() > operation to implement the appropriate error-handling logic that would > have revealed those dma_map_single() calls failing on arm64 for as long > as the driver has been enabled there, but moving the assignment earlier > will at least make the current code operate as intended. > > Fixes: 22843545b200 ("dma: mv_xor: Add support for DMA_INTERRUPT") > Reported-by: John David Anglin <dave.anglin@bell.net> > Tested-by: John David Anglin <dave.anglin@bell.net> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Best regards, Thomas
On 18-02-19, 18:27, Robin Murphy wrote: > Using dma_dev->dev for mappings before it's assigned with the correct > device is unlikely to work as expected, and with future dma-direct > changes, passing a NULL device may end up crashing entirely. I don't > know enough about this hardware or the mv_xor_prep_dma_interrupt() > operation to implement the appropriate error-handling logic that would > have revealed those dma_map_single() calls failing on arm64 for as long > as the driver has been enabled there, but moving the assignment earlier > will at least make the current code operate as intended. Applied, thanks
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c index 7f595355fb79..fe4a7c71fede 100644 --- a/drivers/dma/mv_xor.c +++ b/drivers/dma/mv_xor.c @@ -1059,6 +1059,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev, mv_chan->op_in_desc = XOR_MODE_IN_DESC; dma_dev = &mv_chan->dmadev; + dma_dev->dev = &pdev->dev; mv_chan->xordev = xordev; /* @@ -1091,7 +1092,6 @@ mv_xor_channel_add(struct mv_xor_device *xordev, dma_dev->device_free_chan_resources = mv_xor_free_chan_resources; dma_dev->device_tx_status = mv_xor_status; dma_dev->device_issue_pending = mv_xor_issue_pending; - dma_dev->dev = &pdev->dev; /* set prep routines based on capability */ if (dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask))
Using dma_dev->dev for mappings before it's assigned with the correct device is unlikely to work as expected, and with future dma-direct changes, passing a NULL device may end up crashing entirely. I don't know enough about this hardware or the mv_xor_prep_dma_interrupt() operation to implement the appropriate error-handling logic that would have revealed those dma_map_single() calls failing on arm64 for as long as the driver has been enabled there, but moving the assignment earlier will at least make the current code operate as intended. Fixes: 22843545b200 ("dma: mv_xor: Add support for DMA_INTERRUPT") Reported-by: John David Anglin <dave.anglin@bell.net> Tested-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/dma/mv_xor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)