Thread (1 message) 1 message, 1 author, 2017-03-07

Re: Extending /memreserve/ to allow defining descriptions

From: David Gibson <hidden>
Date: 2017-03-07 02:21:04

On Mon, Mar 06, 2017 at 04:12:59PM -0800, Florian Fainelli wrote:
On 03/06/2017 03:28 PM, Stewart Smith wrote:
quoted
David Gibson [off-list ref] writes:
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help