archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <>
To: Alper Nebi Yasak <>
Cc: Greg Kroah-Hartman <>,
	Jiri Slaby <>,
	Sergey Senozhatsky <>,,
	Steven Rostedt <>,,,
	Andrew Morton <>,
	Andy Shevchenko <>,
	Arvind Sankar <>,
	Benjamin Herrenschmidt <>,
	Daniel Vetter <>,
	"David S. Miller" <>,
	Eric Biggers <>,
	Feng Tang <>,
	Grzegorz Halat <>,
	Lukas Wunner <>, Nicolas Pitre <>,
	Sam Ravnborg <>
Subject: Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path
Date: Wed, 13 May 2020 16:37:55 +0200	[thread overview]
Message-ID: <20200513143755.GM17734@linux-b0ei> (raw)
In-Reply-To: <>

On Thu 2020-04-30 19:14:34, Alper Nebi Yasak wrote:
> I recently experienced some trouble with setting up an encrypted-root
> system, my Chromebook Plus (rk3399-gru-kevin, ARM64) would appear to
> hang where it should have asked for an encryption passphrase; and I
> eventually figured out that the kernel preferred the serial port
> (inaccessible to me) over the built-in working display/keyboard and was
> probably asking there.
> Running plymouth in the initramfs solves that specific problem, but
> both the documentation and tty-related kconfig descriptions imply that
> /dev/console should be tty0 if graphics are working, CONFIG_VT_CONSOLE
> is enabled and no explicit console argument is given in the kernel
> commandline.
> However, I'm seeing different behaviour on systems with SPCR (as in QEMU
> aarch64 virtual machines) and/or a device-tree chosen stdout-path node
> (as in most arm/arm64 devices). On these machines, depending on the
> console argument, the contents of the /proc/consoles file are:

I dug many times into the history of the console registration code.
The following table mostly confirms my expectations.

>                     |     "console=tty0"    |    (no console arg)   |
>   ------------------+-----------------------+-----------------------+
>   QEMU VM           | tty0     -WU (EC p  ) | ttyAMA0  -W- (EC   a) |
>   (w/ SPCR)         | ttyAMA0  -W- (E    a) |
>   |

The SPCR handling is inconsistent over architectures, see

IMHO, arm developers decided that consoles defined by SPCR are always
enabled when existing.

In 1st column: tty0 is the preferred console because it is defined
on the commandline.

In 2nd column: tty0 is not enabled at all because another console was
defined by SPCR. Note that ttySX and ttyX consoles are registered only
as a fallback when there is no other console defined.

The following code is responsible for the fallback, see register_console()

	 *	See if we want to use this console driver. If we
	 *	didn't select a console we take the first one
	 *	that registers here.
	if (!has_preferred) {
		if (newcon->index < 0)
			newcon->index = 0;
		if (newcon->setup == NULL ||
		    newcon->setup(newcon, NULL) == 0) {
			newcon->flags |= CON_ENABLED;
			if (newcon->device) {
				newcon->flags |= CON_CONSDEV;
				has_preferred = true;

>   ------------------+-----------------------+-----------------------+
>   Chromebook Plus   | tty0     -WU (EC p  ) | ttyS2    -W- (EC p a) |
>   (w/ stdout-path)  |                       | tty0     -WU (E     ) |

Hmm, of_console_check() explicitly ignores the console defined by
stdout-path when there is a console on the commandline. This explains
1st column.

I am not sure about 2nd column. My guess is that ttyX consoles are
tried first. tty0 is registered as a fallback because there is no
other console at the moment. ttyS2 is tried later and it is
registered because it is in stdout-patch and there is no console
in the command line. It is somehow consistent with  CONFIG_VT_CONSOLE

Sadly, it is different logic than with SPCR :-(

>   ------------------+-----------------------+-----------------------+
>   Chromebook Plus   | tty0     -WU (EC p  ) | tty0     -WU (EC p  ) |
>   (w/o either)      |                       |                       |
>   ------------------+-----------------------+-----------------------+

This variant is easy and everyone would probably expect this.

Regarding the description of CONFIG_VT_CONSOLE option. I am afraid
that it was created and true only before SPCR and device tree support
was introduced.

Now, it is really sad that SPCR and device tree have different
behavior even across architectures. But I am afraid that we could
not change it without breaking many setups.

The only common rules are:

   + The last console on the command line should always be the
     preferred one when defined.

   + Consoles defined by the device (SPCR, device tree) are used
     when there is no commandline.

   + ttyX or ttySX are used as a fallback when nothing else is defined.

My suggestion is:

   + Fix SPCR setting or device tree of your device when the defaults
     are not as expected.

   + Use command line to force your value when the defaults are not
     as expected and you could not change them.

I am afraid that we could not fix your problem on the kernel side. It
would broke other setups that depend on the existing behavior.

Best Regards,

  parent reply	other threads:[~2020-05-13 15:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 16:14 [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Alper Nebi Yasak
2020-04-30 16:14 ` [RFC PATCH v2 1/3] printk: Add function to set console to preferred console's driver Alper Nebi Yasak
2020-04-30 16:46   ` Andy Shevchenko
2020-05-01  1:44   ` Sergey Senozhatsky
2020-05-01 11:48     ` Alper Nebi Yasak
2020-05-13  5:35   ` Sergey Senozhatsky
2020-05-24 10:01     ` Daniel Vetter
2020-04-30 16:14 ` [RFC PATCH v2 2/3] vt: Set as preferred console when a non-dummy backend is bound Alper Nebi Yasak
2020-04-30 16:14 ` [RFC PATCH v2 3/3] printk: Preset tty0 as a pseudo-preferred console Alper Nebi Yasak
2020-04-30 16:44 ` [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Andy Shevchenko
2020-04-30 19:32   ` Alper Nebi Yasak
2020-05-01  1:30 ` Sergey Senozhatsky
2020-05-01 11:08   ` Alper Nebi Yasak
2020-05-01 13:16     ` Andy Shevchenko
2020-05-01 15:07       ` Alper Nebi Yasak
2020-05-13 14:37 ` Petr Mladek [this message]
2020-05-13 22:22   ` Benjamin Herrenschmidt
2020-05-15 19:27   ` Alper Nebi Yasak
2020-05-25 13:04     ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200513143755.GM17734@linux-b0ei \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).