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;
To:     Serge Semin <fancer.lancer@gmail.com>,
        "Maciej W. Rozycki" <macro@linux-mips.org>
Cc:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Hauke Mehrtens <hauke@hauke-m.de>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        bcm-kernel-feedback-list@broadcom.com,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Keguang Zhang <keguang.zhang@gmail.com>,
        John Crispin <john@phrozen.org>, linux-mips@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
References: <20201008084357.42780-1-tsbogend@alpha.franken.de>
 <20201008152006.4khkbzsxqmmz76rw@mobilestation>
 <alpine.LFD.2.21.2010081628100.866917@eddie.linux-mips.org>
 <20201008155454.kaal2bchjq7wusqr@mobilestation>
From:   Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock
Message-ID: <91e52fa1-ecf9-7acc-62f6-16fccfae927c@gmail.com>
Date:   Thu, 8 Oct 2020 09:49:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Firefox/78.0 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20201008155454.kaal2bchjq7wusqr@mobilestation>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 10/8/2020 8:54 AM, Serge Semin wrote:
> On Thu, Oct 08, 2020 at 04:30:35PM +0100, Maciej W. Rozycki wrote:
>> 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)

AFAICT DTC does not do any validation that regions you declare in 
/memreserve or /reserved-memory are within the 'reg' property defined 
for the /memory node. Not that it could not but that goes a little 
beyond is compiler job.

The kernel ought to be able to do that validation through memblock but 
there could be valid use cases behind declaring a reserved memory region 
that is not backed by a corresponding DRAM region. For instance if you 
hotplugged memory through the sysfs probe interface, and that memory was 
not initially declared in the Device Tree, but there were reserved 
regions within that hot-plugged range that you would have to be aware 
of, then this would break.

> 
> 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?

Would we be breaking any use case if we stopped allowing reserved region 
that are not part of DRAM being declared?
-- 
Florian