Message-ID: <ZlSOc5mtbf4DdI8O@pathway.suse.cz>
Date: Mon, 27 May 2024 15:45:55 +0200
From: Petr Mladek <pmladek@...e.com>
To: Tony Lindgren <tony.lindgren@...ux.intel.com>
Cc: Tony Lindgren <tony@...mide.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>, Jonathan Corbet <corbet@....net>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Ogness <john.ogness@...utronix.de>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	"David S . Miller" <davem@...emloft.net>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Dhruva Gole <d-gole@...com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Johan Hovold <johan@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Vignesh Raghavendra <vigneshr@...com>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org, Sebastian Reichel <sre@...nel.org>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v7 1/7] printk: Save console options for
 add_preferred_console_match()

On Mon 2024-05-27 14:13:19, Tony Lindgren wrote:
> Hi,
> 
> On Fri, May 24, 2024 at 06:06:21PM +0200, Petr Mladek wrote:
> > I have finally found time to looks at this again.
> 
> Great good to hear.
> 
> > First, about breaking the preferred console:
> > 
> > The patchset still causes the regression with /dev/console association
> > as already reported for v3, see
> > https://lore.kernel.org/r/ZWnvc6-LnXdjOQLY@alley
> 
> Thanks and sorry for missing this issue. I thought I had this issue
> already handled, but looking at what I tested with earlier, looks like
> I had the console options the wrong way around.
>  
> > I used the following kernel command line:
> > 
> >    earlycon=uart8250,io,0x3f8,115200 console=ttyS0,115200 console=tty0 ignore_loglevel log_buf_len=1M
> > 
> > The patchset caused that /dev/console became associated with
> > ttyS0 instead of tty0, see the "C" flag:
> > 
> > 	original # cat /proc/consoles
> > 	tty0                 -WU (EC    )    4:1
> > 	ttyS0                -W- (E  p a)    4:64
> > 
> >    vs.
> > 
> > 	patched # cat /proc/consoles
> > 	ttyS0                -W- (EC p a)    4:64
> > 	tty0                 -WU (E     )    4:1
> 
> OK
> 
> > I have added some debugging messages which nicely show the reason.
> > In the original code, __add_preferred_console() is called twice
> > when processing the command line:
> > 
> > [    0.099312] __add_preferred_console[0]: ttyS, 0 (preferrred_console == 0)
> > [    0.099982] __add_preferred_console[1]: tty, 0 (preferrred_console == 1)
> 
> OK thanks for tracking down where things go wrong.
> 
> > The code thinks that "ttyS0" has been mentioned on the command line
> > once again. And preferred_console is _wrongly_ set back to '0'.
> > 
> > My view:
> > 
> > The delayed __add_preferred_console() is a way to hell.
> > 
> > The preferences are defined by the ordering on the command line.
> > All entries have to be added when the command line options are
> > being proceed to keep the order.
> 
> To me it seems we can fix this by keeping track of the console position
> in the kernel command line. I'll send a fix for this to discuss.

Honestly, I would prefer some alternative solution of the whole
problem. From my POV, the current patchset is a kind of a hack.

  1. It hides console=DEVNAME:X.Y options so that register_console()
     does not know about them.

  2. But wait, register_console() might then enable any random console
     by default when there are not console= options. For this the 3rd patch
     added @console_set_on_cmdline variable which would tell
     register_console(): "Hey, I have hidden some user preferences.
     I'll tell you about them when the right time comes."

  3. When port init matches the pattern, it adds the preferred console
     so that the register_console() would know about it.

  4. But wait, the ordering of preferred consoles is important.
     Which would require more hacks to preserve the ordering.

  5. Also serial_base_add_prefcon() adds the preferred console
     with the generic name "ttyS" which is not specific
     for the matched device. It just hopes that the very next
     "register_console()" call will be the one related to
     the matching device. Is this really guaranteed on SMP system?


IMHO, the only solution would be to add a function which would
return "ttySX" for the fiven device name.

Honestly, I do not know the hiearachy of the structures in detail.
But the documentation in the 7th patch says:

+			The mapping of the serial ports to the tty instances
+			can be viewed with:
+
+			$ ls -d /sys/bus/serial-base/devices/*:*.*/tty/*
+			/sys/bus/serial-base/devices/00:04:0.0/tty/ttyS0

BTW: I get on my test system:

# ls -1 -d /sys/bus/serial-base/devices/*:*.*/tty/*
/sys/bus/serial-base/devices/00:00:0.0/tty/ttyS0
/sys/bus/serial-base/devices/serial8250:0.1/tty/ttyS1
/sys/bus/serial-base/devices/serial8250:0.2/tty/ttyS2
/sys/bus/serial-base/devices/serial8250:0.3/tty/ttyS3
..

It looks like it should be possible to provide a function which would
return:

   "ttyS0" for "00:00:0.0"
   "ttyS1" for "serial8250:0.1"
   ...


This function might then be used in "register_console()"
to convert "console=DEVNAME:0.0" option to "ttyS" + "index".

The advantage would be that the relation between "DEVNAME:0.0"
and "ttyS0" will be clear. And the code would see the same hiearachy
as the user in /sys/bus/serial-base/devices/.

Of course, I might be too naive. Maybe, the sysfs hieararchy is
created too late. Maybe, it is not easy to go throught the
hiearachy...

But still. I wonder if there is a straightforard way which would
allow translation between "ttySX" and "DEVNAME:0.0" naming schemes.

Best Regards,
Petr

Powered by blists - more mailing lists