From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:02
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes, and many implementations
have been broken for NULL device support for a while.
This series removes the few remaning users that weren't picked up in
the last merge window and then removes core support for this "feature".
A git tree is also available at:
git://git.infradead.org/users/hch/misc.git dma-remove-NULL-dev-support
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-remove-NULL-dev-support
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:07
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/parport/parport_ip32.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:12
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/da8xx-fb.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:19
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/gbefb.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:27
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:32
This gets rid of the last NULL dev argument passed to the DMA API.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/kernel/dma-isa.c | 8 +++++++-
arch/arm/mach-rpc/dma.c | 8 +++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:36
Most dma_map_ops implementations already had some issues with a NULL
device, or did simply crash if one was fed to them. Now that we have
cleaned up all the obvious offenders we can stop to pretend we
support this mode.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
Documentation/DMA-API-HOWTO.txt | 13 ++++++-------
include/linux/dma-mapping.h | 6 +++---
kernel/dma/direct.c | 2 +-
3 files changed, 10 insertions(+), 11 deletions(-)
@@ -365,13 +365,12 @@ __get_free_pages() (but takes size instead of a page order). If your driver needs regions sized smaller than a page, you may prefer using the dma_pool interface, described below.-The consistent DMA mapping interfaces, for non-NULL dev, will by-default return a DMA address which is 32-bit addressable. Even if the-device indicates (via DMA mask) that it may address the upper 32-bits,-consistent allocation will only return > 32-bit addresses for DMA if-the consistent DMA mask has been explicitly changed via-dma_set_coherent_mask(). This is true of the dma_pool interface as-well.+The consistent DMA mapping interfaces, will by default return a DMA address+which is 32-bit addressable. Even if the device indicates (via the DMA mask)+that it may address the upper 32-bits, consistent allocation will only+return > 32-bit addresses for DMA if the consistent DMA mask has been+explicitly changed via dma_set_coherent_mask(). This is true of the+dma_pool interface as well. dma_alloc_coherent() returns two values: the virtual address which you can use to access it from the CPU and dma_handle which you pass to the
From: Christoph Hellwig <hch@lst.de> Date: 2019-03-21 22:53:39
Now that we removed support for the NULL device argument in the DMA API,
there is no need to cater for that in the x86 code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 10 ----------
arch/x86/kernel/amd_gart_64.c | 6 ------
arch/x86/kernel/pci-dma.c | 20 --------------------
kernel/dma/mapping.c | 7 -------
4 files changed, 43 deletions(-)
@@ -256,9 +252,6 @@ void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,/* let the implementation decide on the zone to allocate from: */flag&=~(__GFP_DMA|__GFP_DMA32|__GFP_HIGHMEM);-if(!arch_dma_alloc_attrs(&dev))-returnNULL;-if(dma_is_direct(ops))cpu_addr=dma_direct_alloc(dev,size,dma_handle,flag,attrs);elseif(ops->alloc)
From: Christoph Hellwig <hch@lst.de> Date: 2019-04-03 15:36:08
Any comments on the remaining patches? I'd like to give this series
a couple weeks of soaking in linux-next before the end of the merge
window, so reviews would be apprciated.
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes, and many implementations
have been broken for NULL device support for a while.
This series removes the few remaning users that weren't picked up in
the last merge window and then removes core support for this "feature".
A git tree is also available at:
git://git.infradead.org/users/hch/misc.git dma-remove-NULL-dev-support
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-remove-NULL-dev-support
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Bartlomiej Zolnierkiewicz <redacted>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2019-04-03 18:26:58
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes, and many implementations
have been broken for NULL device support for a while.
I think I must be missing something, but...
My understanding is that ISA DMA is normally limited to 24 bits of
address - indeed, the x86 version only programs 24 bits of DMA address.
Looking through this series, it appears that the conversions mean that
the DMA mask for ISA becomes the full all-ones DMA mask, which would
of course lead to memory corruption if only 24 bits of the address end
up being programmed into the hardware.
Maybe you could say why you think this series is safe in regard to ISA
DMA?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
From: Christoph Hellwig <hch@lst.de> Date: 2019-04-03 19:42:35
On Wed, Apr 03, 2019 at 07:26:40PM +0100, Russell King - ARM Linux admin wrote:
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
quoted
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes, and many implementations
have been broken for NULL device support for a while.
I think I must be missing something, but...
My understanding is that ISA DMA is normally limited to 24 bits of
address
Yes.
- indeed, the x86 version only programs 24 bits of DMA address.
Looking through this series, it appears that the conversions mean that
the DMA mask for ISA becomes the full all-ones DMA mask, which would
of course lead to memory corruption if only 24 bits of the address end
up being programmed into the hardware.
In the generic dma mapping code no struct device has always meant a
32-bit DMA mask - take a look at the dma_get_mask() function.
Maybe you could say why you think this series is safe in regard to ISA
DMA?
ISA DMA has always been rather painful in a myriad of ways, and the
DMA API so far hasn't helped, given that we don't do bounce buffering
for the 24-bit limit, but just the higher limits. So far even if you
do use the DMA API and pass a device ISA DMA so far always meant
that the higher layers had to assure things are addressable, either
by using GFP_DMA allocation in the drivers, or mid-layer hacks like
the unchecked_isa_dma flag in SCSI and/or BLK_BOUNCE_ISA in the
block layer.
This series doesn't change those facts at all. I have some half
started series to clean some of this up but it isn't high up on
the priority list.