* [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:28 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:28 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy
Cc: Nicolas Saenz Julienne, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
linux-arm-kernel, linux-kernel, linuxppc-dev, linux-s390, iommu
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since RFC:
- Rebased to v5.4-rc6, fixed arm64 code.
NOTE: This will only apply to linux-next, where
arch/arm64/mm/init.c | 5 +++++
arch/powerpc/include/asm/page.h | 9 ---------
arch/powerpc/mm/mem.c | 20 +++++++++++++++-----
arch/s390/include/asm/page.h | 2 --
arch/s390/mm/init.c | 1 +
include/linux/dma-direct.h | 2 ++
kernel/dma/direct.c | 13 ++++++-------
7 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a54909c..f716ea634804 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -20,6 +20,7 @@
#include <linux/sort.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/dma-direct.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
@@ -41,6 +42,8 @@
#include <asm/tlb.h>
#include <asm/alternative.h>
+#define ARM64_ZONE_DMA_BITS 30
+
/*
* We need to be able to catch inadvertent references to memstart_addr
* that occur (potentially in generic code) before arm64_memblock_init()
@@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ zone_dma_bits = ARM64_ZONE_DMA_BITS;
+
reserve_crashkernel();
reserve_elfcorehdr();
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index c8bb14ff4713..f6c562acc3f8 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -329,13 +329,4 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
-/*
- * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
- */
-#ifdef CONFIG_PPC32
-#define ARCH_ZONE_DMA_BITS 30
-#else
-#define ARCH_ZONE_DMA_BITS 31
-#endif
-
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index be941d382c8d..c95b7fe9f298 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/memremap.h>
+#include <linux/dma-direct.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
@@ -201,10 +202,10 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
- * inform the generic DMA mapping code. 32-bit only devices (if not handled
- * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
- * otherwise served by ZONE_DMA.
+ * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
+ * anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
+ * ZONE_DMA.
*/
static unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -237,9 +238,18 @@ void __init paging_init(void)
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
(long int)((top_of_ram - total_ram) >> 20));
+ /*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many
+ * powerbooks.
+ */
+ if (IS_ENABLED(CONFIG_PPC32))
+ zone_dma_bits = 30;
+ else
+ zone_dma_bits = 31;
+
#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (ARCH_ZONE_DMA_BITS - PAGE_SHIFT));
+ 1UL << (zone_dma_bits - PAGE_SHIFT));
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
index 823578c6b9e2..a4d38092530a 100644
--- a/arch/s390/include/asm/page.h
+++ b/arch/s390/include/asm/page.h
@@ -177,8 +177,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-#define ARCH_ZONE_DMA_BITS 31
-
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index a124f19f7b3c..f0ce22220565 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -118,6 +118,7 @@ void __init paging_init(void)
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
+ zone_dma_bits = 31;
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = PFN_DOWN(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index adf993a3bd58..d03af3605460 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -5,6 +5,8 @@
#include <linux/dma-mapping.h>
#include <linux/mem_encrypt.h>
+extern unsigned int zone_dma_bits;
+
#ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
#include <asm/dma-direct.h>
#else
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8402b29c280f..0b67c04e531b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -16,12 +16,11 @@
#include <linux/swiotlb.h>
/*
- * Most architectures use ZONE_DMA for the first 16 Megabytes, but
- * some use it for entirely different regions:
+ * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
+ * it for entirely different regions. In that case the arch code needs to
+ * override the variable below for dma-direct to work properly.
*/
-#ifndef ARCH_ZONE_DMA_BITS
-#define ARCH_ZONE_DMA_BITS 24
-#endif
+unsigned int zone_dma_bits __ro_after_init = 24;
static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
{
@@ -69,7 +68,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
* Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
* zones.
*/
- if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
return GFP_DMA;
if (*phys_mask <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -395,7 +394,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
u64 min_mask;
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
+ min_mask = DMA_BIT_MASK(zone_dma_bits);
else
min_mask = DMA_BIT_MASK(32);
--
2.23.0
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:28 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:28 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy
Cc: linux-s390, Vasily Gorbik, Catalin Marinas, linuxppc-dev,
Heiko Carstens, linux-kernel, Christian Borntraeger, iommu,
Paul Mackerras, linux-arm-kernel, Will Deacon,
Nicolas Saenz Julienne
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since RFC:
- Rebased to v5.4-rc6, fixed arm64 code.
NOTE: This will only apply to linux-next, where
arch/arm64/mm/init.c | 5 +++++
arch/powerpc/include/asm/page.h | 9 ---------
arch/powerpc/mm/mem.c | 20 +++++++++++++++-----
arch/s390/include/asm/page.h | 2 --
arch/s390/mm/init.c | 1 +
include/linux/dma-direct.h | 2 ++
kernel/dma/direct.c | 13 ++++++-------
7 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a54909c..f716ea634804 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -20,6 +20,7 @@
#include <linux/sort.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/dma-direct.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
@@ -41,6 +42,8 @@
#include <asm/tlb.h>
#include <asm/alternative.h>
+#define ARM64_ZONE_DMA_BITS 30
+
/*
* We need to be able to catch inadvertent references to memstart_addr
* that occur (potentially in generic code) before arm64_memblock_init()
@@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ zone_dma_bits = ARM64_ZONE_DMA_BITS;
+
reserve_crashkernel();
reserve_elfcorehdr();
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index c8bb14ff4713..f6c562acc3f8 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -329,13 +329,4 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
-/*
- * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
- */
-#ifdef CONFIG_PPC32
-#define ARCH_ZONE_DMA_BITS 30
-#else
-#define ARCH_ZONE_DMA_BITS 31
-#endif
-
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index be941d382c8d..c95b7fe9f298 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/memremap.h>
+#include <linux/dma-direct.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
@@ -201,10 +202,10 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
- * inform the generic DMA mapping code. 32-bit only devices (if not handled
- * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
- * otherwise served by ZONE_DMA.
+ * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
+ * anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
+ * ZONE_DMA.
*/
static unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -237,9 +238,18 @@ void __init paging_init(void)
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
(long int)((top_of_ram - total_ram) >> 20));
+ /*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many
+ * powerbooks.
+ */
+ if (IS_ENABLED(CONFIG_PPC32))
+ zone_dma_bits = 30;
+ else
+ zone_dma_bits = 31;
+
#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (ARCH_ZONE_DMA_BITS - PAGE_SHIFT));
+ 1UL << (zone_dma_bits - PAGE_SHIFT));
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
index 823578c6b9e2..a4d38092530a 100644
--- a/arch/s390/include/asm/page.h
+++ b/arch/s390/include/asm/page.h
@@ -177,8 +177,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-#define ARCH_ZONE_DMA_BITS 31
-
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index a124f19f7b3c..f0ce22220565 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -118,6 +118,7 @@ void __init paging_init(void)
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
+ zone_dma_bits = 31;
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = PFN_DOWN(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index adf993a3bd58..d03af3605460 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -5,6 +5,8 @@
#include <linux/dma-mapping.h>
#include <linux/mem_encrypt.h>
+extern unsigned int zone_dma_bits;
+
#ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
#include <asm/dma-direct.h>
#else
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8402b29c280f..0b67c04e531b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -16,12 +16,11 @@
#include <linux/swiotlb.h>
/*
- * Most architectures use ZONE_DMA for the first 16 Megabytes, but
- * some use it for entirely different regions:
+ * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
+ * it for entirely different regions. In that case the arch code needs to
+ * override the variable below for dma-direct to work properly.
*/
-#ifndef ARCH_ZONE_DMA_BITS
-#define ARCH_ZONE_DMA_BITS 24
-#endif
+unsigned int zone_dma_bits __ro_after_init = 24;
static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
{
@@ -69,7 +68,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
* Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
* zones.
*/
- if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
return GFP_DMA;
if (*phys_mask <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -395,7 +394,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
u64 min_mask;
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
+ min_mask = DMA_BIT_MASK(zone_dma_bits);
else
min_mask = DMA_BIT_MASK(32);
--
2.23.0
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:28 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:28 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy
Cc: linux-s390, Benjamin Herrenschmidt, Vasily Gorbik,
Catalin Marinas, linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Nicolas Saenz Julienne
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since RFC:
- Rebased to v5.4-rc6, fixed arm64 code.
NOTE: This will only apply to linux-next, where
arch/arm64/mm/init.c | 5 +++++
arch/powerpc/include/asm/page.h | 9 ---------
arch/powerpc/mm/mem.c | 20 +++++++++++++++-----
arch/s390/include/asm/page.h | 2 --
arch/s390/mm/init.c | 1 +
include/linux/dma-direct.h | 2 ++
kernel/dma/direct.c | 13 ++++++-------
7 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a54909c..f716ea634804 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -20,6 +20,7 @@
#include <linux/sort.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/dma-direct.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
@@ -41,6 +42,8 @@
#include <asm/tlb.h>
#include <asm/alternative.h>
+#define ARM64_ZONE_DMA_BITS 30
+
/*
* We need to be able to catch inadvertent references to memstart_addr
* that occur (potentially in generic code) before arm64_memblock_init()
@@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ zone_dma_bits = ARM64_ZONE_DMA_BITS;
+
reserve_crashkernel();
reserve_elfcorehdr();
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index c8bb14ff4713..f6c562acc3f8 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -329,13 +329,4 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
-/*
- * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
- */
-#ifdef CONFIG_PPC32
-#define ARCH_ZONE_DMA_BITS 30
-#else
-#define ARCH_ZONE_DMA_BITS 31
-#endif
-
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index be941d382c8d..c95b7fe9f298 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/memremap.h>
+#include <linux/dma-direct.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
@@ -201,10 +202,10 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
- * inform the generic DMA mapping code. 32-bit only devices (if not handled
- * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
- * otherwise served by ZONE_DMA.
+ * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
+ * anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
+ * ZONE_DMA.
*/
static unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -237,9 +238,18 @@ void __init paging_init(void)
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
(long int)((top_of_ram - total_ram) >> 20));
+ /*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many
+ * powerbooks.
+ */
+ if (IS_ENABLED(CONFIG_PPC32))
+ zone_dma_bits = 30;
+ else
+ zone_dma_bits = 31;
+
#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (ARCH_ZONE_DMA_BITS - PAGE_SHIFT));
+ 1UL << (zone_dma_bits - PAGE_SHIFT));
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
index 823578c6b9e2..a4d38092530a 100644
--- a/arch/s390/include/asm/page.h
+++ b/arch/s390/include/asm/page.h
@@ -177,8 +177,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-#define ARCH_ZONE_DMA_BITS 31
-
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index a124f19f7b3c..f0ce22220565 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -118,6 +118,7 @@ void __init paging_init(void)
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
+ zone_dma_bits = 31;
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = PFN_DOWN(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index adf993a3bd58..d03af3605460 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -5,6 +5,8 @@
#include <linux/dma-mapping.h>
#include <linux/mem_encrypt.h>
+extern unsigned int zone_dma_bits;
+
#ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
#include <asm/dma-direct.h>
#else
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8402b29c280f..0b67c04e531b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -16,12 +16,11 @@
#include <linux/swiotlb.h>
/*
- * Most architectures use ZONE_DMA for the first 16 Megabytes, but
- * some use it for entirely different regions:
+ * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
+ * it for entirely different regions. In that case the arch code needs to
+ * override the variable below for dma-direct to work properly.
*/
-#ifndef ARCH_ZONE_DMA_BITS
-#define ARCH_ZONE_DMA_BITS 24
-#endif
+unsigned int zone_dma_bits __ro_after_init = 24;
static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
{
@@ -69,7 +68,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
* Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
* zones.
*/
- if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
return GFP_DMA;
if (*phys_mask <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -395,7 +394,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
u64 min_mask;
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
+ min_mask = DMA_BIT_MASK(zone_dma_bits);
else
min_mask = DMA_BIT_MASK(32);
--
2.23.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:28 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:28 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy
Cc: linux-s390, Benjamin Herrenschmidt, Vasily Gorbik,
Catalin Marinas, linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Nicolas Saenz Julienne
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since RFC:
- Rebased to v5.4-rc6, fixed arm64 code.
NOTE: This will only apply to linux-next, where
arch/arm64/mm/init.c | 5 +++++
arch/powerpc/include/asm/page.h | 9 ---------
arch/powerpc/mm/mem.c | 20 +++++++++++++++-----
arch/s390/include/asm/page.h | 2 --
arch/s390/mm/init.c | 1 +
include/linux/dma-direct.h | 2 ++
kernel/dma/direct.c | 13 ++++++-------
7 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a54909c..f716ea634804 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -20,6 +20,7 @@
#include <linux/sort.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/dma-direct.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
@@ -41,6 +42,8 @@
#include <asm/tlb.h>
#include <asm/alternative.h>
+#define ARM64_ZONE_DMA_BITS 30
+
/*
* We need to be able to catch inadvertent references to memstart_addr
* that occur (potentially in generic code) before arm64_memblock_init()
@@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ zone_dma_bits = ARM64_ZONE_DMA_BITS;
+
reserve_crashkernel();
reserve_elfcorehdr();
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index c8bb14ff4713..f6c562acc3f8 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -329,13 +329,4 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
-/*
- * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
- */
-#ifdef CONFIG_PPC32
-#define ARCH_ZONE_DMA_BITS 30
-#else
-#define ARCH_ZONE_DMA_BITS 31
-#endif
-
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index be941d382c8d..c95b7fe9f298 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/memremap.h>
+#include <linux/dma-direct.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
@@ -201,10 +202,10 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
- * inform the generic DMA mapping code. 32-bit only devices (if not handled
- * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
- * otherwise served by ZONE_DMA.
+ * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
+ * anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
+ * ZONE_DMA.
*/
static unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -237,9 +238,18 @@ void __init paging_init(void)
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
(long int)((top_of_ram - total_ram) >> 20));
+ /*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many
+ * powerbooks.
+ */
+ if (IS_ENABLED(CONFIG_PPC32))
+ zone_dma_bits = 30;
+ else
+ zone_dma_bits = 31;
+
#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (ARCH_ZONE_DMA_BITS - PAGE_SHIFT));
+ 1UL << (zone_dma_bits - PAGE_SHIFT));
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h
index 823578c6b9e2..a4d38092530a 100644
--- a/arch/s390/include/asm/page.h
+++ b/arch/s390/include/asm/page.h
@@ -177,8 +177,6 @@ static inline int devmem_is_allowed(unsigned long pfn)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-#define ARCH_ZONE_DMA_BITS 31
-
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index a124f19f7b3c..f0ce22220565 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -118,6 +118,7 @@ void __init paging_init(void)
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
+ zone_dma_bits = 31;
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = PFN_DOWN(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index adf993a3bd58..d03af3605460 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -5,6 +5,8 @@
#include <linux/dma-mapping.h>
#include <linux/mem_encrypt.h>
+extern unsigned int zone_dma_bits;
+
#ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
#include <asm/dma-direct.h>
#else
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8402b29c280f..0b67c04e531b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -16,12 +16,11 @@
#include <linux/swiotlb.h>
/*
- * Most architectures use ZONE_DMA for the first 16 Megabytes, but
- * some use it for entirely different regions:
+ * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
+ * it for entirely different regions. In that case the arch code needs to
+ * override the variable below for dma-direct to work properly.
*/
-#ifndef ARCH_ZONE_DMA_BITS
-#define ARCH_ZONE_DMA_BITS 24
-#endif
+unsigned int zone_dma_bits __ro_after_init = 24;
static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
{
@@ -69,7 +68,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
* Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
* zones.
*/
- if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
return GFP_DMA;
if (*phys_mask <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -395,7 +394,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
u64 min_mask;
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
+ min_mask = DMA_BIT_MASK(zone_dma_bits);
else
min_mask = DMA_BIT_MASK(32);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 15:28 ` Nicolas Saenz Julienne
(?)
(?)
@ 2019-10-31 15:47 ` Christoph Hellwig
-1 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:47 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Christoph Hellwig, Marek Szyprowski, Robin Murphy,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-s390, iommu
On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>
> Changes since RFC:
> - Rebased to v5.4-rc6, fixed arm64 code.
>
> NOTE: This will only apply to linux-next, where
missing end of the sentence. But only applying to linux-next isn't
going to help anyone..
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a54909c..f716ea634804 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -20,6 +20,7 @@
> #include <linux/sort.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/dma-direct.h>
> #include <linux/dma-mapping.h>
> #include <linux/dma-contiguous.h>
> #include <linux/efi.h>
> @@ -41,6 +42,8 @@
> #include <asm/tlb.h>
> #include <asm/alternative.h>
>
> +#define ARM64_ZONE_DMA_BITS 30
> +
> /*
> * We need to be able to catch inadvertent references to memstart_addr
> * that occur (potentially in generic code) before arm64_memblock_init()
> @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> +
> reserve_crashkernel();
This actually adds a new limit, as there wasn't one before for arm64.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:47 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:47 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>
> Changes since RFC:
> - Rebased to v5.4-rc6, fixed arm64 code.
>
> NOTE: This will only apply to linux-next, where
missing end of the sentence. But only applying to linux-next isn't
going to help anyone..
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a54909c..f716ea634804 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -20,6 +20,7 @@
> #include <linux/sort.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/dma-direct.h>
> #include <linux/dma-mapping.h>
> #include <linux/dma-contiguous.h>
> #include <linux/efi.h>
> @@ -41,6 +42,8 @@
> #include <asm/tlb.h>
> #include <asm/alternative.h>
>
> +#define ARM64_ZONE_DMA_BITS 30
> +
> /*
> * We need to be able to catch inadvertent references to memstart_addr
> * that occur (potentially in generic code) before arm64_memblock_init()
> @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> +
> reserve_crashkernel();
This actually adds a new limit, as there wasn't one before for arm64.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:47 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:47 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel
On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>
> Changes since RFC:
> - Rebased to v5.4-rc6, fixed arm64 code.
>
> NOTE: This will only apply to linux-next, where
missing end of the sentence. But only applying to linux-next isn't
going to help anyone..
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a54909c..f716ea634804 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -20,6 +20,7 @@
> #include <linux/sort.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/dma-direct.h>
> #include <linux/dma-mapping.h>
> #include <linux/dma-contiguous.h>
> #include <linux/efi.h>
> @@ -41,6 +42,8 @@
> #include <asm/tlb.h>
> #include <asm/alternative.h>
>
> +#define ARM64_ZONE_DMA_BITS 30
> +
> /*
> * We need to be able to catch inadvertent references to memstart_addr
> * that occur (potentially in generic code) before arm64_memblock_init()
> @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> +
> reserve_crashkernel();
This actually adds a new limit, as there wasn't one before for arm64.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:47 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:47 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>
> Changes since RFC:
> - Rebased to v5.4-rc6, fixed arm64 code.
>
> NOTE: This will only apply to linux-next, where
missing end of the sentence. But only applying to linux-next isn't
going to help anyone..
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a54909c..f716ea634804 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -20,6 +20,7 @@
> #include <linux/sort.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/dma-direct.h>
> #include <linux/dma-mapping.h>
> #include <linux/dma-contiguous.h>
> #include <linux/efi.h>
> @@ -41,6 +42,8 @@
> #include <asm/tlb.h>
> #include <asm/alternative.h>
>
> +#define ARM64_ZONE_DMA_BITS 30
> +
> /*
> * We need to be able to catch inadvertent references to memstart_addr
> * that occur (potentially in generic code) before arm64_memblock_init()
> @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
> + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> +
> reserve_crashkernel();
This actually adds a new limit, as there wasn't one before for arm64.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 15:47 ` Christoph Hellwig
(?)
(?)
@ 2019-10-31 15:53 ` Nicolas Saenz Julienne
-1 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Marek Szyprowski, Robin Murphy, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
linux-arm-kernel, linux-kernel, linuxppc-dev, linux-s390, iommu
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >
> > Changes since RFC:
> > - Rebased to v5.4-rc6, fixed arm64 code.
> >
> > NOTE: This will only apply to linux-next, where
>
> missing end of the sentence. But only applying to linux-next isn't
> going to help anyone..
Arrgh, excuse me, I meant to delete that line.
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 45c00a54909c..f716ea634804 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -20,6 +20,7 @@
> > #include <linux/sort.h>
> > #include <linux/of.h>
> > #include <linux/of_fdt.h>
> > +#include <linux/dma-direct.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dma-contiguous.h>
> > #include <linux/efi.h>
> > @@ -41,6 +42,8 @@
> > #include <asm/tlb.h>
> > #include <asm/alternative.h>
> >
> > +#define ARM64_ZONE_DMA_BITS 30
> > +
> > /*
> > * We need to be able to catch inadvertent references to memstart_addr
> > * that occur (potentially in generic code) before arm64_memblock_init()
> > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > else
> > arm64_dma_phys_limit = PHYS_MASK + 1;
> >
> > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > +
> > reserve_crashkernel();
>
> This actually adds a new limit, as there wasn't one before for arm64.
Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
not.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:53 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Robin Murphy,
linux-arm-kernel, Marek Szyprowski
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >
> > Changes since RFC:
> > - Rebased to v5.4-rc6, fixed arm64 code.
> >
> > NOTE: This will only apply to linux-next, where
>
> missing end of the sentence. But only applying to linux-next isn't
> going to help anyone..
Arrgh, excuse me, I meant to delete that line.
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 45c00a54909c..f716ea634804 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -20,6 +20,7 @@
> > #include <linux/sort.h>
> > #include <linux/of.h>
> > #include <linux/of_fdt.h>
> > +#include <linux/dma-direct.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dma-contiguous.h>
> > #include <linux/efi.h>
> > @@ -41,6 +42,8 @@
> > #include <asm/tlb.h>
> > #include <asm/alternative.h>
> >
> > +#define ARM64_ZONE_DMA_BITS 30
> > +
> > /*
> > * We need to be able to catch inadvertent references to memstart_addr
> > * that occur (potentially in generic code) before arm64_memblock_init()
> > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > else
> > arm64_dma_phys_limit = PHYS_MASK + 1;
> >
> > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > +
> > reserve_crashkernel();
>
> This actually adds a new limit, as there wasn't one before for arm64.
Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
not.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:53 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >
> > Changes since RFC:
> > - Rebased to v5.4-rc6, fixed arm64 code.
> >
> > NOTE: This will only apply to linux-next, where
>
> missing end of the sentence. But only applying to linux-next isn't
> going to help anyone..
Arrgh, excuse me, I meant to delete that line.
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 45c00a54909c..f716ea634804 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -20,6 +20,7 @@
> > #include <linux/sort.h>
> > #include <linux/of.h>
> > #include <linux/of_fdt.h>
> > +#include <linux/dma-direct.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dma-contiguous.h>
> > #include <linux/efi.h>
> > @@ -41,6 +42,8 @@
> > #include <asm/tlb.h>
> > #include <asm/alternative.h>
> >
> > +#define ARM64_ZONE_DMA_BITS 30
> > +
> > /*
> > * We need to be able to catch inadvertent references to memstart_addr
> > * that occur (potentially in generic code) before arm64_memblock_init()
> > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > else
> > arm64_dma_phys_limit = PHYS_MASK + 1;
> >
> > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > +
> > reserve_crashkernel();
>
> This actually adds a new limit, as there wasn't one before for arm64.
Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
not.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:53 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 15:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, linux-arm-kernel,
Marek Szyprowski
[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >
> > Changes since RFC:
> > - Rebased to v5.4-rc6, fixed arm64 code.
> >
> > NOTE: This will only apply to linux-next, where
>
> missing end of the sentence. But only applying to linux-next isn't
> going to help anyone..
Arrgh, excuse me, I meant to delete that line.
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 45c00a54909c..f716ea634804 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -20,6 +20,7 @@
> > #include <linux/sort.h>
> > #include <linux/of.h>
> > #include <linux/of_fdt.h>
> > +#include <linux/dma-direct.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dma-contiguous.h>
> > #include <linux/efi.h>
> > @@ -41,6 +42,8 @@
> > #include <asm/tlb.h>
> > #include <asm/alternative.h>
> >
> > +#define ARM64_ZONE_DMA_BITS 30
> > +
> > /*
> > * We need to be able to catch inadvertent references to memstart_addr
> > * that occur (potentially in generic code) before arm64_memblock_init()
> > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > else
> > arm64_dma_phys_limit = PHYS_MASK + 1;
> >
> > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > +
> > reserve_crashkernel();
>
> This actually adds a new limit, as there wasn't one before for arm64.
Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
not.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 15:53 ` Nicolas Saenz Julienne
(?)
(?)
@ 2019-10-31 15:57 ` Christoph Hellwig
-1 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:57 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Christoph Hellwig, Marek Szyprowski, Robin Murphy,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-s390, iommu
On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > +#define ARM64_ZONE_DMA_BITS 30
> > > +
> > > /*
> > > * We need to be able to catch inadvertent references to memstart_addr
> > > * that occur (potentially in generic code) before arm64_memblock_init()
> > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > else
> > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > >
> > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > +
> > > reserve_crashkernel();
> >
> > This actually adds a new limit, as there wasn't one before for arm64.
>
> Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
> I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
> not.
I'd much prefer that to do separately.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:57 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:57 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > +#define ARM64_ZONE_DMA_BITS 30
> > > +
> > > /*
> > > * We need to be able to catch inadvertent references to memstart_addr
> > > * that occur (potentially in generic code) before arm64_memblock_init()
> > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > else
> > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > >
> > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > +
> > > reserve_crashkernel();
> >
> > This actually adds a new limit, as there wasn't one before for arm64.
>
> Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
> I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
> not.
I'd much prefer that to do separately.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:57 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:57 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel
On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > +#define ARM64_ZONE_DMA_BITS 30
> > > +
> > > /*
> > > * We need to be able to catch inadvertent references to memstart_addr
> > > * that occur (potentially in generic code) before arm64_memblock_init()
> > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > else
> > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > >
> > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > +
> > > reserve_crashkernel();
> >
> > This actually adds a new limit, as there wasn't one before for arm64.
>
> Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
> I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
> not.
I'd much prefer that to do separately.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 15:57 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 15:57 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > +#define ARM64_ZONE_DMA_BITS 30
> > > +
> > > /*
> > > * We need to be able to catch inadvertent references to memstart_addr
> > > * that occur (potentially in generic code) before arm64_memblock_init()
> > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > else
> > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > >
> > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > +
> > > reserve_crashkernel();
> >
> > This actually adds a new limit, as there wasn't one before for arm64.
>
> Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is defined
> I figured it doesn't matter if the variable is set conditionally to ZONE_DMA or
> not.
I'd much prefer that to do separately.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 15:57 ` Christoph Hellwig
(?)
(?)
@ 2019-10-31 16:22 ` Nicolas Saenz Julienne
-1 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 16:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Marek Szyprowski, Robin Murphy, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
linux-arm-kernel, linux-kernel, linuxppc-dev, linux-s390, iommu
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > > +#define ARM64_ZONE_DMA_BITS 30
> > > > +
> > > > /*
> > > > * We need to be able to catch inadvertent references to memstart_addr
> > > > * that occur (potentially in generic code) before
> > > > arm64_memblock_init()
> > > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > > else
> > > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > > >
> > > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > > +
> > > > reserve_crashkernel();
> > >
> > > This actually adds a new limit, as there wasn't one before for arm64.
> >
> > Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is
> > defined
> > I figured it doesn't matter if the variable is set conditionally to ZONE_DMA
> > or
> > not.
>
> I'd much prefer that to do separately.
OK, I see what you mean now. It's wrong indeed.
The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
affected by this patch. I don't know the right way to approach this problem
since depending on the merge order, this patch should be updated or the arm64
ZONE_DMA series fixed.
Maybe it's easier to just wait for v5.6.
Regards,
Nicolas
[1] https://lkml.org/lkml/2019/9/11/734
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:22 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 16:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Robin Murphy,
linux-arm-kernel, Marek Szyprowski
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > > +#define ARM64_ZONE_DMA_BITS 30
> > > > +
> > > > /*
> > > > * We need to be able to catch inadvertent references to memstart_addr
> > > > * that occur (potentially in generic code) before
> > > > arm64_memblock_init()
> > > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > > else
> > > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > > >
> > > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > > +
> > > > reserve_crashkernel();
> > >
> > > This actually adds a new limit, as there wasn't one before for arm64.
> >
> > Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is
> > defined
> > I figured it doesn't matter if the variable is set conditionally to ZONE_DMA
> > or
> > not.
>
> I'd much prefer that to do separately.
OK, I see what you mean now. It's wrong indeed.
The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
affected by this patch. I don't know the right way to approach this problem
since depending on the merge order, this patch should be updated or the arm64
ZONE_DMA series fixed.
Maybe it's easier to just wait for v5.6.
Regards,
Nicolas
[1] https://lkml.org/lkml/2019/9/11/734
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:22 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 16:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1356 bytes --]
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > > +#define ARM64_ZONE_DMA_BITS 30
> > > > +
> > > > /*
> > > > * We need to be able to catch inadvertent references to memstart_addr
> > > > * that occur (potentially in generic code) before
> > > > arm64_memblock_init()
> > > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > > else
> > > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > > >
> > > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > > +
> > > > reserve_crashkernel();
> > >
> > > This actually adds a new limit, as there wasn't one before for arm64.
> >
> > Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is
> > defined
> > I figured it doesn't matter if the variable is set conditionally to ZONE_DMA
> > or
> > not.
>
> I'd much prefer that to do separately.
OK, I see what you mean now. It's wrong indeed.
The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
affected by this patch. I don't know the right way to approach this problem
since depending on the merge order, this patch should be updated or the arm64
ZONE_DMA series fixed.
Maybe it's easier to just wait for v5.6.
Regards,
Nicolas
[1] https://lkml.org/lkml/2019/9/11/734
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:22 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 32+ messages in thread
From: Nicolas Saenz Julienne @ 2019-10-31 16:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, linux-arm-kernel,
Marek Szyprowski
[-- Attachment #1.1: Type: text/plain, Size: 1356 bytes --]
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > > +#define ARM64_ZONE_DMA_BITS 30
> > > > +
> > > > /*
> > > > * We need to be able to catch inadvertent references to memstart_addr
> > > > * that occur (potentially in generic code) before
> > > > arm64_memblock_init()
> > > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void)
> > > > else
> > > > arm64_dma_phys_limit = PHYS_MASK + 1;
> > > >
> > > > + zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > > > +
> > > > reserve_crashkernel();
> > >
> > > This actually adds a new limit, as there wasn't one before for arm64.
> >
> > Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is
> > defined
> > I figured it doesn't matter if the variable is set conditionally to ZONE_DMA
> > or
> > not.
>
> I'd much prefer that to do separately.
OK, I see what you mean now. It's wrong indeed.
The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
affected by this patch. I don't know the right way to approach this problem
since depending on the merge order, this patch should be updated or the arm64
ZONE_DMA series fixed.
Maybe it's easier to just wait for v5.6.
Regards,
Nicolas
[1] https://lkml.org/lkml/2019/9/11/734
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 16:22 ` Nicolas Saenz Julienne
(?)
(?)
@ 2019-10-31 16:58 ` Christoph Hellwig
-1 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 16:58 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Christoph Hellwig, Marek Szyprowski, Robin Murphy,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-s390, iommu
On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> OK, I see what you mean now. It's wrong indeed.
>
> The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> affected by this patch. I don't know the right way to approach this problem
> since depending on the merge order, this patch should be updated or the arm64
> ZONE_DMA series fixed.
>
> Maybe it's easier to just wait for v5.6.
Ok, I can wait. Or the arm64 maintainers can pick up this patch if
you want to add it to that series.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:58 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 16:58 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> OK, I see what you mean now. It's wrong indeed.
>
> The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> affected by this patch. I don't know the right way to approach this problem
> since depending on the merge order, this patch should be updated or the arm64
> ZONE_DMA series fixed.
>
> Maybe it's easier to just wait for v5.6.
Ok, I can wait. Or the arm64 maintainers can pick up this patch if
you want to add it to that series.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:58 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 16:58 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel
On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> OK, I see what you mean now. It's wrong indeed.
>
> The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> affected by this patch. I don't know the right way to approach this problem
> since depending on the merge order, this patch should be updated or the arm64
> ZONE_DMA series fixed.
>
> Maybe it's easier to just wait for v5.6.
Ok, I can wait. Or the arm64 maintainers can pick up this patch if
you want to add it to that series.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 16:58 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 16:58 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-s390, Vasily Gorbik, Will Deacon, Catalin Marinas,
linuxppc-dev, Heiko Carstens, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Robin Murphy, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> OK, I see what you mean now. It's wrong indeed.
>
> The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> affected by this patch. I don't know the right way to approach this problem
> since depending on the merge order, this patch should be updated or the arm64
> ZONE_DMA series fixed.
>
> Maybe it's easier to just wait for v5.6.
Ok, I can wait. Or the arm64 maintainers can pick up this patch if
you want to add it to that series.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 16:58 ` Christoph Hellwig
(?)
(?)
@ 2019-10-31 18:06 ` Catalin Marinas
-1 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2019-10-31 18:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nicolas Saenz Julienne, Marek Szyprowski, Robin Murphy,
Will Deacon, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-s390, iommu
On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > OK, I see what you mean now. It's wrong indeed.
> >
> > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > affected by this patch. I don't know the right way to approach this problem
> > since depending on the merge order, this patch should be updated or the arm64
> > ZONE_DMA series fixed.
> >
> > Maybe it's easier to just wait for v5.6.
>
> Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> you want to add it to that series.
This branch is stable (may add a fix but not I'm not rebasing it) if you
want to base this patch on top:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
Otherwise, with your ack, I can add it on top of the above branch (aimed
at 5.5).
--
Catalin
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:06 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2019-10-31 18:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, linuxppc-dev, Heiko Carstens,
Robin Murphy, linux-kernel, Christian Borntraeger, iommu,
Paul Mackerras, linux-arm-kernel, Will Deacon,
Nicolas Saenz Julienne, Marek Szyprowski
On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > OK, I see what you mean now. It's wrong indeed.
> >
> > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > affected by this patch. I don't know the right way to approach this problem
> > since depending on the merge order, this patch should be updated or the arm64
> > ZONE_DMA series fixed.
> >
> > Maybe it's easier to just wait for v5.6.
>
> Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> you want to add it to that series.
This branch is stable (may add a fix but not I'm not rebasing it) if you
want to base this patch on top:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
Otherwise, with your ack, I can add it on top of the above branch (aimed
at 5.5).
--
Catalin
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:06 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2019-10-31 18:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Benjamin Herrenschmidt, linuxppc-dev,
Heiko Carstens, Robin Murphy, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Nicolas Saenz Julienne
On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > OK, I see what you mean now. It's wrong indeed.
> >
> > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > affected by this patch. I don't know the right way to approach this problem
> > since depending on the merge order, this patch should be updated or the arm64
> > ZONE_DMA series fixed.
> >
> > Maybe it's easier to just wait for v5.6.
>
> Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> you want to add it to that series.
This branch is stable (may add a fix but not I'm not rebasing it) if you
want to base this patch on top:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
Otherwise, with your ack, I can add it on top of the above branch (aimed
at 5.5).
--
Catalin
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:06 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2019-10-31 18:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Vasily Gorbik, Benjamin Herrenschmidt, linuxppc-dev,
Heiko Carstens, Robin Murphy, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Nicolas Saenz Julienne,
Marek Szyprowski
On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > OK, I see what you mean now. It's wrong indeed.
> >
> > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > affected by this patch. I don't know the right way to approach this problem
> > since depending on the merge order, this patch should be updated or the arm64
> > ZONE_DMA series fixed.
> >
> > Maybe it's easier to just wait for v5.6.
>
> Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> you want to add it to that series.
This branch is stable (may add a fix but not I'm not rebasing it) if you
want to base this patch on top:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
Otherwise, with your ack, I can add it on top of the above branch (aimed
at 5.5).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
2019-10-31 18:06 ` Catalin Marinas
(?)
(?)
@ 2019-10-31 18:32 ` Christoph Hellwig
-1 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 18:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: Christoph Hellwig, Nicolas Saenz Julienne, Marek Szyprowski,
Robin Murphy, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-s390, iommu
On Thu, Oct 31, 2019 at 06:06:19PM +0000, Catalin Marinas wrote:
> On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > > OK, I see what you mean now. It's wrong indeed.
> > >
> > > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > > affected by this patch. I don't know the right way to approach this problem
> > > since depending on the merge order, this patch should be updated or the arm64
> > > ZONE_DMA series fixed.
> > >
> > > Maybe it's easier to just wait for v5.6.
> >
> > Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> > you want to add it to that series.
>
> This branch is stable (may add a fix but not I'm not rebasing it) if you
> want to base this patch on top:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
>
> Otherwise, with your ack, I can add it on top of the above branch (aimed
> at 5.5).
Please go ahead:
Acked-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:32 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 18:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-s390, Vasily Gorbik, linuxppc-dev, Heiko Carstens,
Robin Murphy, linux-kernel, Christian Borntraeger, iommu,
Paul Mackerras, linux-arm-kernel, Will Deacon, Christoph Hellwig,
Nicolas Saenz Julienne, Marek Szyprowski
On Thu, Oct 31, 2019 at 06:06:19PM +0000, Catalin Marinas wrote:
> On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > > OK, I see what you mean now. It's wrong indeed.
> > >
> > > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > > affected by this patch. I don't know the right way to approach this problem
> > > since depending on the merge order, this patch should be updated or the arm64
> > > ZONE_DMA series fixed.
> > >
> > > Maybe it's easier to just wait for v5.6.
> >
> > Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> > you want to add it to that series.
>
> This branch is stable (may add a fix but not I'm not rebasing it) if you
> want to base this patch on top:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
>
> Otherwise, with your ack, I can add it on top of the above branch (aimed
> at 5.5).
Please go ahead:
Acked-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:32 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 18:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-s390, Vasily Gorbik, Benjamin Herrenschmidt, linuxppc-dev,
Heiko Carstens, Robin Murphy, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Christoph Hellwig,
Nicolas Saenz Julienne
On Thu, Oct 31, 2019 at 06:06:19PM +0000, Catalin Marinas wrote:
> On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > > OK, I see what you mean now. It's wrong indeed.
> > >
> > > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > > affected by this patch. I don't know the right way to approach this problem
> > > since depending on the merge order, this patch should be updated or the arm64
> > > ZONE_DMA series fixed.
> > >
> > > Maybe it's easier to just wait for v5.6.
> >
> > Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> > you want to add it to that series.
>
> This branch is stable (may add a fix but not I'm not rebasing it) if you
> want to base this patch on top:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
>
> Otherwise, with your ack, I can add it on top of the above branch (aimed
> at 5.5).
Please go ahead:
Acked-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable
@ 2019-10-31 18:32 ` Christoph Hellwig
0 siblings, 0 replies; 32+ messages in thread
From: Christoph Hellwig @ 2019-10-31 18:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-s390, Vasily Gorbik, Benjamin Herrenschmidt, linuxppc-dev,
Heiko Carstens, Robin Murphy, linux-kernel,
Christian Borntraeger, iommu, Paul Mackerras, linux-arm-kernel,
Michael Ellerman, Will Deacon, Christoph Hellwig,
Nicolas Saenz Julienne, Marek Szyprowski
On Thu, Oct 31, 2019 at 06:06:19PM +0000, Catalin Marinas wrote:
> On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > > OK, I see what you mean now. It's wrong indeed.
> > >
> > > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > > affected by this patch. I don't know the right way to approach this problem
> > > since depending on the merge order, this patch should be updated or the arm64
> > > ZONE_DMA series fixed.
> > >
> > > Maybe it's easier to just wait for v5.6.
> >
> > Ok, I can wait. Or the arm64 maintainers can pick up this patch if
> > you want to add it to that series.
>
> This branch is stable (may add a fix but not I'm not rebasing it) if you
> want to base this patch on top:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/zone-dma
>
> Otherwise, with your ack, I can add it on top of the above branch (aimed
> at 5.5).
Please go ahead:
Acked-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2019-10-31 18:35 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-31 15:28 [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable Nicolas Saenz Julienne
2019-10-31 15:28 ` Nicolas Saenz Julienne
2019-10-31 15:28 ` Nicolas Saenz Julienne
2019-10-31 15:28 ` Nicolas Saenz Julienne
2019-10-31 15:47 ` Christoph Hellwig
2019-10-31 15:47 ` Christoph Hellwig
2019-10-31 15:47 ` Christoph Hellwig
2019-10-31 15:47 ` Christoph Hellwig
2019-10-31 15:53 ` Nicolas Saenz Julienne
2019-10-31 15:53 ` Nicolas Saenz Julienne
2019-10-31 15:53 ` Nicolas Saenz Julienne
2019-10-31 15:53 ` Nicolas Saenz Julienne
2019-10-31 15:57 ` Christoph Hellwig
2019-10-31 15:57 ` Christoph Hellwig
2019-10-31 15:57 ` Christoph Hellwig
2019-10-31 15:57 ` Christoph Hellwig
2019-10-31 16:22 ` Nicolas Saenz Julienne
2019-10-31 16:22 ` Nicolas Saenz Julienne
2019-10-31 16:22 ` Nicolas Saenz Julienne
2019-10-31 16:22 ` Nicolas Saenz Julienne
2019-10-31 16:58 ` Christoph Hellwig
2019-10-31 16:58 ` Christoph Hellwig
2019-10-31 16:58 ` Christoph Hellwig
2019-10-31 16:58 ` Christoph Hellwig
2019-10-31 18:06 ` Catalin Marinas
2019-10-31 18:06 ` Catalin Marinas
2019-10-31 18:06 ` Catalin Marinas
2019-10-31 18:06 ` Catalin Marinas
2019-10-31 18:32 ` Christoph Hellwig
2019-10-31 18:32 ` Christoph Hellwig
2019-10-31 18:32 ` Christoph Hellwig
2019-10-31 18:32 ` Christoph Hellwig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.