On Tue, 11 Feb 2014 15:29:54 +0100, Tomasz Figa [off-list ref] wrote:

quoted

Yes, if only because it is an define usage of the reg property. If a
devtree has multiple tuples in reg, then all of those tuples should be
treated as reserved, even if the kernel doesn't know how to use them.

I would not do the same for size/align/alloc-ranges unless there is a
very specific use case that you can define. These ones are different
from the static regions because they aren't ever used to protect
something that already exists in the memory.

Is there a reason why multiple regions could not be used for this 
purpose, instead of adding extra complexity of having multiple reg 
entries per region?

I.e. I don't see a difference between

reg1: region at 00000000 {
	reg = <0x00000000 0x1000>;
};

reg2: region at 10000000 {
	reg = <0x10000000 0x1000>;
};

user {
	regions = <&reg1>, <&reg2>;
};

and

reg: region at 00000000 {
	reg = <0x00000000 0x1000>, <0x10000000 0x1000>;
};

user {
	regions = <&reg>;
};

except that the former IMHO better suits the definition of memory 
region, which I see as a single contiguous range of memory and can be 
simplified to have a single reg entry per region.

My point is rather if multiple reg tuples are found in a reserved memory
node, the kernel must respect them and reserve the memory. I'm not
arguing about whether or not that makes for a good binding.

g.