Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3455580pxv; Sun, 18 Jul 2021 23:59:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3S3qxx4f9VNec2fW3eK9KzbZyia509pcrqp527PnBVharK1vFdLwgmTs/NsoTbiZ/jeam X-Received: by 2002:a92:8707:: with SMTP id m7mr16064087ild.177.1626677998232; Sun, 18 Jul 2021 23:59:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626677998; cv=none; d=google.com; s=arc-20160816; b=qdYo4KC7F4ImWFGYUUifzDgkMs3C7vNVCJNG67SBENzwNeXbl3Ixf7lm/pc02CJAC6 P6TC/tyO0jQkO29d1tpg5cjHtEzI5CUmacua7Aovujmli1AwkNyC8BiTiNB4UxgvarSK +PG+UMwDymaEBofebzw5CtJfAMmdtbrXDyFAzjrKhBfID89vHEtS6p3wsqaspY/oWKax aIXXWdjcI5frk8qxp/g8KwdEcemQptTr9QgPRDRgaYthxHrGMj9UekRwH3q0gJG32Bf6 wd3fQbznwGPY8cQOpYmA+w8zQ6ku+kEIztoH15oKqZdyKX+Mp5XOMTAPN7xrJbBY+W0u 8qWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=5NCNcBqTO22l3X4al8acu9AJJxnhiYKAu5aMxQckPxk=; b=m+UQdWzgwj0+JpJBg7Mlcyc2ipd47R42ob7c2YusyGY9zO2Q3VDsVoSz+Grg9Y4HhC fV9GT/JTcgyKAgfyMlSCqfskTJveMbCVOcEPpOziMtlAbuv6X/1rZNAX+djqCiNY2QOK Onp54ueaYbPSwQ95qUMXAayhlbJaO4EyRnZo8Fhk36rHtSrAAbC6DIYSvzzPuhJK4krP Xhv5iRsgzAfkNmZ6j3n4ZHK4HX9eH80KdcyqcftI87kw2Jjtjy7QWbhAcJgoKXCja0dI yl0fWp0lTEhbCdACxR3FFDumrK+8tcKucu7lx0NL6Q6XT1jFdRjKjtARK9cKBqmEda4w j0Xw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v8si9518594jas.68.2021.07.18.23.59.46; Sun, 18 Jul 2021 23:59:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234441AbhGSHCQ (ORCPT + 99 others); Mon, 19 Jul 2021 03:02:16 -0400 Received: from mail-vs1-f42.google.com ([209.85.217.42]:36781 "EHLO mail-vs1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233689AbhGSHCP (ORCPT ); Mon, 19 Jul 2021 03:02:15 -0400 Received: by mail-vs1-f42.google.com with SMTP id o19so6590054vsn.3; Sun, 18 Jul 2021 23:59:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5NCNcBqTO22l3X4al8acu9AJJxnhiYKAu5aMxQckPxk=; b=esA7f/1eOryitydOtRRS2BR2NntUeAYOildsJ++BtaV2UgFY/PHnBdvTAwWx1tooj0 aVU0i9faVWu5HTcdmu5cCFk+I95yrKdLCepWeDBRX9zWmUW6YOUmUXts6VkcngduORQm q392loYQcBcBvoatdfPz7OMjqTnlOJhPq6Fij5skcdi1opoNWY4/2YhHS5Br9U5ZjmFL 5v3tHRa9+I8DmzmKB5/ggXW5+jxQS9KM/yqh3caTwAUwV1RkqdQNXRhU2ewUVL4VnzIj MileSrc5+XgSG58dE1L7JlD0qpEJ4VZD70Dw8Fz/UkFLIPQaM0hX/v6HKmdYqGAKPqgY jHLQ== X-Gm-Message-State: AOAM533buOuzs17GPI1hr9h/ZAKOezUsx3Nmn+HkLLRGnBhnp321A+XP /J6tNmbhqeE2xtdRzsUEgrv9YZZQu8hmm8Pm554= X-Received: by 2002:a67:1542:: with SMTP id 63mr23590649vsv.40.1626677954982; Sun, 18 Jul 2021 23:59:14 -0700 (PDT) MIME-Version: 1.0 References: <04c4d231fb03a3810d72a45c8a5bc2272c5975f3.1626266516.git.geert+renesas@glider.be> <20210714135101.GB2441138@robh.at.kernel.org> In-Reply-To: From: Geert Uytterhoeven Date: Mon, 19 Jul 2021 08:59:03 +0200 Message-ID: Subject: Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation To: Mike Rapoport Cc: Rob Herring , 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 , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , linux-riscv , kexec@lists.infradead.org, Linux MM , Linux-Renesas , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mike, On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport wrote: > 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. I will have a look... > 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. Me neither ;-) > 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. "linux,usable-memory-range" is optional, and typically used only in crashdump kernels, so it would be a bad idea to add such a warning. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds