kernel/linux.git/arch/sh/mm/consistent.c, branch linux-5.9.y

sh: remove call to memset after dma_alloc_coherent

2020-08-15T02:05:03+00:00

Function dma_alloc_coherent use in buf already zeroes out memory, so memset is not needed. Signed-off-by: Chen Zhou Signed-off-by: Rich Felker

sh: Use pr_warn instead of pr_warning

2019-10-18T11:52:05+00:00

As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent _warn style. Let's do it. Link: http://lkml.kernel.org/r/20191018031850.48498-5-wangkefeng.wang@huawei.com To: linux-kernel@vger.kernel.org Cc: Stephen Rothwell Cc: Yoshinori Sato Cc: Rich Felker Signed-off-by: Kefeng Wang Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

sh: split arch/sh/mm/consistent.c

2018-08-02T11:54:15+00:00

Half of the file just contains platform device memory setup code which is required for all builds, and half contains helpers for dma coherent allocation, which is only needed if CONFIG_DMA_NONCOHERENT is enabled. Signed-off-by: Christoph Hellwig Acked-by: Yoshinori Sato

sh: introduce a sh_cacheop_vaddr helper

2018-08-02T11:54:06+00:00

And use it in the maple bus code to avoid a dma API dependency. Signed-off-by: Christoph Hellwig Acked-by: Yoshinori Sato

sh: simplify get_arch_dma_ops

2018-08-02T11:54:01+00:00

Remove the indirection through the dma_ops variable, and just return nommu_dma_ops directly from get_arch_dma_ops. Signed-off-by: Christoph Hellwig Acked-by: Yoshinori Sato

Merge tag 'dma-mapping-4.18' of git://git.infradead.org/users/hch/dma-mapping

2018-06-04T17:58:12+00:00

Pull dma-mapping updates from Christoph Hellwig: - replace the force_dma flag with a dma_configure bus method. (Nipun Gupta, although one patch is іncorrectly attributed to me due to a git rebase bug) - use GFP_DMA32 more agressively in dma-direct. (Takashi Iwai) - remove PCI_DMA_BUS_IS_PHYS and rely on the dma-mapping API to do the right thing for bounce buffering. - move dma-debug initialization to common code, and apply a few cleanups to the dma-debug code. - cleanup the Kconfig mess around swiotlb selection - swiotlb comment fixup (Yisheng Xie) - a trivial swiotlb fix. (Dan Carpenter) - support swiotlb on RISC-V. (based on a patch from Palmer Dabbelt) - add a new generic dma-noncoherent dma_map_ops implementation and use it for arc, c6x and nds32. - improve scatterlist validity checking in dma-debug. (Robin Murphy) - add a struct device quirk to limit the dma-mask to 32-bit due to bridge/system issues, and switch x86 to use it instead of a local hack for VIA bridges. - handle devices without a dma_mask more gracefully in the dma-direct code. * tag 'dma-mapping-4.18' of git://git.infradead.org/users/hch/dma-mapping: (48 commits) dma-direct: don't crash on device without dma_mask nds32: use generic dma_noncoherent_ops nds32: implement the unmap_sg DMA operation nds32: consolidate DMA cache maintainance routines x86/pci-dma: switch the VIA 32-bit DMA quirk to use the struct device flag x86/pci-dma: remove the explicit nodac and allowdac option x86/pci-dma: remove the experimental forcesac boot option Documentation/x86: remove a stray reference to pci-nommu.c core, dma-direct: add a flag 32-bit dma limits dma-mapping: remove unused gfp_t parameter to arch_dma_alloc_attrs dma-debug: check scatterlist segments c6x: use generic dma_noncoherent_ops arc: use generic dma_noncoherent_ops arc: fix arc_dma_{map,unmap}_page arc: fix arc_dma_sync_sg_for_{cpu,device} arc: simplify arc_dma_sync_single_for_{cpu,device} dma-mapping: provide a generic dma-noncoherent implementation dma-mapping: simplify Kconfig dependencies riscv: add swiotlb support riscv: only enable ZONE_DMA32 for 64-bit ...

dma-debug: move initialization to common code

2018-05-08T11:02:42+00:00

Most mainstream architectures are using 65536 entries, so lets stick to that. If someone is really desperate to override it that can still be done through , but I'd rather see a really good rationale for that. dma_debug_init is now called as a core_initcall, which for many architectures means much earlier, and provides dma-debug functionality earlier in the boot process. This should be safe as it only relies on the memory allocator already being available. Signed-off-by: Christoph Hellwig Acked-by: Marek Szyprowski Reviewed-by: Robin Murphy

sh: mm: Fix unprotected access to struct device

2018-05-05T20:51:46+00:00

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, accesses the 'dma_pfn_offset' field of struct device. Unfortunately the 'dma_generic_alloc_coherent()' function is called from several places with a NULL struct device argument, halting the CPU during the boot process. This patch fixes the issue by protecting access to dev->dma_pfn_offset, with a trivial check for validity. It also passes a valid 'struct device' in the 'platform_resource_setup_memory()' function which is the main user of 'dma_alloc_coherent()', and inserts a WARN_ON() check to remind to future (and existing) bogus users of this function to provide a valid 'struct device' whenever possible. Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset") Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Thomas Petazzoni Signed-off-by: Rich Felker

arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset

2018-04-12T23:47:53+00:00

Some devices may have a non-zero DMA offset, i.e an offset between the DMA address and the physical address. Such an offset can be encoded into the dma_pfn_offset field of "struct device", but the SuperH implementation of the DMA mapping API does not observe this information. This commit fixes that by ensuring the DMA address is properly calculated depending on this DMA offset. Signed-off-by: Thomas Petazzoni Signed-off-by: Rich Felker

sh: make dma_cache_sync a no-op

2017-10-19T14:37:44+00:00

sh does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. On the other hand sh uses dma_cache_sync internally in the dma_ops implementation and for the maple bus that does not use the DMA API, so a the old functionality for dma_cache_sync is still provided under the name sh_sync_dma_for_device, and without the redundant dev argument. While at it two of the syncing dma_ops also go the proper _for_device postfix. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy