Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: The arm-smmu driver can COMPILE_TEST on x86, so expand this to also enable the IORT code so it can be COMPILE_TEST'd too. Signed-off-by: Jason Gunthorpe --- drivers/acpi/Kconfig| 2 -- drivers/acpi/Makefile | 2 +-

Re: [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: The iommu_device_lock protects the iommu_device_list which is only read by iommu_ops_from_fwnode(). This is now always called under the iommu_probe_device_lock, so we don't need to double lock the linked list. Use the iommu_probe_device_lock on the

Re: [PATCH v2 00/17] Solve iommu probe races around iommu_fwspec

On 2023-11-16 4:17 am, Jason Gunthorpe wrote: On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote: On 2023-11-15 3:36 pm, Jason Gunthorpe wrote: On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote: On 2023-11-15 2:05 pm, Jason Gunthorpe wrote: [Several people have tested

Re: [PATCH v2 00/17] Solve iommu probe races around iommu_fwspec

On 2023-11-15 3:36 pm, Jason Gunthorpe wrote: On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote: On 2023-11-15 2:05 pm, Jason Gunthorpe wrote: [Several people have tested this now, so it is something that should sit in linux-next for a while] What's the aim here? This is obviously

Re: [PATCH v2 00/17] Solve iommu probe races around iommu_fwspec

On 2023-11-15 2:05 pm, Jason Gunthorpe wrote: [Several people have tested this now, so it is something that should sit in linux-next for a while] What's the aim here? This is obviously far, far too much for a stable fix, but then it's also not the refactoring we want for the future either,

Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O functions

On 2023-04-28 10:27, Thomas Zimmermann wrote: Implement framebuffer I/O helpers, such as fb_read*() and fb_write*() with Linux' regular I/O functions. Remove all ifdef cases for the various architectures. Most of the supported architectures use __raw_() I/O functions or treat framebuffer memory

Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper

On 31/03/2023 3:00 pm, Arnd Bergmann wrote: On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote: On 2023-03-27 13:13, Arnd Bergmann wrote: [ HELP NEEDED: can anyone confirm that it is a correct assumption on arm that a cache-coherent device writing to a page always results in it being

Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper

On 2023-03-27 13:13, Arnd Bergmann wrote: From: Arnd Bergmann The arm version of the arch_sync_dma_for_cpu() function annotates pages as PG_dcache_clean after a DMA, but no other architecture does this here. On ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense to use

Re: [PATCH 08/14] arm64: simplify access_ok()

at the 7-instruction sequence that Mark and I had come up with and certain that it could be shortened still. Kinda sad to see it go, but at the same time, glad that it can. Acked-by: Robin Murphy On a defconfig build, this saves over 28KB of .text. Not to mention saving those "WTF is

Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices

On 08/12/2018 17:36, Christoph Hellwig wrote: There is no need to have an additional kernel mapping for a contiguous allocation if the device already is DMA coherent, so skip it. FWIW, the "need" was that it kept the code in this path simple and the mapping behaviour consistent with the

Re: 'branches' perf event mapping differs on ARC and ARM

On 27/11/2018 14:36, Eugeniy Paltsev wrote: Hi, While playing with perf tool on ARMv7 and ARCv2 processors and profiling the same application I got interesting results. Even if we got pretty similar total execution time and instructions number the number of branches on ARC is about three times

Re: [PATCH 3/3] dma-debug: unexport dma_debug_resize_entries and debug_dma_dump_mappings

-level dma-debug internals *only* called by a couple of IOMMU drivers, but that can wait for another day. Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- lib/dma-debug.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/dma-d

Re: [PATCH 4/3] dma-debug: remove CONFIG_HAVE_DMA_API_DEBUG

On 27/04/18 16:53, Christoph Hellwig wrote: There is no arch specific code required for dma-debug, so there is no need to opt into the support either. Makes sense, and a purely negative diffstat is always pleasing :) Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Chr

Re: [PATCH 2/3] dma-debug: simplify counting of preallocated requests

On 24/04/18 15:02, Christoph Hellwig wrote: Just keep a single variable with a descriptive name instead of two with confusing names. Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- lib/dma-debug.c | 20 -

Re: [PATCH 1/3] dma-debug: move initialization to common code

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. Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Christoph Hell

Re: [PATCH 01/22] dma-debug: move initialization to common code

Hi Christoph, Nice cleanup! Looks good overall, just a couple of nits. On 20/04/18 09:02, Christoph Hellwig wrote: [...] diff --git a/lib/dma-debug.c b/lib/dma-debug.c index 7f5cdc1e6b29..712a897174e4 100644 --- a/lib/dma-debug.c +++ b/lib/dma-debug.c @@ -41,6 +41,11 @@ #define HASH_FN_SHIFT

Re: [PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

On 10/04/18 16:25, Laurent Dufour wrote: Remove the additional define HAVE_PTE_SPECIAL and rely directly on CONFIG_ARCH_HAS_PTE_SPECIAL. There is no functional change introduced by this patch Signed-off-by: Laurent Dufour --- mm/memory.c | 23

Re: [RFC PATCH 6/6] arch: add untagged_addr definition for other arches

On 09/03/18 14:02, Andrey Konovalov wrote: To allow arm64 syscalls accept tagged pointers from userspace, we must untag them when they are passed to the kernel. Since untagging is done in generic parts of the kernel (like the mm subsystem), the untagged_addr macro should be defined for all

Re: [PATCH 31/33] dma-direct: reject too small dma masks

On 10/01/18 15:32, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote: +#ifdef CONFIG_ZONE_DMA + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)) + return 0; +#else + /* +* Because 32-bit DMA masks are so common we expect ev

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

On 10/01/18 15:30, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote: On 10/01/18 08:00, Christoph Hellwig wrote: To preserve the x86 behavior. And combined with patch 10/22 of the SWIOTLB refactoring, this means SWIOTLB allocations will also end up NUMA

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 08:00, Christoph Hellwig wrote: phys_to_dma, dma_to_phys and dma_capable are helpers published by architecture code for use of swiotlb and xen-swiotlb only. Drivers are not supposed to use these directly, but use the DMA API instead. Move these to a new asm/dma-direct.h helper,

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

On 10/01/18 08:00, Christoph Hellwig wrote: To preserve the x86 behavior. And combined with patch 10/22 of the SWIOTLB refactoring, this means SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what we want on arm64 too :) Reviewed-by: Robin Murphy <robin.mur...@arm.

Re: [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

On 10/01/18 08:00, Christoph Hellwig wrote: [...] diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 9f28b2fa329e..88bcb1a8211d 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -518,6 +518,13 @@ static inline void *dma_alloc_attrs(struct

Re: [PATCH 31/33] dma-direct: reject too small dma masks

masks for older hardware which probably associates with host systems packing equivalently small amounts of RAM. Otherwise though, Reviewed-by: Robin Murphy <robin.mur...@arm.com> Robin. +#endif + return 1; +} + static int dma_direct_mapping_error(struct device *dev

Re: [PATCH 10/33] arm64: don't override dma_max_pfn

On 10/01/18 08:00, Christoph Hellwig wrote: The generic version now takes dma_pfn_offset into account, so there is no more need for an architecture override. Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- arch/arm64/inc

Re: [PATCH 09/33] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

On 10/01/18 08:00, Christoph Hellwig wrote: This makes sure the generic version can be used with architectures / devices that have a DMA offset in the direct mapping. Reviewed-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- inclu

Re: [PATCH v4 43/44] dma-mapping: Remove dma_get_attr

te to me; thanks! For arm64 and dma-iommu: Acked-by: Robin Murphy <robin.mur...@arm.com> ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc