linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Alper Nebi Yasak <alpernebiyasak@gmail.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: Mon, 25 May 2020 15:04:19 +0200	[thread overview]
Message-ID: <20200525130417.GN3464@linux-b0ei> (raw)
In-Reply-To: <dd19946d-32e9-89e8-3b35-faea9941f107@gmail.com>

On Fri 2020-05-15 22:27:02, Alper Nebi Yasak wrote:
> On 13/05/2020 17:37, Petr Mladek wrote:
> > On Thu 2020-04-30 19:14:34, Alper Nebi Yasak wrote:
> 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)                   |
> +---------------------------------+---------------------------------+


I was first a bit confused by the above table. The order looks fine
but I was not sure about the indentation. I think that some more
details are needed to get the picture and context.

I see the following order in start_kernel():

1. Add spcr consoles: by acpi_parse_spcr() called from setup_arch().
2. Add and register early consoles: by parse_early_param()
3. Add normal consoles from command line: by parse_args()

4. Register tty console: by vty_init() called via long chain
   from fs_initcall(chr_dev_init). It seems to be init call
   in 5th round, see include/linux/init.h

5. Register other (serial) consoles are most likely registered from
   device_initcall() in 6th round, see include/linux/init.h.

The consoles defined by the device tree are not added directly.
Instead, the probe() callbacks checks whether such console is
selected in device tree by of_console_check() called from
uart_add_one_port().


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

I am afraid that this is a problem with many defaults. They might be
good enough for many people but others would want something else.

It might be acceptable to add consoles. But it might be a problem to
remove consoles or change the currently preferred one.

The only exception would be when most people are annoyed with the
current default. But this need to be discussed with people familiar
with the given architecture or device.


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

The generic parameters: console=tty, console=serial, console=dt, console=spcr
looks fine to me. IMHO, the only problem might be when a particular
serial console drive is not able to guess reasonable defaults for the
baud rate, etc.

Best Regards,
Petr

      reply	other threads:[~2020-05-25 13:04 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
2020-05-25 13:04     ` Petr Mladek [this message]

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=20200525130417.GN3464@linux-b0ei \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=alpernebiyasak@gmail.com \
    --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=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).