[PATCH] mm: use correct section size macro to describe the FDT virtual address

Ard Biesheuvel ardb at kernel.org
Wed Oct 28 11:22:19 EDT 2020


On Wed, 28 Oct 2020 at 16:20, Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Wed, Oct 28, 2020 at 2:25 PM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> >   149a3ffe62b9dbc3 ("9012/1: move device tree mapping out of linear region")
> >
> > created a permanent, read-only section mapping of the device tree blob
> > provided by the firmware, and added a set of macros to get the base and
> > size of the virtually mapped FDT based on the physical address. However,
> > while the mapping code uses the SECTION_SIZE macro correctly, the macros
> > use PMD_SIZE instead, which means something entirely different on ARM when
> > using short descriptors, and is therefore not the right quantity to use
> > here. So replace PMD_SIZE with SECTION_SIZE. While at it, change the names
> > of the macro and its parameter to clarify that it returns the virtual
> > address of the start of the FDT in memory, based on the physical address
> > in memory.
> >
> > Tested-by: Joel Stanley <joel at jms.id.au>
> > Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
>
> 2 * SECTION_SIZE will be 2 MB on classic MMU and 4MB on
> LPAE right?
>

Yes

> Note in Documentation/arm/memory.rst:
>
> > -ffc00000 ffefffff Fixmap mapping region.  Addresses provided
> > +ffc80000 ffefffff Fixmap mapping region.  Addresses provided
> >      by fix_to_virt() will be located here.
> >
> > +ffc00000 ffc7ffff Guard region
> > +
> > +ff800000 ffbfffff Permanent, fixed read-only mapping of the
> > + firmware provided DT blob
>
> So on the classic MMU the DTB mapping will use 0xff800000-0xff9fffff
> and on LPAE it will use the whole 0xff800000-0xffbfffff as in the doc?
>

Indeed

> Just verifying that I understand this right...
>
> If I have understood what I just reviewed right:
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>
> Yours,
> Linus Walleij



More information about the linux-arm-kernel mailing list