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@xxxxxxxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
