linux-kernel - Re: console vs earlycon ?

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: <4963882.HSXu6hF7zO@wuerfel>
Date:	Wed, 21 Oct 2015 16:13:08 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stefan Agner <stefan@...er.ch>, linux-serial@...r.kernel.org,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: console vs earlycon ?

On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
> On 10/21/2015 06:36 AM, Arnd Bergmann wrote:
> > On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
> >>>
> >>>> I am trying to implement OF_EARLYCON_DECLARE() for that.
> >>>>
> >>>> I was just wondering if console_initcall() should work as well.
> >>>>
> >>>>
> >>>> As I said, I noticed the console_initcall() in 8250_core.c
> >>>> only works on very limited platforms.
> >>>
> >>> It works with all those that use of_serial.c, right?
> >>
> >> I doubt it.
> >>
> >>
> >> I have a board with a pure 8250-compat device working.
> >> (  compatible = "ns16550a")
> >> It uses of_serial.c, of course.
> >>
> >>
> >> As far as I tested, it would never enable the console at console_init().
> > 
> > Ok, that sounds like a bug. Peter and others have changed that code
> > a lot in the last year. I wonder if this has never worked then or
> > if it has regressed.
> 
> No, not a bug. console_init() is only for legacy platforms, not for
> probed drivers.

Ah, I had no idea we were moving in this direction. So I guess the idea
is not to add another for_each_compatible_node() loop when we already have
two places (earlycon and tty) in the code that do this?

> > * arch/powerpc/kernel/legacy_serial.c does everything we need, but
> >   does not live in architecture independent code and does a few
> >   things that we probably don't need or want there. It relies
> >   on scanning the device tree for known UART device nodes before
> >   the platform devices are added.
> > 
> > * for console_initcall() to do the right thing, we want both the
> >   ttyS devices to get added early for console=ttyS1 to work, as well
> >   as having the preferred console work based on the stdout-property.
> > 
> > * we parse the /chosen/stdout-path property in drivers/of/base and
> >   store the device node pointer in the global 'of_stdout' variable,
> >   but do not use it until the uart is added by the tty driver
> >   and calls of_console_check() to add the default console device.
> 
> I'm assuming the issue with trying to get console_init() working
> is because the dummy color console causes the earlycon to be disabled?

I don't think so.

My line of thinking was more about usability: earlycon requires that
you edit the kernel command line at the moment, while console_init()
doesn't require any user interaction and just uses the stdout-path.

I guess we could enable earlycon using a Kconfig symbol if we want
to, or make it a per-architecture decision whether it's enabled even
in the absence of the command line flag.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/