- 11 Dec, 2018 3 commits
-
-
Robin Murphy authored
Certain drivers such as large multi-queue network adapters can use pools of mapped DMA buffers larger than the default dma_debug_entry pool of 65536 entries, with the result that merely probing such a device can cause DMA debug to disable itself during boot unless explicitly given an appropriate "dma_debug_entries=..." option. Developers trying to debug some other driver on such a system may not be immediately aware of this, and at worst it can hide bugs if they fail to realise that dma-debug has already disabled itself unexpectedly by the time their code of interest gets to run. Even once they do realise, it can be a bit of a pain to emprirically determine a suitable number of preallocated entries to configure, short of massively over-allocating. There's really no need for such a static limit, though, since we can quite easily expand the pool at runtime in those rare cases that the preallocated entries are insufficient, which is arguably the least surprising and most useful behaviour. To that end, refactor the prealloc_memory() logic a little bit to generalise it for runtime reallocations as well. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Tested-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
Robin Murphy authored
Use pr_fmt() to generate the "DMA-API: " prefix consistently. This results in it being added to a couple of pr_*() messages which were missing it before, and for the err_printk() calls moves it to the actual start of the message instead of somewhere in the middle. Signed-off-by:
-
Robin Murphy authored
Expose nr_total_entries in debugfs, so that {num,min}_free_entries become even more meaningful to users interested in current/maximum utilisation. This becomes even more relevant once nr_total_entries may change at runtime beyond just the existing AMD GART debug code. Suggested-by:John Garry <john.garry@huawei.com> Signed-off-by:
-
- 06 Dec, 2018 24 commits
-
-
Christoph Hellwig authored
These days architectures are mostly out of the business of dealing with struct scatterlist at all, unless they have architecture specific iommu drivers. Replace the ARCH_HAS_SG_CHAIN symbol with a ARCH_NO_SG_CHAIN one only enabled for architectures with horrible legacy iommu drivers like alpha and parisc, and conditionally for arm which wants to keep it disable for legacy platforms. Signed-off-by:
Palmer Dabbelt <palmer@sifive.com>
-
Christoph Hellwig authored
Currently dma_mapping_error returns a boolean as int, with 1 meaning error. This is rather unusual and many callers have to convert it to errno value. The callers are highly inconsistent with error codes ranging from -ENOMEM over -EIO, -EINVAL and -EFAULT ranging to -EAGAIN. Return -ENOMEM which seems to be what the largest number of callers convert it to, and which also matches the typical error case where we are out of resources. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Christoph Hellwig authored
No users left except for vmd which just forwards it. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Pass the page + offset to the low-level __iommu_map_single helper (which gets renamed to fit the new calling conventions) as both callers have the page at hand. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Note that the existing code used AMD_IOMMU_MAPPING_ERROR to check from a 0 return from the IOVA allocator, which is replaced with an explicit 0 as in the implementation and other users of that interface. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma mapping failure and let the core dma-mapping code handle the rest. Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma mapping failure and let the core dma-mapping code handle the rest. Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Remove the odd sba_{un,}map_single_attrs wrappers, check errors everywhere. Signed-off-by: -
Christoph Hellwig authored
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Just return DMA_MAPPING_ERROR from __dummy_map_page and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
The SBA iommu code already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
The CCIO iommu code already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Sparc already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
S390 already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
The Jazz iommu code already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
The powerpc iommu code already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Arm already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
The dma-direct code already returns (~(dma_addr_t)0x0) on mapping failures, so we can switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping code handle the rest. Signed-off-by:
-
Christoph Hellwig authored
Error handling of the dma_map_single and dma_map_page APIs is a little problematic at the moment, in that we use different encodings in the returned dma_addr_t to indicate an error. That means we require an additional indirect call to figure out if a dma mapping call returned an error, and a lot of boilerplate code to implement these semantics. Instead return the maximum addressable value as the error. As long as we don't allow mapping single-byte ranges with single-byte alignment this value can never be a valid return. Additionaly if drivers do not check the return value from the dma_map* routines this values means they will generally not be pointed to actual memory. Once the default value is added here we can start removing the various mapping_error methods and just rely on this generic check. Signed-off-by:
-
- 05 Dec, 2018 1 commit
-
-
Marek Szyprowski authored
Commit bfd56cd6 ("dma-mapping: support highmem in the generic remap allocator") replaced dma_direct_alloc_pages() with __dma_direct_alloc_pages(), which doesn't set dma_handle and zero allocated memory. Fix it by doing this directly in the caller function. Fixes: bfd56cd6 ("dma-mapping: support highmem in the generic remap allocator") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 01 Dec, 2018 9 commits
-
-
Christoph Hellwig authored
The csky code was largely copied from arm/arm64, so switch to the generic arm64-based implementation instead. Signed-off-by:
Guo Ren <ren_guo@c-sky.com>
-
Christoph Hellwig authored
csky does not implement ZONE_DMA, which means passing GFP_DMA is a no-op. Signed-off-by:
-
Christoph Hellwig authored
This option is gone past Linux 4.19. Signed-off-by:
-
Christoph Hellwig authored
Do not waste vmalloc space on allocations that do not require a mapping into the kernel address space. Signed-off-by:
-
Christoph Hellwig authored
By using __dma_direct_alloc_pages we can deal entirely with struct page instead of having to derive a kernel virtual address. Signed-off-by:
-
Christoph Hellwig authored
The arm64 codebase to implement coherent dma allocation for architectures with non-coherent DMA is a good start for a generic implementation, given that is uses the generic remap helpers, provides the atomic pool for allocations that can't sleep and still is realtively simple and well tested. Move it to kernel/dma and allow architectures to opt into it using a config symbol. Architectures just need to provide a new arch_dma_prep_coherent helper to writeback an invalidate the caches for any memory that gets remapped for uncached access. Signed-off-by:
Will Deacon <will.deacon@arm.com> Reviewed-by:
-
Christoph Hellwig authored
The dma remap code only makes sense for not cache coherent architectures (or possibly the corner case of highmem CMA allocations) and currently is only used by arm, arm64, csky and xtensa. Split it out into a separate file with a separate Kconfig symbol, which gets the right copyright notice given that this code was written by Laura Abbott working for Code Aurora at that point. Signed-off-by:
Laura Abbott <labbott@redhat.com> Reviewed-by:
-
Christoph Hellwig authored
dma_alloc_from_contiguous can return highmem pages depending on the setup, which a plain non-remapping DMA allocator can't handle. Detect this case and fail the allocation. Signed-off-by:
-
Christoph Hellwig authored
Some architectures support remapping highmem into DMA coherent allocations. To use the common code for them we need variants of dma_direct_{alloc,free}_pages that do not use kernel virtual addresses. Signed-off-by:
-
- 27 Nov, 2018 2 commits
-
-
Niklas Söderlund authored
The function dma_set_max_seg_size() can return either 0 on success or -EIO on error. Change its return type from unsigned int to int to capture this. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Matias Bjørling authored
The numa_slit variable used by node_distance is available to a module as long as it is linked at compile-time. However, it is not available to loadable modules. Leading to errors such as: ERROR: "numa_slit" [drivers/nvme/host/nvme-core.ko] undefined! The error above is caused by the nvme multipath code that makes use of node_distance for its path calculation. When the patch was added, the lightnvm subsystem would select nvme and always compile it in, leading to the node_distance call to always succeed. However, when this requirement was removed, nvme could be compiled in as a module, which exposed this bug. This patch extracts node_distance to a function and exports it. Since ACPI is depending on node_distance being a simple lookup to numa_slit, the previous behavior is exposed as slit_distance and its users updated. Fixes: f3334447 "nvme: take node locality into account when selecting a path" Fixes: 73569e11 "lightnvm: remove dependencies on BLK_DEV_NVME and PCI" Signed-off-by:
Matias Bjøring <mb@lightnvm.io> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
- 26 Nov, 2018 1 commit
-
-
Linus Torvalds authored
Merge tag 'hwmon-for-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - fix temp4_type attribute permissions in w83795 driver - fix tacho fault detection in mlxreg-fan driver - fix current value calculations in ina2xx driver - fix initial notification/warning in raspberrypi driver - fix a NULL pointer access in ina2xx * tag 'hwmon-for-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (w83795) temp4_type has writable permission hwmon: (mlxreg-fan) Fix macros for tacho fault reading hwmon: (ina2xx) Fix current value calculation hwmon: (raspberrypi) Fix initial notify hwmon (ina2xx) Fix NULL id pointer in probe()
-
