linux-kernel - Re: [PATCH v4] of/fdt: Rework early_init_dt_scan

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87bko2x3mh.fsf@rammhold.de>
Date:   Sat, 17 Dec 2022 01:42:14 +0100
From:   Andreas Rammhold <andreas@...mhold.de>
To:     Rob Herring <robh@...nel.org>
Cc:     devicetree@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-mips@...r.kernel.org, Frank Rowand <frank.rowand@...y.com>,
        linux-kernel@...r.kernel.org, John Crispin <john@...ozen.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Frank Rowand <frowand.list@...il.com>
Subject: Re: [PATCH v4] of/fdt: Rework early_init_dt_scan_memory() to call
 directly

Hi,

I've just debugged an issue that I traced down to this commit.

My mt7621 based board relies on the soc_info.mem_detect function for
memblock init which is never being called again with this patch being
applied.

The code in the original patch as well was on 6.0 doesn't allow any of
the other (fallback?) memory initialization code to run as
early_init_dt_scan_memory() always returns 0.

Was this an oversight in the implementation or are some follow-up
patches missing? Perhaps the code just has to return a different
value when it has found some blocks of memory that should be used?

Andi