[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87plvy31hg.fsf@jogness.linutronix.de>
Date: Wed, 13 Mar 2024 10:55:47 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt
<rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, Ilpo
Järvinen <ilpo.jarvinen@...ux.intel.com>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Tony Lindgren <tony@...mide.com>,
Geert Uytterhoeven <geert+renesas@...der.be>, Justin Chen
<justin.chen@...adcom.com>, Jiaqing Zhao <jiaqing.zhao@...ux.intel.com>,
linux-serial@...r.kernel.org, Peter Collingbourne <pcc@...gle.com>
Subject: Re: [PATCH printk v2 08/26] printk: nbcon: Implement processing in
port->lock wrapper
On 2024-03-11, John Ogness <john.ogness@...utronix.de> wrote:
> And I think you identified a bug relating to the setup() callback.
Actually this bug was recently fixed by Peter Collingbourne:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/kernel/printk/printk.c?h=next-20240313&id=801410b26a0e8b8a16f7915b2b55c9528b69ca87
One nice thing that has risen from this is we are starting to see
exactly what the console lock is needed for. At this point I would say
its main function is synchronizing boot consoles with real
drivers. Which means we will not be able to remove the console lock
until we find a real solution to match boot consoles (which circumvent
the Linux driver model) with the real drivers.
John
Powered by blists - more mailing lists