From: Serge Semin <fancer.lancer@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Hauke Mehrtens" <hauke@hauke-m.de>,
"Rafał Miłecki" <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
Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock
Date: Thu, 8 Oct 2020 18:54:54 +0300 [thread overview]
Message-ID: <20201008155454.kaal2bchjq7wusqr@mobilestation> (raw)
In-Reply-To: <alpine.LFD.2.21.2010081628100.866917@eddie.linux-mips.org>
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)
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?
-Sergey
>
> Maciej
next prev parent reply other threads:[~2020-10-08 15:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 8:43 [PATCH v2] MIPS: replace add_memory_region with memblock Thomas Bogendoerfer
2020-10-08 15:20 ` Serge Semin
2020-10-08 15:30 ` Maciej W. Rozycki
2020-10-08 15:54 ` Serge Semin [this message]
2020-10-08 16:49 ` Florian Fainelli
2020-10-08 21:20 ` Serge Semin
2020-10-08 16:56 ` Maciej W. Rozycki
2020-10-08 22:51 ` Serge Semin
2020-10-09 3:00 ` Jiaxun Yang
2020-10-09 12:09 ` Thomas Bogendoerfer
2020-10-09 12:07 ` Thomas Bogendoerfer
2020-10-09 14:15 ` Serge Semin
2020-10-12 10:01 ` Thomas Bogendoerfer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201008155454.kaal2bchjq7wusqr@mobilestation \
--to=fancer.lancer@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=hauke@hauke-m.de \
--cc=jiaxun.yang@flygoat.com \
--cc=john@phrozen.org \
--cc=keguang.zhang@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=tsbogend@alpha.franken.de \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).