Extending /memreserve/ to allow defining descriptions

Extending /memreserve/ to allow defining descriptions

[Florian Fainelli]

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?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending /memreserve/ to allow defining descriptions

[David Gibson]

[-- 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 --]

Re: Extending /memreserve/ to allow defining descriptions

[Stewart Smith]

David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
> 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.

We've also been toying with the idea of creating a binding for "named
reserved memory range that should probably show up in debugfs"

I'd also be happy with a standard binding to do it.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: Extending /memreserve/ to allow defining descriptions

[Florian Fainelli]

On 03/06/2017 03:28 PM, Stewart Smith wrote:
> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
>> 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.
> 
> We've also been toying with the idea of creating a binding for "named
> reserved memory range that should probably show up in debugfs"
> 
> I'd also be happy with a standard binding to do it.

Seems like
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
may be a good place to add descriptive properties about what these
reserved regions are? The code parsing this also seems to be easily
extensible with adding custom "name" properties.

Using "reserved-names" sounds like a good thing, I will be looking into
submitting a binding update in the next few days, but if you beat me to
it, happy to review it.

Tangential: is it me, or it's possible for /memreserve/'s address and
size cells to disagree with #address-cells and #size-cells defined by
the top-level node?
-- 
Florian

Re: Extending /memreserve/ to allow defining descriptions

[Grant Likely]

On Tue, Mar 7, 2017 at 1:12 AM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 03/06/2017 03:28 PM, Stewart Smith wrote:
>> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
>>> 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.
>>
>> We've also been toying with the idea of creating a binding for "named
>> reserved memory range that should probably show up in debugfs"
>>
>> I'd also be happy with a standard binding to do it.
>
> Seems like
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> may be a good place to add descriptive properties about what these
> reserved regions are? The code parsing this also seems to be easily
> extensible with adding custom "name" properties.
>
> Using "reserved-names" sounds like a good thing, I will be looking into
> submitting a binding update in the next few days, but if you beat me to
> it, happy to review it.
>
> Tangential: is it me, or it's possible for /memreserve/'s address and
> size cells to disagree with #address-cells and #size-cells defined by
> the top-level node?

/memreserve/ is a shortcut to tell the kernel during very early boot
to keep its paws of certain ranges of memory. Don't try to extend it
into anything more. The reserved-memory.txt binding is the place to
put tags and/or names on memory regions.

g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending /memreserve/ to allow defining descriptions

[David Gibson]

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

On Mon, Mar 06, 2017 at 04:12:59PM -0800, Florian Fainelli wrote:
> On 03/06/2017 03:28 PM, Stewart Smith wrote:
> > David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
> >> 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.
> > 
> > We've also been toying with the idea of creating a binding for "named
> > reserved memory range that should probably show up in debugfs"
> > 
> > I'd also be happy with a standard binding to do it.
> 
> Seems like
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> may be a good place to add descriptive properties about what these
> reserved regions are? The code parsing this also seems to be easily
> extensible with adding custom "name" properties.
> 
> Using "reserved-names" sounds like a good thing, I will be looking into
> submitting a binding update in the next few days, but if you beat me to
> it, happy to review it.
> 
> Tangential: is it me, or it's possible for /memreserve/'s address and
> size cells to disagree with #address-cells and #size-cells defined by
> the top-level node?

/memreserve/ has no address or size cells; they're simply 64-bit
integers.

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