On Tue, Mar 7, 2017 at 1:12 AM, Florian Fainelli <f.fainelli@xxxxxxxxx> 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/ 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-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
