[PATCH 1/8] of/fdt: split off FDT self reservation from memreserve processing

[Ard Biesheuvel]

On 1 June 2015 at 13:02, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Jun 01, 2015 at 11:46:27AM +0100, Ard Biesheuvel wrote:
>> On 1 June 2015 at 11:56, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Mon, Jun 01, 2015 at 08:56:07AM +0100, Ard Biesheuvel wrote:
>> >> (snip non-LAKML CCs)
>> >>
>> >> On 22 May 2015 at 12:35, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> > On Mon, May 11, 2015 at 08:41:53AM +0200, Ard Biesheuvel wrote:
>> >> >> This splits off the reservation of the memory occupied by the FDT
>> >> >> binary itself from the processing of the memory reservations it
>> >> >> contains. This is necessary because the physical address of the FDT,
>> >> >> which is needed to perform the reservation, may not be known to the
>> >> >> FDT driver core, i.e., it may be mapped outside the linear direct
>> >> >> mapping, in which case __pa() returns a bogus value.
>> >> >>
>> >> >> Cc: Russell King <linux at arm.linux.org.uk>
>> >> >> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>> >> >> Cc: Paul Mackerras <paulus at samba.org>
>> >> >> Acked-by: Rob Herring <robh at kernel.org>
>> >> >> Acked-by: Mark Rutland <mark.rutland at arm.com>
>> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> >
>> >> > For the arm64 part:
>> >> >
>> >> > Acked-by: Catalin Marinas <catalin.marinas at arm.com>
>> >>
>> >> Thanks Catalin,
>> >>
>> >> Since there has been virtually no discussion about these patches, I
>> >> guess they have missed the window for being considered for inclusion
>> >> in v4.2
>> >>
>> >> May I suggest that you at least consider these patches regarding the ID map
>> >>
>> >> http://article.gmane.org/gmane.linux.ports.arm.kernel/411720
>> >> http://article.gmane.org/gmane.linux.ports.arm.kernel/411721
>> >>
>> >> since they are self-contained and the first one does fix a potential
>> >> problem where the Image placement logic in the stub does not take the
>> >> 512 MB alignment boundary into account. The second one is a trivial
>> >> cleanup.
>> >
>> > FWIW both of these look good to me.
>> >
>> >> Perhaps Mark can comment on the desirability to include the FDT
>> >> remapping patch (which depends on this 1/8).
>> >>
>> >> http://article.gmane.org/gmane.linux.kernel.efi/5738
>> >
>> > I would like to see that taken if possible.
>> >
>>
>> Thanks.
>>
>> Actually, it does make kind of sense to take these four (i.e., this
>> 1/8 plus the three referenced above) patches as a set, since together
>> they address all the known shortcomings in the EFI stub regarding the
>> placement of both the FDT and the kernel image. All the other stuff
>> can easily be deferred.
>
> Putting those together as a cleanup+preparation series makes sense to
> me, if that makes it easy for Catalin to pick them up now.
>
> Do we have/need acks from Ben or Paul on this reservation patch?
>

Considering that this patch is essentially a partial revert of
d1552ce449eb0 ("of/fdt: move memreserve and dtb memory reservations
into core") by Rob, who acked this patch and submitted his patch
without the acks of either Ben or Paul, and the fact that Ben and Paul
(and Russell) have all been cc'ed at least 3 times on this patch, my
take would be that it should be fine to go ahead without them. But it
is ultimately up to Catalin, of course.