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] [thread-next>] [day] [month] [year] [list]
Message-ID: <mhng-6db38728-4f82-45bd-9b17-c41da55c41e9@palmerdabbelt-glaptop>
Date:   Wed, 30 Jun 2021 19:52:51 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     robh+dt@...nel.org
CC:     mick@....forth.gr, geert@...ux-m68k.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, frowand.list@...il.com,
        catalin.marinas@....com, will@...nel.org,
        devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:     Re: [PATCH 2/3] riscv: Remove non-standard linux,elfcorehdr handling

On Wed, 16 Jun 2021 07:47:46 PDT (-0700), robh+dt@...nel.org wrote:
> On Wed, Jun 16, 2021 at 4:43 AM Nick Kossifidis <mick@....forth.gr> wrote:
>>
>> Στις 2021-06-16 10:56, Geert Uytterhoeven έγραψε:
>> >
>> > I can't comment on the duplication on arm64, but to me, /chosen
>> > sounds like the natural place for both "linux,elfcorehdr" and
>> > "linux,usable-memory-range".  First rule of DT is "DT describes
>> > hardware, not software policy", with /chosen describing some software
>> > configuration.
>> >
>>
>> We already have "linux,usable-memory" on /memory node:
>> https://elixir.bootlin.com/linux/v5.13-rc6/source/drivers/of/fdt.c#L1011
>> and it makes perfect sense to be there since it overrides /memory's reg
>> property.
>>
>> Why define another binding for the same thing on /chosen ?
>
> Go look at the thread adding "linux,usable-memory-range". There were
> only 35 versions of it[1]. I wasn't happy with a 2nd way either, but
> as I've mentioned before we don't always have /memory node.

I don't really understand what's going on here, but IIUC what I merged 
in 5.13 doesn't match the behavior that other architectures have.  In 
that case I'm happy moving RISC-V over to the more standard way of doing 
things and just calling what we have in 5.13 a screwup.

Sorry for the confusion.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ