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] [day] [month] [year] [list]
Date:   Thu, 20 Oct 2022 10:43:42 +0000
From:   Sherry Sun <sherry.sun@....com>
To:     Jiri Slaby <jirislaby@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>
CC:     "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH V2] tty: serial: fsl_lpuart: don't break the on-going
 transfer when global reset


> On 19. 10. 22, 13:07, Sherry Sun wrote:
> > lpuart_global_reset() shouldn't break the on-going transmit engin,
> > need
> 
> "engine"

Will fix it in V3.

> 
> > to recover the on-going data transfer after reset.
> >
> > This can help earlycon here, since commit 60f361722ad2 ("serial:
> > fsl_lpuart: Reset prior to registration") moved lpuart_global_reset()
> > before uart_add_one_port(), earlycon is writing during global reset,
> > as global reset will disable the TX and clear the baud rate register,
> > which caused the earlycon cannot work any more after reset, needs to
> > restore the baud rate and re-enable the transmitter to recover the
> > earlycon write.
> >
> > Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for
> > imx7ulp and imx8qxp")
> > Signed-off-by: Sherry Sun <sherry.sun@....com>
> > ---
> > Changes in V2:
> > 1. The while loop may never exit as the stat and sfifo are not re-read
> > inside the loop, fix that.
> > ---
> >   drivers/tty/serial/fsl_lpuart.c | 22 +++++++++++++++++++---
> >   1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/tty/serial/fsl_lpuart.c
> > b/drivers/tty/serial/fsl_lpuart.c index 67fa113f77d4..9a0781395b1f
> > 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -408,11 +408,9 @@ static int lpuart_global_reset(struct lpuart_port
> *sport)
> >   {
> >   	struct uart_port *port = &sport->port;
> >   	void __iomem *global_addr;
> > +	unsigned long tx_enable, bd;
> >   	int ret;
> >
> > -	if (uart_console(port))
> > -		return 0;
> > -
> >   	ret = clk_prepare_enable(sport->ipg_clk);
> >   	if (ret) {
> >   		dev_err(sport->port.dev, "failed to enable uart ipg clk: %d\n",
> > ret); @@ -420,11 +418,29 @@ static int lpuart_global_reset(struct
> lpuart_port *sport)
> >   	}
> >
> >   	if (is_imx7ulp_lpuart(sport) || is_imx8qxp_lpuart(sport)) {
> > +		/*
> > +		 * If the transmitter is used by earlycon, wait transmit engin
> > +complete
> 
> "wait for transmit engine to complete"
> 
> > +		 * and then reset
> 
> "." (add a period)

Will fix it in V3. 

> 
> > +		 */
> > +		tx_enable = lpuart32_read(port, UARTCTRL) & UARTCTRL_TE;
> > +		if (tx_enable) {
> > +			bd = lpuart32_read(&sport->port, UARTBAUD);
> > +			while (!(lpuart32_read(port, UARTSTAT) &
> UARTSTAT_TC &&
> > +				 lpuart32_read(port, UARTFIFO) &
> UARTFIFO_TXEMPT))
> > +				cpu_relax();
> 
> If the HW is stuck, you make the kernel stuck too. What about
> read_poll_timeout_atomic(). Or at least a custom timeout.

Seems use read_poll_timeout_atomic() is a good idea, I will try that.

> 
> > +		}
> > +
> >   		global_addr = port->membase + UART_GLOBAL -
> IMX_REG_OFF;
> >   		writel(UART_GLOBAL_RST, global_addr);
> >   		usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
> >   		writel(0, global_addr);
> >   		usleep_range(GLOBAL_RST_MIN_US, GLOBAL_RST_MAX_US);
> > +
> > +		/* Recover the transmitter for earlycon */
> > +		if (tx_enable) {
> > +			lpuart32_write(port, bd, UARTBAUD);
> > +			lpuart32_write(port, UARTCTRL_TE, UARTCTRL);
> 
> I don't know the HW. Is it enough to write TE here? IOW shouldn't we
> preserve the whole register content from the above read here?

Yes, maybe restore the whole ctrl register here would be better to avoid any confusion, will do that in V3. Thanks.

Best Regards
Sherry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ