linux-kernel - Re: [PATCH AUTOSEL 4.4 27/29] serial: pl010: Drop CR register reset on set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jan 2022 17:43:51 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Russell King <rmk+kernel@...linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux@...linux.org.uk, jirislaby@...nel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.4 27/29] serial: pl010: Drop CR register reset
 on set_termios

On Mon, Jan 17, 2022 at 10:08:20PM -0500, Sasha Levin wrote:
> From: Lukas Wunner <lukas@...ner.de>
> 
> [ Upstream commit 08a0c6dff91c965e39905cf200d22db989203ccb ]
> 
> pl010_set_termios() briefly resets the CR register to zero.
> 
> Where does this register write come from?
> 
> The PL010 driver's IRQ handler ambauart_int() originally modified the CR
> register without holding the port spinlock.  ambauart_set_termios() also
> modified that register.  To prevent concurrent read-modify-writes by the
> IRQ handler and to prevent transmission while changing baudrate,
> ambauart_set_termios() had to disable interrupts.  That is achieved by
> writing zero to the CR register.
> 
> However in 2004 the PL010 driver was amended to acquire the port
> spinlock in the IRQ handler, obviating the need to disable interrupts in
> ->set_termios():
> https://git.kernel.org/history/history/c/157c0342e591
> 
> That rendered the CR register write obsolete.  Drop it.

I'd recommend against backporting this particular patch for pl010
as it's merely a cleanup that eases future work on the driver,
but doesn't actually fix anything.

You've also auto-selected a patch for the pl011 driver with the
same subject.  That other patch *does* actually fix an rs485
Transmit Enable glitch, so backporting it makes sense.

Thanks,

Lukas

> Cc: Russell King <rmk+kernel@...linux.org.uk>
> Signed-off-by: Lukas Wunner <lukas@...ner.de>
> Link: https://lore.kernel.org/r/fcaff16e5b1abb4cc3da5a2879ac13f278b99ed0.1641128728.git.lukas@wunner.de
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>  drivers/tty/serial/amba-pl010.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/amba-pl010.c b/drivers/tty/serial/amba-pl010.c
> index 5d41d5b92619a..7f4ba92739663 100644
> --- a/drivers/tty/serial/amba-pl010.c
> +++ b/drivers/tty/serial/amba-pl010.c
> @@ -465,14 +465,11 @@ pl010_set_termios(struct uart_port *port, struct ktermios *termios,
>  	if ((termios->c_cflag & CREAD) == 0)
>  		uap->port.ignore_status_mask |= UART_DUMMY_RSR_RX;
>  
> -	/* first, disable everything */
>  	old_cr = readb(uap->port.membase + UART010_CR) & ~UART010_CR_MSIE;
>  
>  	if (UART_ENABLE_MS(port, termios->c_cflag))
>  		old_cr |= UART010_CR_MSIE;
>  
> -	writel(0, uap->port.membase + UART010_CR);
> -
>  	/* Set baud rate */
>  	quot -= 1;
>  	writel((quot & 0xf00) >> 8, uap->port.membase + UART010_LCRM);
> -- 
> 2.34.1