u-boot.git/include/lmb.h, branch v2025.04

lmb: change the return code on lmb_alloc_addr()

2025-03-24T17:12:33Z

Ben reports a failure to boot the kernel on hardware that starts its physical memory from 0x0. The reason is that lmb_alloc_addr(), which is supposed to reserve a specific address, takes the address as the first argument, but then also returns the address for success or failure and treats 0 as a failure. Since we already know the address change the prototype to return an int. Reported-by: Ben Schneider Signed-off-by: Ilias Apalodimas Tested-by: Ben Schneider Reviewed-by: Sughosh Ganu

lmb: avoid superfluous value check in lmb_map_update_notify()

2025-02-20T10:09:33Z

Instead of testing the value of parameter op at runtime use an enum to ensure that only valid values are used. Reviewed-by: Ilias Apalodimas Signed-off-by: Heinrich Schuchardt

lmb: Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()

2024-12-30T19:21:55Z

lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags() and remove the wrapper. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Remove lmb_alloc_base_flags()

2024-12-30T19:21:55Z

lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE. There's not much we gain from this abstraction, so let's remove the former add the flags argument to lmb_alloc_base() and make the code a bit easier to follow. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Remove lmb_alloc_addr_flags()

2024-12-30T19:21:55Z

lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE There's not much we gain from this abstraction, so let's remove the latter, add a flags argument to lmb_alloc_addr() and make the code a bit easier to follow. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Rename free_mem to available_mem

2024-12-30T19:21:55Z

free_mem is a misnomer. We never update it with the free memory for LMB. Instead, it describes all available memory and is checked against used_mem to decide whether an area is free or not. So let's rename this field to better match its usage. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Remove lmb_reserve_flags()

2024-12-30T19:21:55Z

lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE. There's not much we gain from this abstraction. So let's remove the latter, add the flags argument to lmb_reserve() and make the code a bit easier to follow. Reviewed-by: Tom Rini Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Move enum lmb_flags to a u32

2024-12-30T19:21:55Z

LMB flags is not an enum anymore. It's currently used as a bitmask in various places of our code. So make it a u32 which is more appropriate when dealing with masks. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Improve kernel-doc comments

2024-12-30T19:20:24Z

Fix warnings from kernel-doc script. Improve and unify overall style of kernel-doc comments in lmb source files. Move all kernel-doc comments for public functions into the header, as recommended in U-Boot documentation [1]: Non-trivial functions should have a comment which describes what they do. If it is an exported function, put the comment in the header file so the API is in one place. If it is a static function, put it in the C file. This also takes care of existing duplication. While at it, do a bit of cosmetic cleanups as well. No functional change. [1] doc/develop/codingstyle.rst Signed-off-by: Sam Protsenko Acked-by: Ilias Apalodimas

Merge patch series "Fix IOVA allocation in Apple dart iommu after global LMB mem map changes"

2024-11-11T15:11:55Z

Janne Grunau says: The changes in "Make LMB memory map global and persistent" [1] break mapping DMA memory in the USB xHCI driver when using the apple_dart iommu present on Apple silicon systems. The IOVA space used by the u-boot driver (low 4GB) and physical memory do not overlap. The physical memory on this systems starts depending on the SoC either at 0x10_0000_0000 or 0x100_0000_0000. It make no sense to manage these distinct regions in a single LMB map. In addition every device has its own iommu and IO address space so sharing a single memory map between all iommu instances is not necessary. To fix this issue restore the used subset (add, alloc and free) of the previous pointer based LMB interface with "io_" as prefix. To ensure that low level lmb functions do not use the global LMB variable reorder lib/lmb.c so that the variable is not visible. Tested with patches from my "Fix device removal order for Apple dart iommu" series [2] to fix a separate issue. The cosmetic commit has two checkpatch warnings in existing code which I ignored. [1] https://lore.kernel.org/u-boot/20240826115940.3233167-1-sughosh.ganu@linaro.org/ [2] https://lore.kernel.org/u-boot/20241031-iommu_apple_dart_ordering-v1-0-8a6877946d6b@jannau.net/ Link: https://lore.kernel.org/r/20241111-io_lmb_apple_dart_iommu-v3-0-32c05da51d72@jannau.net Signed-off-by: Tom Rini