On Wed, 20 Nov 2013 09:01:44 +1100, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2013-11-19 at 15:14 +0000, Grant Likely wrote: > > > The proposal look good for me. I'm not convinced that we really need the > > > support for 'reg' property, as the fixed memory region is a special case > > > of generic dynamic allocation specified by the size and alloc-ranges, but > > > I assume that there have been already a long discussion about this, so I > > > accept the common consensus. > > > > It is absolutely necessary for some use cases. For example, a > > framebuffer enabled by firmware and passed onto the kernel for > > flicker-free boot. Some platforms have fixed regions that cannot be > > moved up. > > Arguably that could be covered with alloc-range and size by making the range be > the reg property content basically (and thus size == size of range) but I > prefer the reg property, it's a clearer statement of intent. True, but I agree on liking 'reg'. Plus I suspect that the simplest implementation will resolve the size+alloc-ranges property into a generated 'reg' property during early boot so that the existing decode APIs work on any reserved range. :-) g. -- 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
