linux-kernel - Re: [PATCH v6] ARM: uncompress: Parse "linux,usable-memory-range" DT property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACRpkdZzz5_oVSXPwuwpqMDYvzwTkHvmy6ua6yoJqOOSuZb4xg@mail.gmail.com>
Date:   Thu, 23 Sep 2021 02:08:39 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     Russell King <linux@...linux.org.uk>,
        Nicolas Pitre <nico@...xnic.net>,
        Ard Biesheuvel <ardb@...nel.org>,
        Lukasz Stelmach <l.stelmach@...sung.com>,
        Simon Horman <horms@...ge.net.au>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        kexec@...ts.infradead.org
Subject: Re: [PATCH v6] ARM: uncompress: Parse "linux,usable-memory-range" DT property

On Wed, Sep 15, 2021 at 3:20 PM Geert Uytterhoeven
<geert+renesas@...der.be> wrote:

> Add support for parsing the "linux,usable-memory-range" DT property.
> This property is used to describe the usable memory reserved for the
> crash dump kernel, and thus makes the memory reservation explicit.
> If present, Linux no longer needs to mask the program counter, and rely
> on the "mem=" kernel parameter to obtain the start and size of usable
> memory.
>
> For backwards compatibility, the traditional method to derive the start
> of memory is still used if "linux,usable-memory-range" is absent.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>

Very nice patch!
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij