linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-serial@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Biggers <ebiggers@google.com>,
	Feng Tang <feng.tang@intel.com>,
	Grzegorz Halat <ghalat@redhat.com>,
	Lukas Wunner <lukas@wunner.de>, Nicolas Pitre <nico@fluxnic.net>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path
Date: Fri, 15 May 2020 22:27:02 +0300	[thread overview]
Message-ID: <dd19946d-32e9-89e8-3b35-faea9941f107@gmail.com> (raw)
In-Reply-To: <20200513143755.GM17734@linux-b0ei>

On 13/05/2020 17:37, Petr Mladek wrote:
> On Thu 2020-04-30 19:14:34, Alper Nebi Yasak wrote:
>>                      |     "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
> https://lkml.kernel.org/r/20180830123849.26163-1-prarit@redhat.com
> 
> IMHO, arm developers decided that consoles defined by SPCR are always
> enabled when existing.

I'm OK with those being enabled. Though, I hope "not registering tty0"
wasn't an explicit decision, but maybe an oversight/trade-off due to
assuming SPCR code will only run on servers without displays (where tty0
wouldn't matter). (I understand it might be too late to change that.)

So I'd want the 2nd column to be: tty0(EC) ttyAMA0(E) at best, and
ttyAMA0(EC) tty0(E) at worst.

> 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
> description.
> 
> Sadly, it is different logic than with SPCR :-(

I like the fact that this one has tty0. For example, Debian's installer
iterates over /proc/consoles and launches itself on all the consoles it
finds there, so it wouldn't launch on my chromebook's screen if tty0
wasn't included (just like it doesn't launch on a QEMU aarch64 VM's
framebuffer).

>>    ------------------+-----------------------+-----------------------+
>>    Chromebook Plus   | tty0     -WU (EC p  ) | tty0     -WU (EC p  ) |
>>    (w/o either)      |                       |                       |
>>    ------------------+-----------------------+-----------------------+
> 
> This variant is easy and everyone would probably expect this.

I think things run roughly in the following order (from what I can
decipher from kernel messages) and I think it matches your explanations:

|            ACPI SPCR            |      dt chosen stdout-path      |
+=================================+=================================+
| acpi_parse_spcr()               |                                 |
| -> add_preferred_console(uart0) |                                 |
|    (if not on x86)              |                                 |
+---------------------------------+---------------------------------+
|                        console_setup()                            |
|                        -> add_preferred_console(tty0)             |
|                           (if console=tty0)                       |
+---------------------------------+---------------------------------+
|                        register_console(vt)                       |
+---------------------------------+---------------------------------+
|                                 | of_console_check()              |
|                                 | -> add_preferred_console(uart2) |
|                                 |    (if no console arg)          |
+---------------------------------+---------------------------------+
|                        register_console(serial)                   |
+---------------------------------+---------------------------------+

> 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.

OK. Assuming these changes won't go any further, maybe I'll try
documenting the current behavior in relevant places.

> 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.

Maybe I can get QEMU's SPCR use conditional on the existence a
framebuffer, and get distributions to remove stdout-path from certain
device-trees; but that would disable the serial console completely
(instead of having it enabled where tty0 is still preferred).

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

This works; but I'd have to know the machine's serial configuration in
advance to put it in the cmdline as "console=<serial> console=tty0", or
lose the serial console as in the above. (A "console=dt" like that
"console=spcr" patch you linked to would be useful here if it existed.)

Both seem imperfect in that sense, but tolerable.

> 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,
> Petr

Thanks for the detailed reply.

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

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 16:14 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
2020-05-13 22:22   ` Benjamin Herrenschmidt
2020-05-15 19:27   ` Alper Nebi Yasak [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=dd19946d-32e9-89e8-3b35-faea9941f107@gmail.com \
    --to=alpernebiyasak@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=feng.tang@intel.com \
    --cc=ghalat@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=nico@fluxnic.net \
    --cc=nivedita@alum.mit.edu \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sam@ravnborg.org \
    --cc=sergey.senozhatsky@gmail.com \
    --subject='Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).