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