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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 EFFCFC2D0A3 for ; Tue, 3 Nov 2020 16:52:18 +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 3D84820756 for ; Tue, 3 Nov 2020 16:52:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jMoqPx7I"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="HQdZwz6q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D84820756 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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:In-Reply-To:MIME-Version:References:Message-ID: 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=JSO68Jyb6tdVDdph8kpmuIW1yFrvHqQRQ/oJiG4zOAI=; b=jMoqPx7Iy7rMGOIRdMMq0T4g7 B4jYR2ycQdfrqDnUtjexLC8ewaQi0z/qwIu5Y04F2t5/EaEgYaIpiDg5ihUY7qs5nd3i/i1oG8ZfO 1QLRPZ56aTHeHksXJlKB3EIMryDKxfcztEzlv4U5Rkcd0+2hBQM4wvH5Gw5GvmY7VWsZEMSIPGvGI X8VlxxVQLeomSeEgF1rAox3fn4KvNufM6ftBF5gZ9/zwKzEh5h9O5rZ+Sm4BDk6UjPjhLdpMSN0OP e//2ZlnhA4Rd9GW5LqH9ohlh3C/9sL15kD/aTm42nBgsWiZADd07OtNYM5s9tFLFR4gQc98s7V8QX YUCYbL27w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZzX8-0007Rh-GC; Tue, 03 Nov 2020 16:51:46 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZzX5-0007R5-9Y for linux-arm-kernel@lists.infradead.org; Tue, 03 Nov 2020 16:51:44 +0000 Received: from kernel.org (unknown [87.71.17.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A364F20709; Tue, 3 Nov 2020 16:51:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604422302; bh=ltFWbwZrKzlRod8Ro/4wG6vMt94SJxaRjMtj1TLMLYc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HQdZwz6qSkFP7g8HiqaXmRItKdiuPmA3b/89ZigFPfM+QNyFJ7qO4NcRNf830wSRS R+sL56de+WHAQIIJx3bhWqgcQQLsgy2ccFyTuOhz/Pbr9c4FY60sCCbbw7rbb9asSx sKgdTAe6PpIiHcbikl84KlDdGFr90ZoCWhA3rSuo= Date: Tue, 3 Nov 2020 18:51:34 +0200 From: Mike Rapoport To: Sudarshan Rajagopalan Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM Message-ID: <20201103165134.GL4879@kernel.org> References: <20201030083842.GA4319@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201103_115143_561334_858F43E1 X-CRM114-Status: GOOD ( 35.74 ) 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: Mark Rutland , David Hildenbrand , Catalin Marinas , Anshuman Khandual , linux-kernel@vger.kernel.org, Steven Price , Suren Baghdasaryan , Greg Kroah-Hartman , Will Deacon , linux-arm-kernel@lists.infradead.org, Pratik Patel Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gTW9uLCBOb3YgMDIsIDIwMjAgYXQgMDY6NTE6MjVQTSAtMDgwMCwgU3VkYXJzaGFuIFJhamFn b3BhbGFuIHdyb3RlOgo+IE9uIDIwMjAtMTAtMzAgMDE6MzgsIE1pa2UgUmFwb3BvcnQgd3JvdGU6 Cj4gPiBPbiBUaHUsIE9jdCAyOSwgMjAyMCBhdCAwMjoyOToyN1BNIC0wNzAwLCBTdWRhcnNoYW4g UmFqYWdvcGFsYW4gd3JvdGU6Cj4gPiA+IEhlbGxvIGFsbCwKPiA+ID4gCj4gPiA+IFdlIGhhdmUg YSB1c2VjYXNlIHdoZXJlIGEgbW9kdWxlIGRyaXZlciBhZGRzIGNlcnRhaW4gbWVtb3J5IGJsb2Nr cwo+ID4gPiB1c2luZwo+ID4gPiBhZGRfbWVtb3J5X2RyaXZlcl9tYW5hZ2VkKCksIHNvIHRoYXQg aXQgY2FuIHBlcmZvcm0gbWVtb3J5IGhvdHBsdWcKPiA+ID4gb3BlcmF0aW9ucyBvbiB0aGVzZSBi bG9ja3MuIEluIGdlbmVyYWwsIHRoZXNlIG1lbW9yeSBibG9ja3MgYXJlbuKAmXQKPiA+ID4gc29t ZXRoaW5nCj4gPiA+IHRoYXQgZ2V0cyBwaHlzaWNhbGx5IGFkZGVkIGxhdGVyLCBidXQgaXMgcGFy dCBvZiBhY3R1YWwgUkFNIHRoYXQKPiA+ID4gc3lzdGVtCj4gPiA+IGJvb3RlZCB1cCB3aXRoLiBN ZWFuaW5nIOKAkyB3ZSBzZXQgdGhlIOKAmG1lbT3igJkgY21kbGluZSBwYXJhbWV0ZXIgdG8KPiA+ ID4gbGltaXQgdGhlCj4gPiA+IG1lbW9yeSBhbmQgbGF0ZXIgYWRkIHRoZSByZW1haW5pbmcgb25l cyB1c2luZyBhZGRfbWVtb3J5KigpIHZhcmlhbnRzLgo+ID4gPiAKPiA+ID4gVGhlIGJhc2ljIGlk ZWEgaXMgdG8gaGF2ZSBkcml2ZXIgaGF2ZSBvd25lcnNoaXAgYW5kIG1hbmFnZSBjZXJ0YWluCj4g PiA+IG1lbW9yeQo+ID4gPiBibG9ja3MgZm9yIGhvdHBsdWcgb3BlcmF0aW9ucy4KPiA+ID4gCj4g PiA+IEZvciB0aGUgZHJpdmVyIGJlIGFibGUgdG8ga25vdyBob3cgbXVjaCBtZW1vcnkgd2FzIGxp bWl0ZWQgYW5kIGhvdwo+ID4gPiBtdWNoCj4gPiA+IGFjdHVhbGx5IHByZXNlbnQsIHdlIHRha2Ug dGhlIGRlbHRhIG9mIOKAmGJvb3RtZW0gcGh5c2ljYWwgZW5kCj4gPiA+IGFkZHJlc3PigJkgYW5k Cj4gPiA+IOKAmG1lbWJsb2NrX2VuZF9vZl9EUkFN4oCZLiBUaGUgJ2Jvb3RtZW0gcGh5c2ljYWwg ZW5kIGFkZHJlc3MnIGlzCj4gPiA+IG9idGFpbmVkIGJ5Cj4gPiA+IHNjYW5uaW5nIHRoZSByZWcg dmFsdWVzIGluIOKAmG1lbW9yeeKAmSBEVCBub2RlIGFuZCBkZXRlcm1pbmluZyB0aGUgbWF4Cj4g PiA+IHthZGRyLHNpemV9LiBTaW5jZSBvdXIgZHJpdmVyIGlzIGdldHRpbmcgbW9kdWxhcml6ZWQs IHdlIHdvbuKAmXQgaGF2ZQo+ID4gPiBhY2Nlc3MKPiA+ID4gdG8gbWVtYmxvY2tfZW5kX29mX0RS QU0gKGkuZS4gZW5kIGFkZHJlc3Mgb2YgYWxsIG1lbW9yeSBibG9ja3MgYWZ0ZXIKPiA+ID4g4oCY bWVtPeKAmQo+ID4gPiBpcyBhcHBsaWVkKS4KPiA+ID4gCj4gPiA+IFNvIGNoZWNraW5nIGlmIG1l bWJsb2NrX3tzdGFydC9lbmR9X29mX0RSQU0oKSBzeW1ib2xzIGNhbiBiZQo+ID4gPiBleHBvcnRl ZD8gQWxzbywKPiA+ID4gdGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgb2J0YWluZWQgYnkgdXNlcnNw YWNlIGJ5IGRvaW5nIOKAmGNhdAo+ID4gPiAvcHJvYy9pb21lbeKAmSBhbmQKPiA+ID4gZ3JlcGlu ZyBmb3Ig4oCYU3lzdGVtIFJBTeKAmS4gU28gd29uZGVyaW5nIGlmIHVzZXJzcGFjZSBjYW4gaGF2 ZSBhY2Nlc3MKPiA+ID4gdG8gc3VjaAo+ID4gPiBpbmZvLCBjYW4gd2UgYWxsb3cga2VybmVsIG1v ZHVsZSBkcml2ZXJzIGhhdmUgYWNjZXNzIGJ5IGV4cG9ydGluZwo+ID4gPiBtZW1ibG9ja197c3Rh cnQvZW5kfV9vZl9EUkFNKCkuCj4gPiAKPiA+IFRoZXNlIGZ1bmN0aW9ucyBjYW5ub3QgYmUgZXhw b3J0ZWQgbm90IGJlY2F1c2Ugd2Ugd2FudCB0byBoaWRlIHRoaXMKPiA+IGluZm9ybWF0aW9uIGZy b20gdGhlIG1vZHVsZXMgYnV0IGJlY2F1c2UgaXQgaXMgdW5zYWZlIHRvIHVzZSB0aGVtLgo+ID4g T24gbW9zdCBhcmNoaXRlY3R1cnMgdGhlc2UgZnVuY3Rpb25zIGFyZSBfX2luaXQgc28gdGhleSBh cmUgZGlzY2FyZGVkCj4gPiBhZnRlciBib290IGFueXdheS4gQmVpc2RlcywgdGhlIG1lbW9yeSBj b25maWd1cmF0aW9uIGtub3duIHRvIG1lbWJsb2NrCj4gPiBtaWdodCBiZSBub3QgYWNjdXJhdGUg aW4gbWFueSBjYXNlcyBhcyBEYXZpZCBleHBsYWluZWQgaW4gaGlzIHJlcGx5Lgo+ID4gCj4gCj4g SSBkb24ndCBzZWUgaG93IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBtZW1ibG9ja197c3RhcnQv ZW5kfV9vZl9EUkFNKCkgaXMKPiBjb25zaWRlcmVkIGhpZGRlbiBpZiB0aGUgaW5mb3JtYXRpb24g Y2FuIGJlIG9idGFpbmVkIHVzaW5nICdjYXQKPiAvcHJvYy9pb21lbScuIFRoZSBtZW1vcnkgcmVz b3VyY2UgbWFuYWdlciBhZGRzIHRoZXNlIGJsb2NrcyBlaXRoZXIgaW4KPiAiU3lzdGVtIFJBTSIs ICJyZXNlcnZlZCIsICJLZXJuZWwgZGF0YS9jb2RlIiBldGMuIEluc3BlY3RpbmcgdGhpcywgb25l IGNvdWxkCj4gZGV0ZXJtaW5lIHdoYXRzIHRoZSBzdGFydCBhbmQgZW5kIG9mIG1lbWJsb2Nrcy4K CkknbSBub3Qgc2F5aW5nIHRoYXQgdGhlIG1lbWJsb2NrIGRhdGEgaXMgY29uc2lkZXJlZCBoaWRk ZW4uIE9uIG1vc3QKc3lzdGVtcyBpdCBpcyBzaW1wbHkgbm90IHByZXNlbnQgYWZ0ZXIgYm9vdC4g QW5kIGV2ZW4gaWYgaXQgaXMgbm90CmRpc2NhcmRlZCwgaXQgbWlnaHQgYmUgbm90IGFjY3VyYXRl IG9uIGFueSBhcmNoIGV4Y2VwdCBhcm02NC4KCj4gSSBhZ3JlZSBvbiB0aGUgcGFydCB0aGF0IGl0 cyBfX2luaXQgYW5ub3RhdGVkIGFuZCBjb3VsZCBiZSByZW1vdmVkIGFmdGVyCj4gYm9vdC4gVGhp cyBpcyBzb21ldGhpbmcgdGhhdCB0aGUgZHJpdmVyIGNhbiBiZSB2YXJ5IG9mIHRvby4KPiAKPiA+ ID4gT3IgYXJlIHRoZXJlIGFueSBvdGhlciB3YXlzIHdoZXJlIGEgbW9kdWxlIGRyaXZlciBjYW4g Z2V0IHRoZSBlbmQKPiA+ID4gYWRkcmVzcyBvZgo+ID4gPiBzeXN0ZW0gbWVtb3J5IGJsb2NrPwo+ ID4gCj4gPiBXaGF0IGRvIHlvdSBtZWFuIGJ5ICJzeXN0ZW0gbWVtb3J5IGJsb2NrIj8gVGhlcmUg Y291bGQgYmUgYSBsb3Qgb2YKPiA+IGludGVycHJldGF0aW9ucyBpZiB5b3UgdGFrZSBpbnRvIGFj Y291bnQgbWVtb3J5IGhvdHBsdWcsICJtZW09IiBvcHRpb24sCj4gPiByZXNlcnZlZCBhbmQgZmly bXdhcmUgbWVtb3J5Lgo+IAo+IEkgbWVhbnQgdGhlIHBoeXNpY2FsIGVuZCBhZGRyZXNzIG9mIG1l bWJsb2NrLiBUaGUgZXF1aXZhbGVudCBvZgo+IG1lbWJsb2NrX2VuZF9vZl9EUkFNLgoKPiA+IEkn ZCBzdWdnZXN0IHlvdSB0byBkZXNjcmliZSB0aGUgZW50aXJlIHVzZSBjYXNlIGluIG1vcmUgZGV0 YWlsLiBIYXZpbmcKPiA+IHRoZSBjb21wbGV0ZSBwaWN0dXJlIHdvdWxkIGhlbHAgZmluZGluZyBh IHByb3BlciBzb2x1dGlvbi4KPiAKPiBUaGUgdXNlY2FzZSBpbiBnZW5lcmFsIGlzIGhhdmUgYSB3 YXkgdG8gYWRkL3JlbW92ZSBhbmQgb25saW5lL29mZmxpbmUKPiBjZXJ0YWluIG1lbW9yeSBibG9j a3Mgd2hpY2ggYXJlIHBhcnQgb2YgYm9vdC4gV2UgZG8gdGhpcyBieSBsaW1pdGluZyB0aGUKPiBt ZW1vcnkgdXNpbmcgIm1lbT0iIGFuZCBsYXR0ZXIgYWRkIHRoZSByZW1haW5pbmcgYmxvY2tzIHVz aW5nCj4gYWRkX21lbW9yeV9kcml2ZXJfbWFtYW5hZ2VkKCkuCgpJIHRoaW5rIHN1Y2ggaW5mcmFz dHJ1Y3R1cmUgc2hvdWxkIGJlIGEgcGFydCBvZiBjb3JlIG1tIHJhdGhlciB0aGFuCmV4dGVybmFs IG91dC1vZi10cmVlIGRyaXZlci4KCj4gU3VkYXJzaGFuCj4gCi0tIApTaW5jZXJlbHkgeW91cnMs Ck1pa2UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwps aW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJh ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51 eC1hcm0ta2VybmVsCg== 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 EF1D2C2D0A3 for ; Tue, 3 Nov 2020 16:51:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94A0720756 for ; Tue, 3 Nov 2020 16:51:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604422304; bh=ltFWbwZrKzlRod8Ro/4wG6vMt94SJxaRjMtj1TLMLYc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Qck0VuTxeblqhOfgCsX/tDlx/ooX1BnAiR+csGs8Q5MJkYJey2a6d6rM1NhmPgA2m NOfubz0lcpHi2tPVRRfmGfaCIQ/AjTQ581rAOutRlGFLwyeFshlfsdoyCIBDA4jFvX yNLvAMli8E9anOcsm87P6YshUBdeTlXBFS7LmHzI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728364AbgKCQvn (ORCPT ); Tue, 3 Nov 2020 11:51:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:57660 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgKCQvn (ORCPT ); Tue, 3 Nov 2020 11:51:43 -0500 Received: from kernel.org (unknown [87.71.17.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A364F20709; Tue, 3 Nov 2020 16:51:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604422302; bh=ltFWbwZrKzlRod8Ro/4wG6vMt94SJxaRjMtj1TLMLYc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HQdZwz6qSkFP7g8HiqaXmRItKdiuPmA3b/89ZigFPfM+QNyFJ7qO4NcRNf830wSRS R+sL56de+WHAQIIJx3bhWqgcQQLsgy2ccFyTuOhz/Pbr9c4FY60sCCbbw7rbb9asSx sKgdTAe6PpIiHcbikl84KlDdGFr90ZoCWhA3rSuo= Date: Tue, 3 Nov 2020 18:51:34 +0200 From: Mike Rapoport To: Sudarshan Rajagopalan Cc: Anshuman Khandual , Mark Rutland , David Hildenbrand , Steven Price , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Suren Baghdasaryan , Greg Kroah-Hartman , Pratik Patel Subject: Re: mm/memblock: export memblock_{start/end}_of_DRAM Message-ID: <20201103165134.GL4879@kernel.org> References: <20201030083842.GA4319@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 02, 2020 at 06:51:25PM -0800, Sudarshan Rajagopalan wrote: > On 2020-10-30 01:38, Mike Rapoport wrote: > > On Thu, Oct 29, 2020 at 02:29:27PM -0700, Sudarshan Rajagopalan wrote: > > > Hello all, > > > > > > We have a usecase where a module driver adds certain memory blocks > > > using > > > add_memory_driver_managed(), so that it can perform memory hotplug > > > operations on these blocks. In general, these memory blocks aren’t > > > something > > > that gets physically added later, but is part of actual RAM that > > > system > > > booted up with. Meaning – we set the ‘mem=’ cmdline parameter to > > > limit the > > > memory and later add the remaining ones using add_memory*() variants. > > > > > > The basic idea is to have driver have ownership and manage certain > > > memory > > > blocks for hotplug operations. > > > > > > For the driver be able to know how much memory was limited and how > > > much > > > actually present, we take the delta of ‘bootmem physical end > > > address’ and > > > ‘memblock_end_of_DRAM’. The 'bootmem physical end address' is > > > obtained by > > > scanning the reg values in ‘memory’ DT node and determining the max > > > {addr,size}. Since our driver is getting modularized, we won’t have > > > access > > > to memblock_end_of_DRAM (i.e. end address of all memory blocks after > > > ‘mem=’ > > > is applied). > > > > > > So checking if memblock_{start/end}_of_DRAM() symbols can be > > > exported? Also, > > > this information can be obtained by userspace by doing ‘cat > > > /proc/iomem’ and > > > greping for ‘System RAM’. So wondering if userspace can have access > > > to such > > > info, can we allow kernel module drivers have access by exporting > > > memblock_{start/end}_of_DRAM(). > > > > These functions cannot be exported not because we want to hide this > > information from the modules but because it is unsafe to use them. > > On most architecturs these functions are __init so they are discarded > > after boot anyway. Beisdes, the memory configuration known to memblock > > might be not accurate in many cases as David explained in his reply. > > > > I don't see how information contained in memblock_{start/end}_of_DRAM() is > considered hidden if the information can be obtained using 'cat > /proc/iomem'. The memory resource manager adds these blocks either in > "System RAM", "reserved", "Kernel data/code" etc. Inspecting this, one could > determine whats the start and end of memblocks. I'm not saying that the memblock data is considered hidden. On most systems it is simply not present after boot. And even if it is not discarded, it might be not accurate on any arch except arm64. > I agree on the part that its __init annotated and could be removed after > boot. This is something that the driver can be vary of too. > > > > Or are there any other ways where a module driver can get the end > > > address of > > > system memory block? > > > > What do you mean by "system memory block"? There could be a lot of > > interpretations if you take into account memory hotplug, "mem=" option, > > reserved and firmware memory. > > I meant the physical end address of memblock. The equivalent of > memblock_end_of_DRAM. > > I'd suggest you to describe the entire use case in more detail. Having > > the complete picture would help finding a proper solution. > > The usecase in general is have a way to add/remove and online/offline > certain memory blocks which are part of boot. We do this by limiting the > memory using "mem=" and latter add the remaining blocks using > add_memory_driver_mamanaged(). I think such infrastructure should be a part of core mm rather than external out-of-tree driver. > Sudarshan > -- Sincerely yours, Mike.