[PATCH 0/2] Revert support for reserved memory regions defined in device tree

Grant Likely grant.likely at secretlab.ca
Wed Nov 20 08:04:38 EST 2013

On Wed, 20 Nov 2013 09:01:44 +1100, Benjamin Herrenschmidt <benh at kernel.crashing.org> 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.  :-)


More information about the linux-arm-kernel mailing list