Messages in this thread | | | Subject | Re: [PATCH] ata: sata_rcar: Fix DMA boundary mask | From | Sergei Shtylyov <> | Date | Wed, 13 May 2020 15:43:51 +0300 |
| |
Hello!
On 13.05.2020 14:04, Geert Uytterhoeven wrote:
> Before commit 9495b7e92f716ab2 ("driver core: platform: Initialize > dma_parms for platform devices"), the R-Car SATA device didn't have DMA > parameters. Hence the DMA boundary mask supplied by its driver was > silently ignored, as __scsi_init_queue() doesn't check the return value > of dma_set_seg_boundary(), and the default value of 0xffffffff was used. > > Now the device has gained DMA parameters, the driver-supplied value is > used, and the following warning is printed on Salvator-XS: > > DMA-API: sata_rcar ee300000.sata: mapping sg segment across boundary [start=0x00000000ffffe000] [end=0x00000000ffffefff] [boundary=0x000000001ffffffe] > WARNING: CPU: 5 PID: 38 at kernel/dma/debug.c:1233 debug_dma_map_sg+0x298/0x300 > > (the range of start/end values depend on whether IOMMU support is > enabled or not) > > The issue here is that SATA_RCAR_DMA_BOUNDARY doesn't have bit 0 set, so > any typical end value, which is odd, will trigger the check. > > Fix this by increasing the DMA boundary value by 1. > > Fixes: 8bfbeed58665dbbf ("sata_rcar: correct 'sata_rcar_sht'") > Fixes: 9495b7e92f716ab2 ("driver core: platform: Initialize dma_parms for platform devices") > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Sorry, my mistake that went undetected for many years. :-)
MBR, Sergei
| |