From: Robin Murphy <robin.murphy@arm.com> To: vinod.koul@intel.com, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, dan.j.williams@intel.com, lars@metafoo.de, liviu.dudau@arm.com, andrew.jackson@arm.com Subject: [PATCH] dma-mapping: tidy up dma_parms default handling Date: Fri, 19 Dec 2014 17:39:09 +0000 [thread overview] Message-ID: <ffdc5455d698d2525f2d126d0adabf9418fd76b1.1418990609.git.robin.murphy@arm.com> (raw) Many DMA controllers and other devices set max_segment_size to indicate their scatter-gather capability, but have no interest in segment_boundary_mask. However, the existence of a dma_parms structure precludes the use of any default value, leaving them as zeros (assuming a properly kzalloc'ed structure). If a well-behaved IOMMU (or SWIOTLB) then tries to respect this by ensuring a mapped segment does not cross a zero-byte boundary, hilarity ensues. Since zero is a nonsensical value for either parameter, treat it as an indicator for "default", as might be expected. In the process, clean up a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous "else" statements. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- Hi Vinod, dmaengine folks, This isn't strictly a dmaengine patch, but get_maintainer.pl pointed at you, and there do happen to be more dmaengine drivers potentially affected by this than anything else - the current PL330 driver blows up arm64's SWIOTLB when running dmatest on the Juno platform, which is what brought the underlying problem to light. include/linux/dma-mapping.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index c3007cb..99ba736 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -141,7 +141,9 @@ static inline void arch_teardown_dma_ops(struct device *dev) { } static inline unsigned int dma_get_max_seg_size(struct device *dev) { - return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536; + if (dev->dma_parms && dev->dma_parms->max_segment_size) + return dev->dma_parms->max_segment_size; + return SZ_64K; } static inline unsigned int dma_set_max_seg_size(struct device *dev, @@ -150,14 +152,15 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev, if (dev->dma_parms) { dev->dma_parms->max_segment_size = size; return 0; - } else - return -EIO; + } + return -EIO; } static inline unsigned long dma_get_seg_boundary(struct device *dev) { - return dev->dma_parms ? - dev->dma_parms->segment_boundary_mask : 0xffffffff; + if (dev->dma_parms && dev->dma_parms->segment_boundary_mask) + return dev->dma_parms->segment_boundary_mask; + return DMA_BIT_MASK(32); } static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) @@ -165,8 +168,8 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) if (dev->dma_parms) { dev->dma_parms->segment_boundary_mask = mask; return 0; - } else - return -EIO; + } + return -EIO; } #ifndef dma_max_pfn -- 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RESEND] dma-mapping: tidy up dma_parms default handling Date: Fri, 9 Jan 2015 16:56:03 +0000 [thread overview] Message-ID: <ffdc5455d698d2525f2d126d0adabf9418fd76b1.1418990609.git.robin.murphy@arm.com> (raw) Many DMA controllers and other devices set max_segment_size to indicate their scatter-gather capability, but have no interest in segment_boundary_mask. However, the existence of a dma_parms structure precludes the use of any default value, leaving them as zeros (assuming a properly kzalloc'ed structure). If a well-behaved IOMMU (or SWIOTLB) then tries to respect this by ensuring a mapped segment does not cross a zero-byte boundary, hilarity ensues. Since zero is a nonsensical value for either parameter, treat it as an indicator for "default", as might be expected. In the process, clean up a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous "else" statements. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- Hi, various maintainers from Git logs ;) This one's a bit tricky to find a home for - I think technically it's probably an IOMMU patch, but then the long-underlying problem doesn't seem to have blown up anything until arm64, and my motivation is to make bits of Juno work, which seems to nudge it towards arm64/arm-soc territory. Could anyone suggest which tree is most appropriate? Thanks, Robin. include/linux/dma-mapping.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index c3007cb..99ba736 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -141,7 +141,9 @@ static inline void arch_teardown_dma_ops(struct device *dev) { } static inline unsigned int dma_get_max_seg_size(struct device *dev) { - return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536; + if (dev->dma_parms && dev->dma_parms->max_segment_size) + return dev->dma_parms->max_segment_size; + return SZ_64K; } static inline unsigned int dma_set_max_seg_size(struct device *dev, @@ -150,14 +152,15 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev, if (dev->dma_parms) { dev->dma_parms->max_segment_size = size; return 0; - } else - return -EIO; + } + return -EIO; } static inline unsigned long dma_get_seg_boundary(struct device *dev) { - return dev->dma_parms ? - dev->dma_parms->segment_boundary_mask : 0xffffffff; + if (dev->dma_parms && dev->dma_parms->segment_boundary_mask) + return dev->dma_parms->segment_boundary_mask; + return DMA_BIT_MASK(32); } static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) @@ -165,8 +168,8 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask) if (dev->dma_parms) { dev->dma_parms->segment_boundary_mask = mask; return 0; - } else - return -EIO; + } + return -EIO; } #ifndef dma_max_pfn -- 1.9.1
next reply other threads:[~2014-12-19 17:39 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-19 17:39 Robin Murphy [this message] 2015-01-09 16:56 ` [PATCH RESEND] dma-mapping: tidy up dma_parms default handling Robin Murphy 2014-12-22 15:25 ` [PATCH] " Vinod Koul 2014-12-22 15:25 ` Vinod Koul 2015-01-09 19:45 ` [PATCH RESEND] " Arnd Bergmann 2015-01-09 19:45 ` Arnd Bergmann 2015-01-12 13:00 ` Will Deacon 2015-01-12 13:00 ` Will Deacon 2015-01-12 13:00 ` Will Deacon 2015-01-12 13:07 ` Robin Murphy 2015-01-12 13:07 ` Robin Murphy 2015-01-12 13:07 ` Robin Murphy 2015-01-13 11:19 ` Marek Szyprowski 2015-01-13 11:19 ` Marek Szyprowski 2015-01-13 11:19 ` Marek Szyprowski 2015-01-22 3:45 ` Sumit Semwal 2015-01-22 3:45 ` Sumit Semwal
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ffdc5455d698d2525f2d126d0adabf9418fd76b1.1418990609.git.robin.murphy@arm.com \ --to=robin.murphy@arm.com \ --cc=andrew.jackson@arm.com \ --cc=dan.j.williams@intel.com \ --cc=dmaengine@vger.kernel.org \ --cc=lars@metafoo.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=liviu.dudau@arm.com \ --cc=vinod.koul@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.