devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org
Subject: Re: Extending /memreserve/ to allow defining descriptions
Date: Mon, 6 Mar 2017 14:58:56 +1100	[thread overview]
Message-ID: <20170306035856.GF12030@umbus.fritz.box> (raw)
In-Reply-To: <9c1cb5e8-2afd-e266-72b9-20ca6622956e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

On Sat, Mar 04, 2017 at 01:40:39PM -0800, Florian Fainelli wrote:
> Hello,
> 
> I am considering extending the /memreserve node syntax with the ability
> to pass a description string that would be describing what kind of
> memory is being reserved here, e:g:
> 
> /memreserve/ 0x0 0x10000 type = "psci"
> 
> The rationale would be for a client program to be able to list these
> reserved regions e.g: from /proc/iomem in a way that could be made
> available to other applications.
> 
> What do you think?

Suggestions like this have come up before, and I think it's a bad
idea.

First of all, note that it's not merely a matter of extending the dtc
syntax - you'd need to add a way of encoding the extra labels into the
flattened format as well.

Second, the reserve list as a separate piece of the flattened tree
exists for one reason: to allow really early boot code to exclude
memory regions it needs to without having to parse the flat tree.
Labels and other additional information doesn't help that purpose.
BenH (who created the flattened tree format) has opined that having
memory reserves as a separate structure (rather than properties within
the tree) was probably a design error.

Most fundamentally, there isn't always a clear 1:1 correspondance
between each memory region and a single specific purpose.  For
example, firmware could reserve a single region which is uses for
several purposes.

What you could do is to add properties within the device tree further
annotating the reservations, with the extra structure essentially just
acting as an easy-to-parse summary of that.  In fact I know that POWER
systems firmware use 'reserved-ranges' and 'reserved-names' properties
for this.  I don't know if anyone else has adopted that though.

I would certainly be willing to look at patches to have dtc verify the
/memreserve/ statements against such properties, or to autogenerate
the reserved table from the properties, instead of from explicit
/memreserve/ statements.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2017-03-06  3:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-04 21:40 Extending /memreserve/ to allow defining descriptions Florian Fainelli
     [not found] ` <9c1cb5e8-2afd-e266-72b9-20ca6622956e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-03-06  3:58   ` David Gibson [this message]
     [not found]     ` <20170306035856.GF12030-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-03-06 23:28       ` Stewart Smith
     [not found]         ` <87r32a6l43.fsf-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-03-07  0:12           ` Florian Fainelli
     [not found]             ` <fba988e1-40a0-4a7e-e680-45c7360c5aa3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-03-07  1:04               ` Grant Likely
2017-03-07  2:21               ` David Gibson

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=20170306035856.GF12030@umbus.fritz.box \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /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).