From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B4BFC636C8 for ; Sun, 18 Jul 2021 09:31:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0EFC1611AB for ; Sun, 18 Jul 2021 09:31:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EFC1611AB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4895D8D00F4; Sun, 18 Jul 2021 05:31:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 439DD8D00EC; Sun, 18 Jul 2021 05:31:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DA308D00F4; Sun, 18 Jul 2021 05:31:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 08F2B8D00EC for ; Sun, 18 Jul 2021 05:31:37 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 966B7181AEF1A for ; Sun, 18 Jul 2021 09:31:36 +0000 (UTC) X-FDA: 78375190992.32.C2B0802 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP id 58EA670009D9 for ; Sun, 18 Jul 2021 09:31:36 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 34BC960C3F; Sun, 18 Jul 2021 09:31:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626600693; bh=+rDFm9FsoZ08b6sGG01ofP3oHAAfan2l2sSh1XQwSR0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aAJYxQFsJbdGWKQX5mdFOrV/4Mbkl/qDKVE1yIy9pxZq4HHu+AWBm7dAXBHiriHrG M6m8IZZlz8muKxk60d6kD7Ci0+jfD6udeh8+tb/Wjp4ehaNbxOk+whVAujiNEkYQKS PHKvYjq3fNIu4UVm+Z7v4s1fZPkunITPVAf1yELADkVpf4vJWy/8lOCgPU6CkkrMob G2A2DWUH3/st5jP+5I66EBcTvI628tSgsh/H2qXMbgg5RGPD0p0Qgg9hCd2BSvFR0S Mooq4W/uqRwgTonQqFVILswVYaEe6mhHurnQ/7N9BoQJY/gSkg9c01sBSpCcowA3bv jBJiC2NBzPWPw== Date: Sun, 18 Jul 2021 12:31:21 +0300 From: Mike Rapoport To: Rob Herring Cc: Geert Uytterhoeven , Russell King , Nicolas Pitre , Ard Biesheuvel , Linus Walleij , Catalin Marinas , Will Deacon , Nick Kossifidis , Paul Walmsley , Palmer Dabbelt , Albert Ou , Frank Rowand , Dave Young , Baoquan He , Vivek Goyal , Andrew Morton , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kexec@lists.infradead.org, linux-mm@kvack.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation Message-ID: References: <04c4d231fb03a3810d72a45c8a5bc2272c5975f3.1626266516.git.geert+renesas@glider.be> <20210714135101.GB2441138@robh.at.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210714135101.GB2441138@robh.at.kernel.org> Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aAJYxQFs; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 58EA670009D9 X-Stat-Signature: 46yycea84zootgtn8n343ozzet5d8475 X-HE-Tag: 1626600696-836928 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote: > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > Add two global variables (cap_mem_addr and cap_mem_size) for storing a > > base address and size, describing a limited region in which memory may > > be considered available for use by the kernel. If enabled, memory > > outside of this range is not available for use. > > > > These variables can by filled by firmware-specific code, and used in > > calls to memblock_cap_memory_range() by architecture-specific code. > > An example user is the parser of the "linux,usable-memory-range" > > property in the DT "/chosen" node. > > > > Signed-off-by: Geert Uytterhoeven > > --- > > This is similar to how the initial ramdisk (phys_initrd_{start,size}) > > and ELF core headers (elfcorehdr_{addr,size})) are handled. > > > > Does there exist a suitable place in the common memblock code to call > > "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this > > have to be done in architecture-specific code? > > Can't you just call it from early_init_dt_scan_usablemem? If the > property is present, you want to call it. If the property is not > present, nothing happens. For memblock_cap_memory_range() to work properly it should be called after memory is detected and added to memblock with memblock_add[_node]() I'm not huge fan of adding more globals to memblock so if such ordering can be implemented on the DT side it would be great. I don't see a way to actually enforce this ordering, so maybe we'd want to add warning in memblock_cap_memory_range() if memblock.memory is empty. > Rob -- Sincerely yours, Mike.