[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230914191328.GA1487598@hu-bjorande-lv.qualcomm.com>
Date: Thu, 14 Sep 2023 12:13:28 -0700
From: Bjorn Andersson <quic_bjorande@...cinc.com>
To: John Ogness <john.ogness@...utronix.de>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
<linux-serial@...r.kernel.org>, Petr Mladek <pmladek@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
<linux-kernel@...r.kernel.org>, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH tty v1 41/74] serial: msm: Use port lock wrappers
On Thu, Sep 14, 2023 at 08:43:58PM +0206, 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>
Reviewed-by: Bjorn Andersson <quic_bjorande@...cinc.com>
Regards,
Bjorn
Powered by blists - more mailing lists