On Fri, 26 Jul 2024 at 05:02, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Wed, 24 Jul 2024 at 00:04, Sughosh Ganu sughosh.ganu@linaro.org wrote:
Add a flags parameter to the LMB API functions. The parameter can then be used to pass any other type of reservations or allocations needed by the callers. These will be used in a subsequent set of changes for allocation requests coming from the EFI subsystem.
Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org
Changes since rfc: New patch
arch/arm/mach-apple/board.c | 17 ++-- arch/arm/mach-snapdragon/board.c | 2 +- arch/arm/mach-stm32mp/dram_init.c | 4 +- arch/powerpc/cpu/mpc85xx/mp.c | 2 +- arch/powerpc/lib/bootm.c | 2 +- board/xilinx/common/board.c | 4 +- boot/bootm.c | 5 +- boot/image-board.c | 15 ++- boot/image-fdt.c | 15 +-- cmd/booti.c | 2 +- cmd/bootz.c | 2 +- cmd/load.c | 4 +- drivers/iommu/apple_dart.c | 6 +- drivers/iommu/sandbox_iommu.c | 6 +- fs/fs.c | 2 +- include/lmb.h | 23 ++--- lib/lmb.c | 48 ++++------ test/lib/lmb.c | 150 +++++++++++++++--------------- 18 files changed, 150 insertions(+), 159 deletions(-)
This negates any code-size advantage of dropping the lmb parameter.
All of these are LMB_NONE. Can we have a separate function (e.g. lmb_alloc_type()) for when we actually need to specify the type?
We will be passing different values when we call the LMB API's from the EFI allocation function. This is only adding a parameter to the allocation API's, which I believe is better than adding separate functions which take a flag parameter only to be called from the EFI subsystem.
-sughosh