Re: [PATCH v3] sh: mm: Fix unprotected access to struct device

On Wed, May 02, 2018 at 09:46:31AM +0200, jacopo mondi wrote: > Hi again Christoph, > > The gentle ping actually applies to this version of the patch. > > Sorry for the confusion. I'd expect this to go in through the sh tree, but if the sh maintainers are fine with it I can take it through

Re: [PATCH v2] base: dma-mapping: Postpone cpu addr translation on mmap()

Thanks, applied to the dma-mapping tree for 4.17.

Re: [PATCH] sh: mm: Fix unprotected access to struct device

On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote: > As long as it goes for arch/sh, the only user of dma_alloc_coherent() > is platform_resource_setup_memory(), and it has been fixed by this > patch. Great! > > Unfortunately, as Thomas pointed out, there are drivers which calls >

Re: [PATCH] sh: mm: Fix unprotected access to struct device

On Tue, Apr 17, 2018 at 03:54:07PM +0200, Thomas Petazzoni wrote: > > dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL); > > and one to switch to the WARN_ON + if(dev) model. But I don't really > care either way, so: > > Reviewed-by: Thomas Petazzoni Yes,

Re: [PATCH] sh: mm: Fix unprotected access to struct device

On Tue, Apr 17, 2018 at 03:35:23PM +0200, Jacopo Mondi wrote: > With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping > operations observe dev->dma_pfn_offset") the generic DMA allocation > function on which the SH 'dma_alloc_coherent()' function relies on, > access the

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

Please send a v2.

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

On Mon, Apr 09, 2018 at 06:59:08PM +0200, Jacopo Mondi wrote: > I'm still a bit puzzled on what happens if dma_mmap_from_dev_coherent() fails. > Does a dma_mmap_from_dev_coherent() failure guarantee anyhow that the > successive virt_to_page() isn't problematic as it is today? > Or is it the >

Re: NVMe vs DMA addressing limitations

On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote: > That is an interesting question: We actually have the > "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements > it in the coherent interface, so that might be a good fit. Yes. my WIP HMB patch uses

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Tue, Jan 10, 2017 at 02:42:23PM +0100, Arnd Bergmann wrote: > It's a much rarer problem for the IOMMU case though, because it only > impacts devices that are restricted to addressing of less than 32-bits. > > If you have an IOMMU enabled, the dma-mapping interface does not care > if the device

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Tue, Jan 10, 2017 at 03:47:25PM +0300, Nikita Yushchenko wrote: > With this direction, semantics of dma mask becomes even more > questionable. I'd say dma_mask is candidate for removal (or to move to > swiotlb's or iommu's local area) We need the dma mask so that the device can advertise what

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote: > Another workaround me might need is to limit amount of concurrent DMA > in the NVMe driver based on some platform quirk. The way that NVMe works, > it can have very large amounts of data that is concurrently mapped into > the device.

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > 32-bit architectures without swiotlb (arc, arm, some mips32), and > there are several 64-bit architectures that do not have swiotlb > (alpha, parisc, s390, sparc). I

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: > I'm now working with HW that: > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, > and is being manufactured and developed, > - has 75% of it's RAM located beyond first 4G of address space, > - can't

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Mon, Jan 09, 2017 at 11:34:55PM +0300, Nikita Yushchenko wrote: > I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC > but in block layer, in particular it should be controlled by > blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it > is something

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

On Mon, Apr 25, 2016 at 04:26:19PM +0200, Niklas S?derlund wrote: > I have followed the call path from the usage in > drivers/dma/sh/rcar-dmac.c and made sure the dma_addr_t is not used in a > bad way. The dma-debug routines are called from the generic code in include/linux/dma-mapping.h, and

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

On Wed, Apr 13, 2016 at 03:29:17PM +0200, Niklas S?derlund wrote: > > Yes, it would be good to do an audit of all the ARM dma_ops as well > > as generic code like drivers/base/dma-*.c, lib/dma-debug.c and > > include/linux/dma-*.h What about things like the phys_addr() helper in lib/dma-debug.c?

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

On Thu, Mar 17, 2016 at 01:33:51PM +0200, Laurent Pinchart wrote: > The good news is that, given that no code uses this new API at the moment, > there isn't much to audit. The patch series implements the resource mapping > for arch/arm only, and makes use of it in the rcar-dmac driver only.

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

On Fri, Mar 11, 2016 at 01:58:46PM +0100, Niklas S?derlund wrote: > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are > the same and no special care is needed. However if you have a IOMMU you > need to map the DMA slave phys_addr_t to a dma_addr_t using something > like

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

Please add some documentation on where/how this should be used. It's not a very obvious interface.