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: Christoph Hellwig hch@lst.de Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Reviewed-by: Sergei Shtylyov sergei.shtylyov@cogentembedded.com Tested-by: Lad Prabhakar prabhakar.mahadev-lad.rj@bp.renesas.com Cc: stable stable@vger.kernel.org --- v2: - Add Reviewed-by, Tested-by, Cc.
This is a fix for a regression in v5.7-rc5 that fell through the cracks. https://lore.kernel.org/linux-ide/20200513110426.22472-1-geert+renesas@glide...
As by default the DMA debug code prints the first error only, this issue may be hidden on plain v5.7-rc5, where the FCP driver triggers a similar warning. Merging commit dd844fb8e50b12e6 ("media: platform: fcp: Set appropriate DMA parameters", in v5.8-rc1) from the media tree fixes the FCP issue, and exposes the SATA issue.
I added the second fixes tag because that commit is already being backported to stable kernels, and this patch thus needs backporting, too. --- drivers/ata/sata_rcar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c index 141ac600b64c87ef..44b0ed8f6bb8a120 100644 --- a/drivers/ata/sata_rcar.c +++ b/drivers/ata/sata_rcar.c @@ -120,7 +120,7 @@ /* Descriptor table word 0 bit (when DTA32M = 1) */ #define SATA_RCAR_DTEND BIT(0)
-#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFEUL +#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFFUL
/* Gen2 Physical Layer Control Registers */ #define RCAR_GEN2_PHY_CTL1_REG 0x1704
On Tue, 11 Aug 2020 at 10:17, Geert Uytterhoeven geert+renesas@glider.be 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: Christoph Hellwig hch@lst.de Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Reviewed-by: Sergei Shtylyov sergei.shtylyov@cogentembedded.com Tested-by: Lad Prabhakar prabhakar.mahadev-lad.rj@bp.renesas.com Cc: stable stable@vger.kernel.org
Reviewed-by: Ulf Hansson ulf.hansson@linaro.org
Kind regards Uffe
v2:
- Add Reviewed-by, Tested-by, Cc.
This is a fix for a regression in v5.7-rc5 that fell through the cracks. https://lore.kernel.org/linux-ide/20200513110426.22472-1-geert+renesas@glide...
As by default the DMA debug code prints the first error only, this issue may be hidden on plain v5.7-rc5, where the FCP driver triggers a similar warning. Merging commit dd844fb8e50b12e6 ("media: platform: fcp: Set appropriate DMA parameters", in v5.8-rc1) from the media tree fixes the FCP issue, and exposes the SATA issue.
I added the second fixes tag because that commit is already being backported to stable kernels, and this patch thus needs backporting, too.
drivers/ata/sata_rcar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c index 141ac600b64c87ef..44b0ed8f6bb8a120 100644 --- a/drivers/ata/sata_rcar.c +++ b/drivers/ata/sata_rcar.c @@ -120,7 +120,7 @@ /* Descriptor table word 0 bit (when DTA32M = 1) */ #define SATA_RCAR_DTEND BIT(0)
-#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFEUL +#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFFUL
/* Gen2 Physical Layer Control Registers */
#define RCAR_GEN2_PHY_CTL1_REG 0x1704
2.17.1
linux-stable-mirror@lists.linaro.org
-
Geert Uytterhoeven -
Ulf Hansson