linux-kernel - Re: [PATCH v2 2/3] microblaze: remove redundant early

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: <CAL_Jsq+yEfWZkwWAWKeDuFjxaaZO0uec6eqaq7UNOF-oY30ZuQ@mail.gmail.com>
Date:   Fri, 13 Apr 2018 09:11:32 -0500
From:   Rob Herring <robh@...nel.org>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Michal Simek <monstr@...str.eu>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] microblaze: remove redundant early_printk support

On Tue, Apr 10, 2018 at 8:44 AM, Michal Simek <michal.simek@...inx.com> wrote:
> Hi Rob,
>
> On 28.3.2018 04:06, Rob Herring wrote:
>> With earlycon support now enabled, the arch specific early_printk support
>> can be removed.
>
> earlycon is not the full replacement of early_printk support as is
> designed right now.
> Definitely current early_printk is pretty old and contains code
> duplication but it starts much earlier then earlycon.

Yes, essentially it's after MMU enabling rather than before. But it is
still before any h/w specific setup (dependent on the DT) which is
where one would typically fail to boot. Generally, I've found before
DT unflattening to be early enough. What can go wrong at this early
stage? Memory is flaky or you've passed in bad memory ranges or image
locations. An earlier console may or may not help there and those
problems are easier to debug in the bootloader.

So it is a question of what you want to maintain.

>> Signed-off-by: Rob Herring <robh@...nel.org>
>> Cc: Michal Simek <monstr@...str.eu>
>> ---
>> v2:
>> - Fix booting. The setup_memory call needed to be before the
>>   parse_early_param call.
>
> What's the reason for calling setup_memory before parse_early_param?
> Is there any dependency?

Yes, either fixmap or ioremap (in your case) has to be functional when
earlycon is setup which happens via parse_early_param.

Rob