--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:13 +0800
+Subject: arm64: mm: Move reserve_crashkernel() into mem_init()
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Jeremy Linton <jeremy.linton@arm.com>
+Message-ID: <20210303073319.2215839-2-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 0a30c53573b07d5561457e41fb0ab046cd857da5 upstream
+
+crashkernel might reserve memory located in ZONE_DMA. We plan to delay
+ZONE_DMA's initialization after unflattening the devicetree and ACPI's
+boot table initialization, so move it later in the boot process.
+Specifically into bootmem_init() since request_standard_resources()
+depends on it.
+
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Tested-by: Jeremy Linton <jeremy.linton@arm.com>
+Link: https://lore.kernel.org/r/20201119175400.9995-2-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/init.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/mm/init.c
++++ b/arch/arm64/mm/init.c
+@@ -386,8 +386,6 @@ void __init arm64_memblock_init(void)
+ else
+ arm64_dma32_phys_limit = PHYS_MASK + 1;
+
+- reserve_crashkernel();
+-
+ reserve_elfcorehdr();
+
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
+@@ -427,6 +425,12 @@ void __init bootmem_init(void)
+ sparse_init();
+ zone_sizes_init(min, max);
+
++ /*
++ * request_standard_resources() depends on crashkernel's memory being
++ * reserved, so do it here.
++ */
++ reserve_crashkernel();
++
+ memblock_dump_all();
+ }
+
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:14 +0800
+Subject: arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Jeremy Linton <jeremy.linton@arm.com>
+Message-ID: <20210303073319.2215839-3-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 9804f8c69b04a39d0ba41d19e6bdc6aa91c19725 upstream
+
+zone_dma_bits's initialization happens earlier that it's actually
+needed, in arm64_memblock_init(). So move it into the more suitable
+zone_sizes_init().
+
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Tested-by: Jeremy Linton <jeremy.linton@arm.com>
+Link: https://lore.kernel.org/r/20201119175400.9995-3-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/init.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/arch/arm64/mm/init.c
++++ b/arch/arm64/mm/init.c
+@@ -190,6 +190,8 @@ static void __init zone_sizes_init(unsig
+ unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
+
+ #ifdef CONFIG_ZONE_DMA
++ zone_dma_bits = ARM64_ZONE_DMA_BITS;
++ arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
+ #endif
+ #ifdef CONFIG_ZONE_DMA32
+@@ -376,11 +378,6 @@ void __init arm64_memblock_init(void)
+
+ early_init_fdt_scan_reserved_mem();
+
+- if (IS_ENABLED(CONFIG_ZONE_DMA)) {
+- zone_dma_bits = ARM64_ZONE_DMA_BITS;
+- arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
+- }
+-
+ if (IS_ENABLED(CONFIG_ZONE_DMA32))
+ arm64_dma32_phys_limit = max_zone_phys(32);
+ else
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:17 +0800
+Subject: arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>
+Message-ID: <20210303073319.2215839-6-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 8424ecdde7df99d5426e1a1fd9f0fb36f4183032 upstream
+
+We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
+incorporating masters that can address less than 32 bits of DMA, in
+particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
+peripherals that can only address up to 1 GB (and its PCIe host
+bridge can only access the bottom 3 GB)
+
+The DMA layer also needs to be able to allocate memory that is
+guaranteed to meet those DMA constraints, for bounce buffering as well
+as allocating the backing for consistent mappings. This is why the 1 GB
+ZONE_DMA was introduced recently. Unfortunately, it turns out the having
+a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and
+potentially in other places where allocations cannot cross zone
+boundaries. Therefore, we should avoid having two separate DMA zones
+when possible.
+
+So, with the help of of_dma_get_max_cpu_address() get the topmost
+physical address accessible to all DMA masters in system and use that
+information to fine-tune ZONE_DMA's size. In the absence of addressing
+limited masters ZONE_DMA will span the whole 32-bit address space,
+otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit
+address space, and have ZONE_DMA32 cover the rest of the 32-bit address
+space.
+
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Link: https://lore.kernel.org/r/20201119175400.9995-6-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/init.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/mm/init.c
++++ b/arch/arm64/mm/init.c
+@@ -42,8 +42,6 @@
+ #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()
+@@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(
+ static void __init zone_sizes_init(unsigned long min, unsigned long max)
+ {
+ unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
++ unsigned int __maybe_unused dt_zone_dma_bits;
+
+ #ifdef CONFIG_ZONE_DMA
+- zone_dma_bits = ARM64_ZONE_DMA_BITS;
++ dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
++ zone_dma_bits = min(32U, dt_zone_dma_bits);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
+ #endif
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:18 +0800
+Subject: arm64: mm: Set ZONE_DMA size based on early IORT scan
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Jeremy Linton <jeremy.linton@arm.com>, Christoph Hellwig <hch@lst.de>, Robin Murphy <robin.murphy@arm.com>
+Message-ID: <20210303073319.2215839-7-jingxiangfeng@huawei.com>
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+commit 2b8652936f0ca9ca2e6c984ae76c7bfcda1b3f22 upstream
+
+We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
+incorporating masters that can address less than 32 bits of DMA, in
+particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
+peripherals that can only address up to 1 GB (and its PCIe host
+bridge can only access the bottom 3 GB)
+
+Instructing the DMA layer about these limitations is straight-forward,
+even though we had to fix some issues regarding memory limits set in
+the IORT for named components, and regarding the handling of ACPI _DMA
+methods. However, the DMA layer also needs to be able to allocate
+memory that is guaranteed to meet those DMA constraints, for bounce
+buffering as well as allocating the backing for consistent mappings.
+
+This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
+it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
+problems with kdump, and potentially in other places where allocations
+cannot cross zone boundaries. Therefore, we should avoid having two
+separate DMA zones when possible.
+
+So let's do an early scan of the IORT, and only create the ZONE_DMA
+if we encounter any devices that need it. This puts the burden on
+the firmware to describe such limitations in the IORT, which may be
+redundant (and less precise) if _DMA methods are also being provided.
+However, it should be noted that this situation is highly unusual for
+arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
+the _DMA method if implemented, and so we will not lose the ability to
+perform streaming DMA outside the ZONE_DMA if the _DMA method permits
+it.
+
+[nsaenz: unified implementation with DT's counterpart]
+
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Tested-by: Jeremy Linton <jeremy.linton@arm.com>
+Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Acked-by: Hanjun Guo <guohanjun@huawei.com>
+Cc: Jeremy Linton <jeremy.linton@arm.com>
+Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Hanjun Guo <guohanjun@huawei.com>
+Cc: Sudeep Holla <sudeep.holla@arm.com>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/init.c | 5 +++-
+ drivers/acpi/arm64/iort.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++
+ include/linux/acpi_iort.h | 4 +++
+ 3 files changed, 63 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/init.c
++++ b/arch/arm64/mm/init.c
+@@ -29,6 +29,7 @@
+ #include <linux/kexec.h>
+ #include <linux/crash_dump.h>
+ #include <linux/hugetlb.h>
++#include <linux/acpi_iort.h>
+
+ #include <asm/boot.h>
+ #include <asm/fixmap.h>
+@@ -186,11 +187,13 @@ static phys_addr_t __init max_zone_phys(
+ static void __init zone_sizes_init(unsigned long min, unsigned long max)
+ {
+ unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
++ unsigned int __maybe_unused acpi_zone_dma_bits;
+ unsigned int __maybe_unused dt_zone_dma_bits;
+
+ #ifdef CONFIG_ZONE_DMA
++ acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
+ dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
+- zone_dma_bits = min(32U, dt_zone_dma_bits);
++ zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
+ #endif
+--- a/drivers/acpi/arm64/iort.c
++++ b/drivers/acpi/arm64/iort.c
+@@ -1730,3 +1730,58 @@ void __init acpi_iort_init(void)
+
+ iort_init_platform_devices();
+ }
++
++#ifdef CONFIG_ZONE_DMA
++/*
++ * Extract the highest CPU physical address accessible to all DMA masters in
++ * the system. PHYS_ADDR_MAX is returned when no constrained device is found.
++ */
++phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void)
++{
++ phys_addr_t limit = PHYS_ADDR_MAX;
++ struct acpi_iort_node *node, *end;
++ struct acpi_table_iort *iort;
++ acpi_status status;
++ int i;
++
++ if (acpi_disabled)
++ return limit;
++
++ status = acpi_get_table(ACPI_SIG_IORT, 0,
++ (struct acpi_table_header **)&iort);
++ if (ACPI_FAILURE(status))
++ return limit;
++
++ node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
++ end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
++
++ for (i = 0; i < iort->node_count; i++) {
++ if (node >= end)
++ break;
++
++ switch (node->type) {
++ struct acpi_iort_named_component *ncomp;
++ struct acpi_iort_root_complex *rc;
++ phys_addr_t local_limit;
++
++ case ACPI_IORT_NODE_NAMED_COMPONENT:
++ ncomp = (struct acpi_iort_named_component *)node->node_data;
++ local_limit = DMA_BIT_MASK(ncomp->memory_address_limit);
++ limit = min_not_zero(limit, local_limit);
++ break;
++
++ case ACPI_IORT_NODE_PCI_ROOT_COMPLEX:
++ if (node->revision < 1)
++ break;
++
++ rc = (struct acpi_iort_root_complex *)node->node_data;
++ local_limit = DMA_BIT_MASK(rc->memory_address_limit);
++ limit = min_not_zero(limit, local_limit);
++ break;
++ }
++ node = ACPI_ADD_PTR(struct acpi_iort_node, node, node->length);
++ }
++ acpi_put_table(&iort->header);
++ return limit;
++}
++#endif
+--- a/include/linux/acpi_iort.h
++++ b/include/linux/acpi_iort.h
+@@ -38,6 +38,7 @@ void iort_dma_setup(struct device *dev,
+ const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
+ const u32 *id_in);
+ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
++phys_addr_t acpi_iort_dma_get_max_cpu_address(void);
+ #else
+ static inline void acpi_iort_init(void) { }
+ static inline u32 iort_msi_map_id(struct device *dev, u32 id)
+@@ -55,6 +56,9 @@ static inline const struct iommu_ops *io
+ static inline
+ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+ { return 0; }
++
++static inline phys_addr_t acpi_iort_dma_get_max_cpu_address(void)
++{ return PHYS_ADDR_MAX; }
+ #endif
+
+ #endif /* __ACPI_IORT_H__ */
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:19 +0800
+Subject: mm: Remove examples from enum zone_type comment
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Christoph Hellwig <hch@lst.de>
+Message-ID: <20210303073319.2215839-8-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 04435217f96869ac3a8f055ff68c5237a60bcd7e upstream
+
+We can't really list every setup in common code. On top of that they are
+unlikely to stay true for long as things change in the arch trees
+independently of this comment.
+
+Suggested-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20201119175400.9995-8-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/mmzone.h | 20 --------------------
+ 1 file changed, 20 deletions(-)
+
+--- a/include/linux/mmzone.h
++++ b/include/linux/mmzone.h
+@@ -354,26 +354,6 @@ enum zone_type {
+ * DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
+ * platforms may need both zones as they support peripherals with
+ * different DMA addressing limitations.
+- *
+- * Some examples:
+- *
+- * - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
+- * rest of the lower 4G.
+- *
+- * - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
+- * the specific device.
+- *
+- * - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
+- * lower 4G.
+- *
+- * - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
+- * depending on the specific device.
+- *
+- * - s390 uses ZONE_DMA fixed to the lower 2G.
+- *
+- * - ia64 and riscv only use ZONE_DMA32.
+- *
+- * - parisc uses neither.
+ */
+ #ifdef CONFIG_ZONE_DMA
+ ZONE_DMA,
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:15 +0800
+Subject: of/address: Introduce of_dma_get_max_cpu_address()
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Rob Herring <robh@kernel.org>
+Message-ID: <20210303073319.2215839-4-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 964db79d6c186cc2ecc6ae46f98eed7e0ea8cf71 upstream
+
+Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
+physical address addressable by all DMA masters in the system. It's
+specially useful for setting memory zones sizes at early boot time.
+
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Reviewed-by: Rob Herring <robh@kernel.org>
+Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/of/address.c | 42 ++++++++++++++++++++++++++++++++++++++++++
+ include/linux/of.h | 7 +++++++
+ 2 files changed, 49 insertions(+)
+
+--- a/drivers/of/address.c
++++ b/drivers/of/address.c
+@@ -1025,6 +1025,48 @@ out:
+ #endif /* CONFIG_HAS_DMA */
+
+ /**
++ * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
++ * @np: The node to start searching from or NULL to start from the root
++ *
++ * Gets the highest CPU physical address that is addressable by all DMA masters
++ * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
++ * DMA constrained device is found, it returns PHYS_ADDR_MAX.
++ */
++phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
++{
++ phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
++ struct of_range_parser parser;
++ phys_addr_t subtree_max_addr;
++ struct device_node *child;
++ struct of_range range;
++ const __be32 *ranges;
++ u64 cpu_end = 0;
++ int len;
++
++ if (!np)
++ np = of_root;
++
++ ranges = of_get_property(np, "dma-ranges", &len);
++ if (ranges && len) {
++ of_dma_range_parser_init(&parser, np);
++ for_each_of_range(&parser, &range)
++ if (range.cpu_addr + range.size > cpu_end)
++ cpu_end = range.cpu_addr + range.size - 1;
++
++ if (max_cpu_addr > cpu_end)
++ max_cpu_addr = cpu_end;
++ }
++
++ for_each_available_child_of_node(np, child) {
++ subtree_max_addr = of_dma_get_max_cpu_address(child);
++ if (max_cpu_addr > subtree_max_addr)
++ max_cpu_addr = subtree_max_addr;
++ }
++
++ return max_cpu_addr;
++}
++
++/**
+ * of_dma_is_coherent - Check if device is coherent
+ * @np: device node
+ *
+--- a/include/linux/of.h
++++ b/include/linux/of.h
+@@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u3
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out);
+
++phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
++
+ #else /* CONFIG_OF */
+
+ static inline void of_core_init(void)
+@@ -995,6 +997,11 @@ static inline int of_map_id(struct devic
+ return -EINVAL;
+ }
+
++static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
++{
++ return PHYS_ADDR_MAX;
++}
++
+ #define of_match_ptr(_ptr) NULL
+ #define of_match_node(_matches, _node) NULL
+ #endif /* CONFIG_OF */
--- /dev/null
+From foo@baz Sun Mar 7 04:22:37 PM CET 2021
+From: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Date: Wed, 3 Mar 2021 15:33:16 +0800
+Subject: of: unittest: Add test for of_dma_get_max_cpu_address()
+To: <gregkh@linuxfoundation.org>, <catalin.marinas@arm.com>, <will@kernel.org>, <akpm@linux-foundation.org>, <nsaenzjulienne@suse.de>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>, <lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>, <sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>, <song.bao.hua@hisilicon.com>, <ardb@kernel.org>, <anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>, <robh+dt@kernel.org>
+Cc: <stable@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>, <jingxiangfeng@huawei.com>, <wangkefeng.wang@huawei.com>, Rob Herring <robh@kernel.org>
+Message-ID: <20210303073319.2215839-5-jingxiangfeng@huawei.com>
+
+From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+commit 07d13a1d6120d453c3c1f020578693d072deded5 upstream
+
+Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
+data as the rest of dma-ranges unit tests.
+
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Reviewed-by: Rob Herring <robh@kernel.org>
+Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.de
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/of/unittest.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/of/unittest.c
++++ b/drivers/of/unittest.c
+@@ -869,6 +869,23 @@ static void __init of_unittest_changeset
+ #endif
+ }
+
++static void __init of_unittest_dma_get_max_cpu_address(void)
++{
++ struct device_node *np;
++ phys_addr_t cpu_addr;
++
++ np = of_find_node_by_path("/testcase-data/address-tests");
++ if (!np) {
++ pr_err("missing testcase data\n");
++ return;
++ }
++
++ cpu_addr = of_dma_get_max_cpu_address(np);
++ unittest(cpu_addr == 0x4fffffff,
++ "of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting %x)\n",
++ &cpu_addr, 0x4fffffff);
++}
++
+ static void __init of_unittest_dma_ranges_one(const char *path,
+ u64 expect_dma_addr, u64 expect_paddr)
+ {
+@@ -3266,6 +3283,7 @@ static int __init of_unittest(void)
+ of_unittest_changeset();
+ of_unittest_parse_interrupts();
+ of_unittest_parse_interrupts_extended();
++ of_unittest_dma_get_max_cpu_address();
+ of_unittest_parse_dma_ranges();
+ of_unittest_pci_dma_ranges();
+ of_unittest_match_node();
drm-amdgpu-disable-vcn-for-navi12-sku.patch
drm-amdgpu-fix-parameter-error-of-rreg32_pcie-in-amdgpu_regs_pcie.patch
crypto-shash-reduce-minimum-alignment-of-shash_desc-structure.patch
+arm64-mm-move-reserve_crashkernel-into-mem_init.patch
+arm64-mm-move-zone_dma_bits-initialization-into-zone_sizes_init.patch
+of-address-introduce-of_dma_get_max_cpu_address.patch
+of-unittest-add-test-for-of_dma_get_max_cpu_address.patch
+arm64-mm-set-zone_dma-size-based-on-devicetree-s-dma-ranges.patch
+arm64-mm-set-zone_dma-size-based-on-early-iort-scan.patch
+mm-remove-examples-from-enum-zone_type-comment.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
