From patchwork Tue Jun 17 10:43:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sughosh Ganu X-Patchwork-Id: 897363 Delivered-To: patch@linaro.org Received: by 2002:adf:9b99:0:b0:3a4:ee3f:8f15 with SMTP id d25csp2073709wrc; Tue, 17 Jun 2025 03:44:09 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUMRrLxv3BW0R/xylpUJ+Fo/eNkpT0fqy+0dR5QamLfra12vMfjx++8xOo3ukSSKcnW+xXI0A==@linaro.org X-Google-Smtp-Source: AGHT+IEhHL7FN4MS4FKYSP5szdGyv96alnDJ2L3CBBDOiTRr1LZUGk364PRAmV+6SmODHkaj8Tl9 X-Received: by 2002:a05:622a:316:b0:4a7:1525:42ff with SMTP id d75a77b69052e-4a73c385608mr181041461cf.0.1750157049467; Tue, 17 Jun 2025 03:44:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750157049; cv=none; d=google.com; s=arc-20240605; b=DsVm+eGOXGUs6sFBveMedd/ow2aTbW+i92itohJtYg5yn/BwW8c7WCMyhTtxxNrArO 3xjAoxa5JtRRvpPL5/NqizHhrVJ7V7nHiLEopTfDE7BiP7J6XyHlcKyThiPOGXsGW2RD Vx4o1vV2KdVy3v8PaBL49daQypR0HBtLLBj1/tmDyw0rHrh/PToOL58z6xAcqYhhFtSF +XMua5uvaoXGhxlKkGZ9J2OuRlJsD34GWucIMQLdcRbOBPBP1JZg2xqxToX8JMnOP4CW TpZqIppYykK3R8chXQDwXeJaNZFzw7DrHZuoIrJKXecyU5bcX7uBb/JkT6TqBJjH6nm4 GRIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from; bh=+4MKtL9UDn27wg8CtDv+mgkHxAurxNaGsvgqAdoSYEg=; fh=89MlnLdazmnhKnYeHaI4JcicUnUrLLJuTd/r2dh4RLc=; b=aJ2HqTZIqZqin/bP5ob+DQyZjP4lbREGREptjq/wVmtEMzqOp+8Ii+WbmygYykoik2 R8nU9B0Pv4Y7ScRu0lAEHK5kmwQHqm3TG/n//36Fxon0Uh/jUnHX/8lVN4EicDjZG6mR T8OEfIVlqK424uw1YwK7mzARjtTZaB3cunzla73MPre2y8iXMI7Efp1dcEMwPLk2x2+7 FLB6PO6y2KNvsiPtY3hXbCiIQV9JIlJYbhcxNoYMoLjurOTL5TfilG1+oXWdXln59TYx N9MKteWy2uBdRwJW4hjuJg9JGe/X7dJp9vYVKtkt2RsrzxA5JMQ4A16TKv3Fixj1b29b L5NA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) smtp.mailfrom=u-boot-bounces@lists.denx.de; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from phobos.denx.de (phobos.denx.de. [2a01:238:438b:c500:173d:9f52:ddab:ee01]) by mx.google.com with ESMTPS id d75a77b69052e-4a72a2b8f79si121967491cf.120.2025.06.17.03.44.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jun 2025 03:44:09 -0700 (PDT) Received-SPF: pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; Authentication-Results: mx.google.com; spf=pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) smtp.mailfrom=u-boot-bounces@lists.denx.de; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7B8BC82C2F; Tue, 17 Jun 2025 12:44:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id CE85182C79; Tue, 17 Jun 2025 12:44:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 87CBE82BCD for ; Tue, 17 Jun 2025 12:44:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sughosh.ganu@linaro.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ACA8E1596; Tue, 17 Jun 2025 03:43:42 -0700 (PDT) Received: from a079122.blr.arm.com (a079122.arm.com [10.164.21.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C30593F58B; Tue, 17 Jun 2025 03:44:00 -0700 (PDT) From: Sughosh Ganu To: u-boot@lists.denx.de Cc: Ilias Apalodimas , Tom Rini , Casey Connolly , Neil Armstrong , Mark Kettenis , Weijie Gao , Heinrich Schuchardt , Simon Glass Subject: [PATCH v5 0/7] lmb: use a single API for all allocations Date: Tue, 17 Jun 2025 16:13:39 +0530 Message-Id: <20250617104346.1379981-1-sughosh.ganu@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean The LMB module has a bunch for API's which are used for allocating memory. There are a couple of API's for requesting memory, and two more for reserving regions of memory. Replace these different API's with a single one, lmb_alloc_mem(). The type of allocation to be made is specified through one of the parameters to the function. Additionally, the two API's for reserving regions of memory, lmb_reserve() and lmb_alloc_addr() are the same with one difference. One can reserve any memory region with lmb_reserve(), while lmb_alloc_addr() actually checks that the memory region being requested is part of the LMB memory map. Reserving memory that is not part of the LMB memory map is pretty futile -- the allocation functions do not allocate memory which has not been added to the LMB memory map. This series also removes the functionality allowing for reserving memory regions outside the LMB memory map. Any request for reserving a region of memory outside the LMB memory map now returns an -EINVAL error. Certain places in the common code using the LMB API's were not checking the return value of the functions. Checks have been added for them. There are some calls being made from the architecture/platform specific code which too do not check the return value. Those have been kept the same, as I do not have the platform with me to check if it causes any issues on those platforms. In addition, there is a patch which refactors code in lmb_overlaps_region() and lmb_can_reserve_region() so that both functionalities can be put in a single function, lmb_overlap_checks(). Finally, a new patch has been added which checks the return value of the lmb allocation function before copying the device-tree to the allocated address. Changes since V4: * Remove the superfluous return from _lmb_alloc_addr() - patch 1 Sughosh Ganu (7): lmb: replace lmb_reserve() and lmb_alloc_addr() API's lmb: replace the lmb_alloc() and lmb_alloc_base() API's lmb: staticise lmb_add_memory() lmb: use a single function to free up memory lmb: use a single function to check for allocation and reservation requests mach-snapdragon: add a check before copying FDT to fdt_addr_r doc: add lmb documentation arch/arm/mach-apple/board.c | 27 +++-- arch/arm/mach-mediatek/tzcfg.c | 8 +- arch/arm/mach-snapdragon/board.c | 41 ++++--- arch/powerpc/cpu/mpc85xx/mp.c | 4 +- arch/powerpc/lib/misc.c | 5 +- boot/bootm.c | 27 +++-- boot/image-board.c | 56 ++++++---- boot/image-fdt.c | 69 ++++++++---- cmd/booti.c | 10 +- cmd/bootz.c | 10 +- cmd/load.c | 9 +- doc/api/index.rst | 1 - doc/api/lmb.rst | 7 -- doc/develop/index.rst | 1 + doc/develop/lmb.rst | 166 ++++++++++++++++++++++++++++ fs/fs.c | 5 +- include/lmb.h | 105 ++++++++---------- lib/efi_loader/efi_memory.c | 22 ++-- lib/lmb.c | 183 ++++++++++++++++--------------- test/lib/lmb.c | 102 +++++++++++------ 20 files changed, 578 insertions(+), 280 deletions(-) delete mode 100644 doc/api/lmb.rst create mode 100644 doc/develop/lmb.rst