From patchwork Thu May 1 12:02:34 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sughosh Ganu X-Patchwork-Id: 886331 Delivered-To: patch@linaro.org Received: by 2002:a5d:430f:0:b0:38f:210b:807b with SMTP id h15csp278444wrq; Thu, 1 May 2025 05:03:03 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUrEx8pEoIP7ier0rmQ8fDcWgLS/gf78/WCQOpgMYTxNWY7sKd4rfrCvheZvbE/+iuWZgpsgw==@linaro.org X-Google-Smtp-Source: AGHT+IHy7BPLywlVLeIaf/LUAA3gbhX8rzQCilfuICWRmFixpU5Pm9i7q1S8Olzs/O1qQsFZ+5RC X-Received: by 2002:a5d:5f8a:0:b0:391:412b:e23f with SMTP id ffacd0b85a97d-3a093035823mr1936479f8f.15.1746100983625; Thu, 01 May 2025 05:03:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1746100983; cv=none; d=google.com; s=arc-20240605; b=fTqcZ55QLa2D/7LOgBWNoVz2TgbsAcuYZe2GmVepmMQnkJJuvJQZK52/y8lsYXM/e/ ff1Z8Eo+W1ZgTylXGxalO0RxoMMYjFsJc2GuUTrP5NgOM16hufoeE8smANWSXQ6+8/v9 6x/n/AKMx65fIZj3f1OYUzTUSmkgiF3mFXVNT3GC7Rd5XZikoDheiF9l9E6jHrBzla+U VXc8vIFej1R0hLUPLRxMUxJWJifPVl54EkTnlaA3OSTAexW+oSLaaLTymhuyP2V5XE7l J35oeUH2PuJEz7/2Bfd3MQKliQWNJARCskzyEBD1M1+1Vaz4gRNbSzzgANlabCujmzjJ MT3g== 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=g6JNBLZsHtiurdZcD4SzPA/7nnOiCubSaG/RBFH3Nbw=; fh=89MlnLdazmnhKnYeHaI4JcicUnUrLLJuTd/r2dh4RLc=; b=h57fr4c9c2Wql6+r5idT2hkgEsOO2JCXSj1zFo3+9C82sFLru7NFm0JUCOk6f/2sTf ewSG3BKgxAD6DHHd7OOvvSXRNpYjF3ZBwjpmeI4X5w6iceWMfnthW8YLp0yvu6tMoW6v P0PfeTcNRVO4uq5MqDSH6+VJvXoV9YuId7EYRtS+QbATojJvCVr1uVxBqgC2WKnIrL6T wVYFAmQ1wn72NGSsBT5MPqDVEa2lXjpvSVZTwt+9lXmuwJwTL/cAHarmW9VBGxKYY0kc zCDs72UFW4T+r+FVwx3clnZUndFM4FYInzXbLQjCchWb8L+p4Ox2H4HhzdzPV5aEBbe1 fr/w==; 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 ffacd0b85a97d-3a095a88a72si327232f8f.560.2025.05.01.05.03.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 05:03:03 -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 3DD0A8081A; Thu, 1 May 2025 14:03:02 +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 C8C508081A; Thu, 1 May 2025 14:03:00 +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_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_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 A72098056A for ; Thu, 1 May 2025 14:02:58 +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 490EC106F; Thu, 1 May 2025 05:02:50 -0700 (PDT) Received: from a079122.blr.arm.com (a079122.arm.com [10.162.17.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4043B3F673; Thu, 1 May 2025 05:02:55 -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 0/5] lmb: use a single API for all allocations Date: Thu, 1 May 2025 17:32:34 +0530 Message-Id: <20250501120239.199829-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_allocate_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. Sughosh Ganu (5): 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 doc: add lmb documentation arch/arm/mach-apple/board.c | 27 +++-- arch/arm/mach-mediatek/tzcfg.c | 8 +- arch/arm/mach-snapdragon/board.c | 13 ++- arch/powerpc/cpu/mpc85xx/mp.c | 4 +- arch/powerpc/lib/misc.c | 5 +- boot/bootm.c | 11 +- boot/image-board.c | 49 +++++---- boot/image-fdt.c | 67 +++++++++--- cmd/booti.c | 8 +- cmd/bootz.c | 8 +- cmd/load.c | 6 +- doc/api/index.rst | 1 - doc/api/lmb.rst | 7 -- doc/develop/index.rst | 1 + doc/develop/lmb.rst | 166 ++++++++++++++++++++++++++++++ fs/fs.c | 3 +- include/lmb.h | 101 ++++++++---------- lib/efi_loader/efi_memory.c | 22 ++-- lib/lmb.c | 171 +++++++++++++++++-------------- test/lib/lmb.c | 102 ++++++++++++------ 20 files changed, 535 insertions(+), 245 deletions(-) delete mode 100644 doc/api/lmb.rst create mode 100644 doc/develop/lmb.rst