linux-kernel - Re: [PATCH] serial: earlycon: Allow earlier DT scan is acpi=off

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: <20200430120933.r33oraqvt7p4lu2v@holly.lan>
Date:   Thu, 30 Apr 2020 13:09:33 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sumit Garg <sumit.garg@...aro.org>,
        linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Patch Tracking <patches@...aro.org>
Subject: Re: [PATCH] serial: earlycon: Allow earlier DT scan is acpi=off

On Wed, Apr 29, 2020 at 05:40:10PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Apr 28, 2020 at 9:22 AM Daniel Thompson
> <daniel.thompson@...aro.org> wrote:
> >
> > Currently if the kernel has support for ACPI SPCR parsing then earlycon
> > without arguments is processed later than the full earlycon=...
> > alternative.
> >
> > If ACPI has been explicitly disabled on the kernel command line then
> > there is not need to defer since the ACPI code (both x86 and arm64)
> > will never actually run.
> >
> > Or, put another way it allows lazy people to throw "acpi=off earlycon"
> > onto the command line of a DT systems and be confident the console will
> > start as early as possible without them having to lookup the driver
> > and address needed for a specific platform.
> >
> > Signed-off-by: Daniel Thompson <daniel.thompson@...aro.org>
> > ---
> >  drivers/tty/serial/earlycon.c | 28 +++++++++++++++++++++++++++-
> >  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> I wonder if a cleaner option is to just add a special "earlycon" value
> like "earlycon=not_acpi".  This wouldn't require any special peeking
> and would just be a sentinel that just says "you should autodetect the
> earlycon, but don't worry about waiting for ACPI".  ...that in itself
> is a bit of a hack, but at least it's more self contained in the
> earlycon driver and maybe more discoverable when someone is figuring
> out how to setup earlycon?

Taking this idea further I wonder if we could even make this earlycon=acpi.
In other words if the loader provided a DT and earlycon has no arguments
when we use the DT to setup the earlycon regardless of any later
decision to adopt ACPI.

I think the only time this would do the wrong thing is if the DT and
ACPI tables are both passed to the kernel and have different early
consoles. This would be a very weird thing for the firmware to do
by, just in case, we could offer earlycon=acpi to accommodate it.

Naturally I do have to code and test it ;-).


Daniel.