Re: [PATCH v2 2/2] console: don't select first registered console if stdout-path used

[Paul Burton]

Hi Eugeniy,

On Wednesday, 6 September 2017 10:57:18 PDT Eugeniy Paltsev wrote:
> > > We retain previous behavior for tty0 console (if "stdout-path" used)
> > > as a special case:
> > > tty0 will be registered even if it was specified neither
> > > in "bootargs" nor in "stdout-path".
> > > We had to retain this behavior because a lot of ARM boards (and some
> > > powerpc) rely on it.
> >
> > My main concern is the exception for "tty". Yes, it was regiression
> > reported in the commit c6c7d83b9c9e6a8b3e ("Revert "console: don't
> > prefer first registered if DT specifies stdout-path""). But is this
> > the only possible regression?
> >
> > All this is about the fallback code that tries to enable all
> > consoles until a real one with tty binding (newcon->device)
> > is enabled.
> >
> > v1 version of you patch disabled this fallback code when a console
> > was defined by stdout-path in the device tree. This emulates
> > defining the console by console= parameter on the command line.
> >
> > It might make sense until some complains that a console is not
> > longer automatically enabled while it was before. But wait.
> > Someone already complained about "tty0". We can solve this
> > by adding an exception for "tty0". And if anyone else complains
> > about another console, we might need more exceptions.
> >
> > We might endup with so many exceptions that the fallback code
> > will be always used. But then we are back in the square
> > and have the original behavior before your patch.
> 
> Yes, I understand your concerns.
> 
> But I also have another concern: If we decide to left current behavior
> untouched (like after reverting patch 05fd007e4629)
> more and more boards and devices will use current broken stdout-path
> behavior in any form and in the results we will get the situation when we
> can't fix stdout-path behavior at all - because every change will break
> something somewhere. 
> (05fd007e4629 patch do absolutely the same as v1 version of my patch)
> 
> > This is why I would like to know more info about your problem.
> > We need to decide if it is more important than a regression.
> > Or if it can be fixed another way.

After the troubles with commit 05fd007e4629 ("console: don't prefer first 
registered if DT specifies stdout-path") I took an alternate approach: rather 
than preventing the first console being registered, I instead prevent the 
bootconsole from being unregistered until we see the stdout-path console 
probed.

For my systems, where there are 3 consoles involved, this is how it goes:

 - The 8250 earlycon is our boot console.

 - tty0 (from CONFIG_VT) comes along & gets registered fairly early, and
   becomes the "proper" console. With current mainline this causes the boot
   console to be unregistered & lose output over the UART for a while.

 - Eventually ttyS0, the proper 8250 console, gets registered & we re-gain
   UART output. If the system died between the tty0 & ttyS0 registering, it
   dies silently.

With my current approach the difference is that the boot console sticks around 
until the last step where ttyS0 is registered (or until the late_initcall 
stage if ttyS0 never registers). This solves my problem - would it solve 
yours?

I haven't submitted this patch yet, but you can find it here in a v4.13 based 
downstream if you want to give it a try:

  https://git.linux-mips.org/cgit/linux-mti.git/commit/?
h=eng-201705051946&id=dd144b12c899b591c0370715328199bc958878fe

Thanks,
    Paul

Attachment: signature.asc
Description: This is a digitally signed message part.