[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2045de5e-b7f8-18fe-dc92-e1d88a62f810@linux.intel.com>
Date: Fri, 15 Sep 2023 12:35:17 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: John Ogness <john.ogness@...utronix.de>
cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
linux-serial <linux-serial@...r.kernel.org>,
Petr Mladek <pmladek@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Tony Lindgren <tony@...mide.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH tty v1 06/74] serial: 8250: Use port lock wrappers
On Thu, 14 Sep 2023, John Ogness wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
>
> When a serial port is used for kernel console output, then all
> modifications to the UART registers which are done from other contexts,
> e.g. getty, termios, are interference points for the kernel console.
>
> So far this has been ignored and the printk output is based on the
> principle of hope. The rework of the console infrastructure which aims to
> support threaded and atomic consoles, requires to mark sections which
> modify the UART registers as unsafe. This allows the atomic write function
> to make informed decisions and eventually to restore operational state. It
> also allows to prevent the regular UART code from modifying UART registers
> while printk output is in progress.
>
> All modifications of UART registers are guarded by the UART port lock,
> which provides an obvious synchronization point with the console
> infrastructure.
>
> To avoid adding this functionality to all UART drivers, wrap the
> spin_[un]lock*() invocations for uart_port::lock into helper functions
> which just contain the spin_[un]lock*() invocations for now. In a
> subsequent step these helpers will gain the console synchronization
> mechanisms.
>
> Converted with coccinelle. No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
> drivers/tty/serial/8250/8250_core.c | 12 ++--
> drivers/tty/serial/8250/8250_port.c | 100 ++++++++++++++--------------
> 2 files changed, 56 insertions(+), 56 deletions(-)
> @@ -3403,9 +3403,9 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
> touch_nmi_watchdog();
>
> if (oops_in_progress)
> - locked = spin_trylock_irqsave(&port->lock, flags);
> + locked = uart_port_trylock_irqsave(port, &flags);
> else
> - spin_lock_irqsave(&port->lock, flags);
> + uart_port_lock_irqsave(port, &flags);
Not related to any problem (with this patch) but I'm a bit curious is this
construct going to remain there after the follow-up work? And there's the
similar one in some other drivers (with some variations related to
local_irq_save()):
if (port->sysrq) {
locked = 0;
} else if (oops_in_progress) {
locked = spin_trylock(&port->lock);
} else {
spin_lock(&port->lock);
locked = 1;
}
--
i.
> /*
> * First save the IER then disable the interrupts
> @@ -3475,7 +3475,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
> serial8250_modem_status(up);
>
> if (locked)
> - spin_unlock_irqrestore(&port->lock, flags);
> + uart_port_unlock_irqrestore(port, flags);
> }
>
> static unsigned int probe_baud(struct uart_port *port)
>
Powered by blists - more mailing lists