From: Greg Kroah-Hartman Date: Sun, 7 Mar 2021 15:25:43 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v5.4.104~16 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f10d6bd3b58595d7a9d9ddf716cbd2e487eecdbb;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm64-mm-move-reserve_crashkernel-into-mem_init.patch arm64-mm-move-zone_dma_bits-initialization-into-zone_sizes_init.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 of-address-introduce-of_dma_get_max_cpu_address.patch of-unittest-add-test-for-of_dma_get_max_cpu_address.patch --- diff --git a/queue-5.10/arm64-mm-move-reserve_crashkernel-into-mem_init.patch b/queue-5.10/arm64-mm-move-reserve_crashkernel-into-mem_init.patch new file mode 100644 index 00000000000..eb9be8e9e2a --- /dev/null +++ b/queue-5.10/arm64-mm-move-reserve_crashkernel-into-mem_init.patch @@ -0,0 +1,53 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:13 +0800 +Subject: arm64: mm: Move reserve_crashkernel() into mem_init() +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Jeremy Linton +Message-ID: <20210303073319.2215839-2-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Tested-by: Jeremy Linton +Link: https://lore.kernel.org/r/20201119175400.9995-2-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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(); + } + diff --git a/queue-5.10/arm64-mm-move-zone_dma_bits-initialization-into-zone_sizes_init.patch b/queue-5.10/arm64-mm-move-zone_dma_bits-initialization-into-zone_sizes_init.patch new file mode 100644 index 00000000000..51160ff9a78 --- /dev/null +++ b/queue-5.10/arm64-mm-move-zone_dma_bits-initialization-into-zone_sizes_init.patch @@ -0,0 +1,50 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:14 +0800 +Subject: arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Jeremy Linton +Message-ID: <20210303073319.2215839-3-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Tested-by: Jeremy Linton +Link: https://lore.kernel.org/r/20201119175400.9995-3-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/arm64-mm-set-zone_dma-size-based-on-devicetree-s-dma-ranges.patch b/queue-5.10/arm64-mm-set-zone_dma-size-based-on-devicetree-s-dma-ranges.patch new file mode 100644 index 00000000000..960e37259c2 --- /dev/null +++ b/queue-5.10/arm64-mm-set-zone_dma-size-based-on-devicetree-s-dma-ranges.patch @@ -0,0 +1,69 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:17 +0800 +Subject: arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , +Message-ID: <20210303073319.2215839-6-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Link: https://lore.kernel.org/r/20201119175400.9995-6-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + +-#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 diff --git a/queue-5.10/arm64-mm-set-zone_dma-size-based-on-early-iort-scan.patch b/queue-5.10/arm64-mm-set-zone_dma-size-based-on-early-iort-scan.patch new file mode 100644 index 00000000000..a4438005026 --- /dev/null +++ b/queue-5.10/arm64-mm-set-zone_dma-size-based-on-early-iort-scan.patch @@ -0,0 +1,174 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:18 +0800 +Subject: arm64: mm: Set ZONE_DMA size based on early IORT scan +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Jeremy Linton , Christoph Hellwig , Robin Murphy +Message-ID: <20210303073319.2215839-7-jingxiangfeng@huawei.com> + +From: Ard Biesheuvel + +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 +Signed-off-by: Nicolas Saenz Julienne +Tested-by: Jeremy Linton +Acked-by: Lorenzo Pieralisi +Acked-by: Hanjun Guo +Cc: Jeremy Linton +Cc: Lorenzo Pieralisi +Cc: Nicolas Saenz Julienne +Cc: Rob Herring +Cc: Christoph Hellwig +Cc: Robin Murphy +Cc: Hanjun Guo +Cc: Sudeep Holla +Cc: Anshuman Khandual +Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #include + #include +@@ -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__ */ diff --git a/queue-5.10/mm-remove-examples-from-enum-zone_type-comment.patch b/queue-5.10/mm-remove-examples-from-enum-zone_type-comment.patch new file mode 100644 index 00000000000..cd659745bac --- /dev/null +++ b/queue-5.10/mm-remove-examples-from-enum-zone_type-comment.patch @@ -0,0 +1,57 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:19 +0800 +Subject: mm: Remove examples from enum zone_type comment +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Christoph Hellwig +Message-ID: <20210303073319.2215839-8-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Signed-off-by: Nicolas Saenz Julienne +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20201119175400.9995-8-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/of-address-introduce-of_dma_get_max_cpu_address.patch b/queue-5.10/of-address-introduce-of_dma_get_max_cpu_address.patch new file mode 100644 index 00000000000..0ac0d2cc898 --- /dev/null +++ b/queue-5.10/of-address-introduce-of_dma_get_max_cpu_address.patch @@ -0,0 +1,102 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:15 +0800 +Subject: of/address: Introduce of_dma_get_max_cpu_address() +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Rob Herring +Message-ID: <20210303073319.2215839-4-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Reviewed-by: Rob Herring +Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-5.10/of-unittest-add-test-for-of_dma_get_max_cpu_address.patch b/queue-5.10/of-unittest-add-test-for-of_dma_get_max_cpu_address.patch new file mode 100644 index 00000000000..1ff98fdf436 --- /dev/null +++ b/queue-5.10/of-unittest-add-test-for-of_dma_get_max_cpu_address.patch @@ -0,0 +1,60 @@ +From foo@baz Sun Mar 7 04:22:37 PM CET 2021 +From: Jing Xiangfeng +Date: Wed, 3 Mar 2021 15:33:16 +0800 +Subject: of: unittest: Add test for of_dma_get_max_cpu_address() +To: , , , , , , , , , , , , , , , , , , , +Cc: , , , , , , , , , Rob Herring +Message-ID: <20210303073319.2215839-5-jingxiangfeng@huawei.com> + +From: Nicolas Saenz Julienne + +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 +Reviewed-by: Rob Herring +Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.de +Signed-off-by: Catalin Marinas +Cc: +Signed-off-by: Jing Xiangfeng +Signed-off-by: Greg Kroah-Hartman +--- + 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(); diff --git a/queue-5.10/series b/queue-5.10/series index 7dbab780e42..cdd75284d52 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -21,3 +21,10 @@ dm-verity-fix-fec-for-rs-roots-unaligned-to-block-size.patch 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