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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 7D40DC433DF for ; Thu, 8 Oct 2020 16:57:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2E1B21D7D for ; Thu, 8 Oct 2020 16:57:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WtI9YaAx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2E1B21D7D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-mips.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R3/b8cPJysg/q6ygedqh5VMnsOeDR4oqXGEV74EJuf8=; b=WtI9YaAxbJi/CCfBm+SJhxrW7 QOcc2tdpPP29NdB1sD7MUmtqJ59fYPjTcJEw1wzEdqn9lLW0LVBoIOXRwFZ8+PN2GoTR8q0nZ7M6/ Ei6ilnZFwWxFWgGgI1rq4O2qIlBuMYZdK9zr9PCXGclWZVb9yc2DXe/zgaoImFHtAI7DMgJCr3XiY j0OsrRnlsIKs9u7t9p0xOf//Qgm/yudiNaPS2WhzcDlr1goxZQDX9glVt8hGZhgBv277Dz9K6MJej poNhBa0zrRYH0UMSwuyMVgTKNImZ/U4VDoZVhjY/ghnYffufvu9K+5/gGZEk+413HeOO/cXtB2ADp jTRKykd9A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZDP-0006aM-6P; Thu, 08 Oct 2020 16:56:27 +0000 Received: from [2001:4190:8020::2] (helo=orcam.me.uk) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZDL-0006Zt-Og for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 16:56:25 +0000 Received: from bugs.linux-mips.org (eddie.linux-mips.org [IPv6:2a01:4f8:201:92aa::3]) by orcam.me.uk (Postfix) with ESMTPS id A09E02BE086; Thu, 8 Oct 2020 17:56:18 +0100 (BST) Date: Thu, 8 Oct 2020 17:56:17 +0100 (BST) From: "Maciej W. Rozycki" To: Serge Semin Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock In-Reply-To: <20201008155454.kaal2bchjq7wusqr@mobilestation> Message-ID: References: <20201008084357.42780-1-tsbogend@alpha.franken.de> <20201008152006.4khkbzsxqmmz76rw@mobilestation> <20201008155454.kaal2bchjq7wusqr@mobilestation> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_125624_329322_56AA9FFC X-CRM114-Status: GOOD ( 20.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , Hauke Mehrtens , =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= , linux-mips@vger.kernel.org, Jiaxun Yang , linux-kernel@vger.kernel.org, Thomas Bogendoerfer , bcm-kernel-feedback-list@broadcom.com, John Crispin , Keguang Zhang , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 8 Oct 2020, Serge Semin wrote: > > > At least I don't see a decent reason to preserve them. The memory registration > > > method does nearly the same sanity checks. The memory reservation function > > > defers a bit in adding the being reserved memory first. That seems redundant, > > > since the reserved memory won't be available for the system anyway. Do I miss > > > something? > > > > > At the very least it serves informational purposes as it shows up in > > /proc/iomem. > > I thought about that, but /proc/iomem prints the System RAM up. Adding the reserved > memory regions to be just memory region first still seem redundant, since > reserving a non-reflected in memory region most likely indicates an erroneous > dts. I failed to find that, but do the kernel or DTC make sure that the reserved > memory regions has actual memory behind? (At least in the framework of the > memblock.memory vs memblock.reserved arrays or in the DT source file) Reserved regions need not be RAM or a memory-like device. They could be floating bus even. Here's an example from my x86 laptop where all kinds of stuff is marked reserved: 00000000-00000fff : Reserved 00001000-0009cfff : System RAM 0009d000-0009ffff : Reserved 000a0000-000bffff : PCI Bus 0000:00 000c0000-000cebff : Video ROM 000d0000-000d3fff : pnp 00:0b 000d8000-000dbfff : pnp 00:0b 000e0000-000fffff : Reserved 000f0000-000fffff : System ROM 00100000-5f24afff : System RAM 5f24b000-5f24cfff : Reserved 5f24d000-5fee5fff : System RAM 5fee6000-5fee6fff : Reserved 5fee7000-6daecfff : System RAM 6daed000-729bafff : Reserved 729bb000-729bbfff : ACPI Non-volatile Storage 729bc000-7fefefff : Reserved 7feff000-7ff99fff : ACPI Non-volatile Storage 7ff9a000-7fffefff : ACPI Tables 7ffff000-87ffffff : Reserved 80200000-85f7ffff : INT0E0C:00 88600000-89ffffff : Reserved 8a000000-efffffff : PCI Bus 0000:00 c0000000-d1ffffff : PCI Bus 0000:01 c0000000-cfffffff : 0000:01:00.0 d0000000-d1ffffff : 0000:01:00.0 d4000000-ea0fffff : PCI Bus 0000:05 eb000000-ec0fffff : PCI Bus 0000:01 eb000000-ebffffff : 0000:01:00.0 ec100000-ecafffff : PCI Bus 0000:03 ecb00000-ecbfffff : PCI Bus 0000:3f ecb00000-ecb00fff : 0000:3f:00.0 ecb00000-ecb00fff : rtsx_pci ecc00000-eccfffff : PCI Bus 0000:3e ecc00000-ecc03fff : 0000:3e:00.0 ecc00000-ecc03fff : nvme ecd00000-ecdfffff : PCI Bus 0000:04 ecd00000-ecd01fff : 0000:04:00.0 ecd00000-ecd01fff : iwlwifi ece00000-ed7fffff : PCI Bus 0000:03 ed800000-ed8fffff : PCI Bus 0000:02 ed800000-ed803fff : 0000:02:00.0 ed800000-ed803fff : nvme ed900000-ed91ffff : 0000:00:1f.6 ed900000-ed91ffff : e1000e ed920000-ed92ffff : 0000:00:14.0 ed920000-ed92ffff : xhci-hcd ed930000-ed933fff : 0000:00:1f.2 effe0000-efffffff : pnp 00:08 effe0000-efffffff : pnp 00:0a f0000000-f7ffffff : PCI MMCONFIG 0000 [bus 00-7f] f0000000-f7ffffff : Reserved f0000000-f7ffffff : pnp 00:08 f0000000-f7ffffff : pnp 00:0a fd000000-fe7fffff : Reserved fd000000-fe7fffff : PCI Bus 0000:00 fd000000-fdabffff : pnp 00:00 fdac0000-fdacffff : INT345D:00 fdac0000-fdacffff : INT345D:00 fdad0000-fdadffff : pnp 00:00 fdae0000-fdaeffff : INT345D:00 fdae0000-fdaeffff : INT345D:00 fdaf0000-fdafffff : INT345D:00 fdaf0000-fdafffff : INT345D:00 fdb00000-fdffffff : pnp 00:00 fdc6000c-fdc6000f : iTCO_wdt fdc6000c-fdc6000f : iTCO_wdt fe000000-fe01ffff : pnp 00:00 fe036000-fe03bfff : pnp 00:00 fe03d000-fe3fffff : pnp 00:00 fe410000-fe7fffff : pnp 00:00 feb00000-febfffff : pnp 00:08 fec00000-fec00fff : Reserved fec00000-fec003ff : IOAPIC 0 fed00000-fed00fff : Reserved fed00000-fed003ff : HPET 0 fed00000-fed003ff : PNP0103:00 fed10000-fed19fff : Reserved fed10000-fed13fff : pnp 00:08 fed18000-fed18fff : pnp 00:08 fed18000-fed18fff : pnp 00:0a fed19000-fed19fff : pnp 00:08 fed19000-fed19fff : pnp 00:0a fed20000-fed3ffff : pnp 00:08 fed20000-fed3ffff : pnp 00:0a fed84000-fed84fff : Reserved fed90000-fed93fff : pnp 00:08 fed90000-fed93fff : pnp 00:0a fee00000-fee00fff : Local APIC fee00000-fee00fff : Reserved ff000000-ffffffff : INT0800:00 ff800000-ffffffff : Reserved 100000000-873ffffff : System RAM 4bb200000-4bbc031d0 : Kernel code 4bbc031d1-4bc334e7f : Kernel data 4bc7b7000-4bc9fffff : Kernel bss 2000000000-2fffffffff : PCI Bus 0000:00 2fd0000000-2ff1ffffff : PCI Bus 0000:05 2ff2000000-2ff200ffff : 0000:00:1f.3 2ff2000000-2ff200ffff : ICH HD audio 2ff2010000-2ff2013fff : 0000:00:1f.3 2ff2010000-2ff2013fff : ICH HD audio 2ff2014000-2ff20140ff : 0000:00:1f.4 2ff2015000-2ff2015fff : 0000:00:16.0 2ff2015000-2ff2015fff : mei_me 2ff2016000-2ff2016fff : 0000:00:15.0 2ff2016000-2ff20161ff : lpss_dev 2ff2016000-2ff20161ff : lpss_dev 2ff2016200-2ff20162ff : lpss_priv 2ff2016800-2ff2016fff : idma64.0 2ff2016800-2ff2016fff : idma64.0 2ff2017000-2ff2017fff : 0000:00:14.2 2ff2017000-2ff2017fff : Intel PCH thermal driver 2ff2018000-2ff2018fff : 0000:00:08.0 Actually another reason to mark regions reserved is to prevent them from being claimed by the wrong driver or, perhaps more importantly, used for assigning bus address ranges to hardware resources (BAR programming). > I also don't see the other platforms doing that, since the MIPS arch only > redefines these methods. So if a problem of adding a reserved memory with > possible no real memory behind exist, it should be fixed in the cross-platform > basis, don't you think? I think doing things in a generic way where possible is surely desired, however platforms have different ways to discover resources and I can't see offhand how this could be unified. I haven't look at that code for a while now, so I can't be more specific offhand. Maciej _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel