[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230914060726.GN5285@atomide.com>
Date: Thu, 14 Sep 2023 09:07:26 +0300
From: Tony Lindgren <tony@...mide.com>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andy Shevchenko <andriy.shevchenko@...el.com>,
Dhruva Gole <d-gole@...com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
John Ogness <john.ogness@...utronix.de>,
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
Subject: Re: [PATCH v2 2/3] serial: core: Add support for DEVNAME:0.0 style
naming for kernel console
* Jiri Slaby <jirislaby@...nel.org> [230914 05:43]:
> On 12. 09. 23, 13:03, Tony Lindgren wrote:
> > +/*
> > + * The "console=" option is handled by console_setup() in printk. We can't use
> > + * early_param() as do_early_param() checks for "console" and "earlycon" options
> > + * so console_setup() potentially handles console also early. Use parse_args().
>
> So why not concentrate console= handling on one place, ie. in
> console_setup()? The below (second time console= handling) occurs quite
> illogical to me.
Well console_setup() knows nothing about the probing serial port controller
device, tries to call __add_preferred_console() based on a few hardcoded
device names and some attempted guessing, and is stuffed into printk.c :)
I don't think we should pile on more stuff into printk.c for this.
If we wanted to do something, let's set up the console list somewhere else,
and then just have console_setup() add every console option to that list
and leave the rest of console_setup in place to avoid breaking things all
over the place.
Then we can export some find_named_console() type function for serial core
to use. Or do you have some better ideas in mind?
Regards,
Tony
Powered by blists - more mailing lists