Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()
From: Ard Biesheuvel <ardb@kernel.org>
Date: 2020-10-15 09:18:31
Also in:
linux-devicetree, linux-iommu, lkml
On Thu, 15 Oct 2020 at 11:16, Nicolas Saenz Julienne [off-list ref] wrote:
On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote:quoted
On Thu, 15 Oct 2020 at 00:03, Rob Herring [off-list ref] wrote:quoted
On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne [off-list ref] wrote:quoted
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 <redacted> --- Changes since v2: - Use PHYS_ADDR_MAX - return phys_dma_t - Rename function - Correct subject - Add support to start parsing from an arbitrary device node in order for the function to work with unit tests drivers/of/address.c | 42 ++++++++++++++++++++++++++++++++++++++++++ include/linux/of.h | 7 +++++++ 2 files changed, 49 insertions(+)diff --git a/drivers/of/address.c b/drivers/of/address.c index eb9ab4f1e80b..b5a9695aaf82 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c@@ -1024,6 +1024,48 @@ int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map) } #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 system (or subtree when np is non-NULL). 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;One issue with using phys_addr_t is it may be 32-bit even though the DT is 64-bit addresses. LPAE capable system with LPAE disabled. Maybe the truncation is fine here? Maybe not.PHYS_ADDR_MAX is the max addressable CPU address on the system, and so it makes sense to use it for the return type, and for the preliminary return value: this is actually what /prevents/ truncation, because we will only overwrite max_cpu_addr if the new u64 value is lower.Actually I now see how things might go south.quoted
quoted
quoted
+ 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;If cpu_end hits 0x1_00000000, it'll overflow to 0. This is possible on 32-bit systems (LPAE or not). And something similar might happen on LPAE disabled systems. I could add some extra logic, something like: /* We overflowed */ if (cpu_end < range.cpu_addr) cpu_end = PHYS_ADDR_MAX; Which is not perfect but will cover most sensible cases. Or simply deal internally in u64s, and upon returning, check if "max_cpu_addr" falls higher than PHYS_ADDR_MAX.
Just use a u64 for cpu_end
quoted
quoted
quoted
+ + if (max_cpu_addr > cpu_end) + max_cpu_addr = cpu_end;
... then this comparison and assignment will work as expected.
quoted
quoted
quoted
+ } + + 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; +}Regards, Nicolas
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel