summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'dma-mapping-4.13' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds2017-07-0775-725/+778
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull dma-mapping infrastructure from Christoph Hellwig: "This is the first pull request for the new dma-mapping subsystem In this new subsystem we'll try to properly maintain all the generic code related to dma-mapping, and will further consolidate arch code into common helpers. This pull request contains: - removal of the DMA_ERROR_CODE macro, replacing it with calls to ->mapping_error so that the dma_map_ops instances are more self contained and can be shared across architectures (me) - removal of the ->set_dma_mask method, which duplicates the ->dma_capable one in terms of functionality, but requires more duplicate code. - various updates for the coherent dma pool and related arm code (Vladimir) - various smaller cleanups (me)" * tag 'dma-mapping-4.13' of git://git.infradead.org/users/hch/dma-mapping: (56 commits) ARM: dma-mapping: Remove traces of NOMMU code ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus ARM: NOMMU: Introduce dma operations for noMMU drivers: dma-mapping: allow dma_common_mmap() for NOMMU drivers: dma-coherent: Introduce default DMA pool drivers: dma-coherent: Account dma_pfn_offset when used with device tree dma: Take into account dma_pfn_offset dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs dma-mapping: remove dmam_free_noncoherent crypto: qat - avoid an uninitialized variable warning au1100fb: remove a bogus dma_free_nonconsistent call MAINTAINERS: add entry for dma mapping helpers powerpc: merge __dma_set_mask into dma_set_mask dma-mapping: remove the set_dma_mask method powerpc/cell: use the dma_supported method for ops switching powerpc/cell: clean up fixed mapping dma_ops initialization tile: remove dma_supported and mapping_error methods xen-swiotlb: remove xen_swiotlb_set_dma_mask arm: implement ->dma_supported instead of ->set_dma_mask mips/loongson64: implement ->dma_supported instead of ->set_dma_mask ...
| * ARM: dma-mapping: Remove traces of NOMMU codeVladimir Murzin2017-06-301-27/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | DMA operations for NOMMU case have been just factored out into separate compilation unit, so don't keep dead code. Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpusVladimir Murzin2017-06-301-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now, we have dedicated non-cacheable region for consistent DMA operations. However, that region can still be marked as bufferable by MPU, so it'd be safer to have barriers by default. M-class machines that didn't need it until now also likely won't need it in the future, therefore, we offer this as an option. Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * ARM: NOMMU: Introduce dma operations for noMMUVladimir Murzin2017-06-304-4/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | R/M classes of cpus can have memory covered by MPU which in turn might configure RAM as Normal i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and friends, since data can stuck in caches now or be buffered. This patch factors out DMA support for NOMMU configuration into separate entity which provides dedicated dma_ops. We have to handle there several cases: - configurations with MMU/MPU setup - configurations without MMU/MPU setup - special case for M-class, since caches and MPU there are optional In general we rely on default DMA area for coherent allocations or/and per-device memory reserves suitable for coherent DMA, so if such regions are set coherent allocations go from there. In case MMU/MPU was not setup we fallback to normal page allocator for DMA memory allocation. In case we run M-class cpus, for configuration without cache support (like Cortex-M3/M4) dma operations are forced to be coherent and wired with dma-noop (such decision is made based on cacheid global variable); however, if caches are detected there and no DMA coherent region is given (either default or per-device), dma is disallowed even MPU is not set - it is because M-class implement system memory map which defines part of address space as Normal memory. Reported-by: Alexandre Torgue <alexandre.torgue@st.com> Reported-by: Andras Szemzo <sza@esh.hu> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> [hch: removed the dma_supported() implementation that isn't required anymore] Signed-off-by: Christoph Hellwig <hch@lst.de>
| * drivers: dma-mapping: allow dma_common_mmap() for NOMMUVladimir Murzin2017-06-307-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, internals of dma_common_mmap() is compiled out if build is done for either NOMMU or target which explicitly says it does not have/want coherent DMA mmap. It turned out that dma_common_mmap() can be handy in NOMMU setup (at least for ARM). This patch converts exitent NOMMU targets to use ARCH_NO_COHERENT_DMA_MMAP, thus when CONFIG_MMU is gone from dma_common_mmap() their behaviour stays unchanged. ARM is not converted to ARCH_NO_COHERENT_DMA_MMAP because it 1) already has mmap callback which can handle (at some extent) NOMMU 2) already defines dummy pgprot_noncached() for NOMMU build. c6x and frv stay untouched since they already have ARCH_NO_COHERENT_DMA_MMAP. Cc: Steven Miao <realmz6@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Michal Simek <monstr@monstr.eu> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
| * drivers: dma-coherent: Introduce default DMA poolVladimir Murzin2017-06-282-7/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces default coherent DMA pool similar to default CMA area concept. To keep other users safe code kept under CONFIG_ARM. Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * drivers: dma-coherent: Account dma_pfn_offset when used with device treeVladimir Murzin2017-06-281-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dma_declare_coherent_memory() and friends are designed to account difference in CPU and device addresses. However, when it is used with reserved memory regions there is assumption that CPU and device have the same view on address space. This assumption gets invalid when reserved memory for coherent DMA allocations is referenced by device with non-empty "dma-range" property. Simply feeding device address as rmem->base + dev->dma_pfn_offset would not work due to reserved memory region can be shared, so this patch turns device address to be expressed with help of CPU address and device's dma_pfn_offset in case memory reservation has been done via device tree; non device tree users continue to use the old scheme. Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Roger Quadros <rogerq@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * dma: Take into account dma_pfn_offsetVladimir Murzin2017-06-281-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though dma-noop-ops assumes 1:1 memory mapping DMA memory range can be different to RAM. For example, ARM STM32F4 MCU offers the possibility to remap SDRAM from 0xc000_0000 to 0x0 to get CPU performance boost, but DMA continue to see SDRAM at 0xc000_0000. This difference in mapping is handled via device-tree "dma-range" property which leads to dev->dma_pfn_offset is set nonzero. To handle such cases take dma_pfn_offset into account. Cc: Joerg Roedel <jroedel@suse.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Reported-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrsChristoph Hellwig2017-06-284-25/+23
| | | | | | | | | | | | | | | | | | dmam_alloc_noncoherent is a trivial wrapper around dmam_alloc_attrs, that hardcodes one particular flag. Make the devres code more flexible by allowing the callers to pass arbitrary flags. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Tejun Heo <tj@kernel.org>
| * dma-mapping: remove dmam_free_noncoherentChristoph Hellwig2017-06-283-23/+0
| | | | | | | | | | | | | | This function was never used since it was added. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Tejun Heo <tj@kernel.org>
| * crypto: qat - avoid an uninitialized variable warningArnd Bergmann2017-06-281-19/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 9e442aa6a753 ("x86: remove DMA_ERROR_CODE"), the inlining decisions in the qat driver changed slightly, introducing a new false-positive warning: drivers/crypto/qat/qat_common/qat_algs.c: In function 'qat_alg_sgl_to_bufl.isra.6': include/linux/dma-mapping.h:228:2: error: 'sz_out' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/crypto/qat/qat_common/qat_algs.c:676:9: note: 'sz_out' was declared here The patch that introduced this is correct, so let's just avoid the warning in this driver by rearranging the unwinding after an error to make it more obvious to the compiler what is going on. The problem here is the 'if (unlikely(dma_mapping_error(dev, blp)))' check, in which the 'unlikely' causes gcc to forget what it knew about the state of the variables. Cleaning up the dma state in the reverse order it was created means we can simplify the logic so it doesn't have to know about that state, and also makes it easier to understand. Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
| * au1100fb: remove a bogus dma_free_nonconsistent callChristoph Hellwig2017-06-281-4/+0
| | | | | | | | | | | | | | | | | | au1100fb is using managed dma allocations, so it doesn't need to explicitly free the dma memory in the error path (and if it did it would have to use the managed version). Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
| * MAINTAINERS: add entry for dma mapping helpersChristoph Hellwig2017-06-281-0/+15
| | | | | | | | | | | | | | | | | | | | This code has been spread between getting in through arch trees, the iommu tree, -mm and the drivers tree. There will be a lot of work in this area, including consolidating various arch implementations into more common code, so ensure we have a proper git tree that facilitates cooperation with the architecture maintainers. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * powerpc: merge __dma_set_mask into dma_set_maskChristoph Hellwig2017-06-282-10/+4
| | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de>
| * dma-mapping: remove the set_dma_mask methodChristoph Hellwig2017-06-282-10/+0
| | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de>
| * powerpc/cell: use the dma_supported method for ops switchingChristoph Hellwig2017-06-281-16/+9
| | | | | | | | | | | | | | Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * powerpc/cell: clean up fixed mapping dma_ops initializationChristoph Hellwig2017-06-281-20/+7
| | | | | | | | | | | | | | | | | | By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * tile: remove dma_supported and mapping_error methodsChristoph Hellwig2017-06-281-30/+0
| | | | | | | | | | | | These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * xen-swiotlb: remove xen_swiotlb_set_dma_maskChristoph Hellwig2017-06-281-12/+0
| | | | | | | | | | | | This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * arm: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig2017-06-281-4/+3
| | | | | | | | | | | | Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * mips/loongson64: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig2017-06-281-14/+5
| | | | | | | | | | | | Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * dma-mapping: remove HAVE_ARCH_DMA_SUPPORTEDChristoph Hellwig2017-06-281-2/+0
| | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de>
| * x86: remove arch specific dma_supported implementationChristoph Hellwig2017-06-289-11/+13
| | | | | | | | | | | | | | | | | | And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * arm: remove arch specific dma_supported implementationChristoph Hellwig2017-06-284-5/+8
| | | | | | | | | | | | | | | | | | And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * openrisc: remove arch-specific dma_supported implementationChristoph Hellwig2017-06-281-7/+0
| | | | | | | | | | | | | | | | This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * hexagon: remove the unused dma_is_consistent prototypeChristoph Hellwig2017-06-281-1/+0
| | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de>
| * hexagon: remove arch-specific dma_supported implementationChristoph Hellwig2017-06-282-11/+0
| | | | | | | | | | | | | | | | | | This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
| * dma-virt: remove dma_supported and mapping_error methodsChristoph Hellwig2017-06-281-12/+0
| | | | | | | | | | | | These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * dma-noop: remove dma_supported and mapping_error methodsChristoph Hellwig2017-06-281-12/+0
| | | | | | | | | | | | These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * sparc: remove arch specific dma_supported implementationsChristoph Hellwig2017-06-284-43/+39
| | | | | | | | | | | | | | | | | | | | | | Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which means always supported. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
| * sparc: remove leon_dma_opsChristoph Hellwig2017-06-282-6/+2
| | | | | | | | | | | | | | We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
| * dma-mapping: remove DMA_ERROR_CODEChristoph Hellwig2017-06-282-31/+5
| | | | | | | | | | | | | | And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * arm: implement ->mapping_errorChristoph Hellwig2017-06-284-19/+38
| | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * x86: remove DMA_ERROR_CODEChristoph Hellwig2017-06-281-2/+0
| | | | | | | | | | | | | | All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * x86/calgary: implement ->mapping_errorChristoph Hellwig2017-06-281-8/+16
| | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * x86/pci-nommu: implement ->mapping_errorChristoph Hellwig2017-06-281-1/+9
| | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * powerpc: implement ->mapping_errorChristoph Hellwig2017-06-286-19/+27
| | | | | | | | | | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
| * sparc: implement ->mapping_errorChristoph Hellwig2017-06-284-9/+21
| | | | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
| * s390: implement ->mapping_errorChristoph Hellwig2017-06-282-7/+13
| | | | | | | | | | | | | | | | | | s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
| * iommu/amd: implement ->mapping_errorChristoph Hellwig2017-06-281-5/+13
| | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * hexagon: switch to use ->mapping_error for error reportingChristoph Hellwig2017-06-283-6/+9
| | | | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
| * arm64: remove DMA_ERROR_CODEChristoph Hellwig2017-06-202-3/+1
| | | | | | | | | | | | | | | | | | | | | | The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
| * xtensa: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | | | xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * sh: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * openrisc: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * microblaze: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * m32r: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | | | dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * ia64: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-2/+0
| | | | | | | | | | | | All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig <hch@lst.de>
| * c6x: remove DMA_ERROR_CODEChristoph Hellwig2017-06-201-5/+0
| | | | | | | | Signed-off-by: Christoph Hellwig <hch@lst.de>
| * xen-swiotlb: implement ->mapping_errorChristoph Hellwig2017-06-201-2/+10
| | | | | | | | | | | | | | DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-15 10:22:28 +0100