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:   Thu, 20 Oct 2022 02:16:29 +0000
From:   Sherry Sun <sherry.sun@....com>
To:     Shenwei Wang <shenwei.wang@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "jirislaby@...nel.org" <jirislaby@...nel.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


> > -----Original Message-----
> > From: Sherry Sun <sherry.sun@....com>
> > Sent: Wednesday, October 19, 2022 6:07 AM
> > To: gregkh@...uxfoundation.org; jirislaby@...nel.org; lukas@...ner.de;
> > ilpo.jarvinen@...ux.intel.com
> > Cc: linux-serial@...r.kernel.org; linux-kernel@...r.kernel.org;
> > dl-linux-imx <linux-imx@....com>
> > Subject: [PATCH V2] tty: serial: fsl_lpuart: don't break the on-going
> > transfer when global reset
> >
> > lpuart_global_reset() shouldn't break the on-going transmit engin,
> > need 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
> > +		 * and then reset
> > +		 */
> > +		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();
> > +		}
> > +
> >  		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);
> 
> According to the statement in the RM, you don't need to add delay here.
> "There is no minimum delay required before clearing the software reset."
> 
Hi Shenwei,

Assuming you are referencing the imx8ulp lpuart RM, yes, for imx8ulp/imx93 lpuart, no minimum delay is required before clearing the software reset.
But for imx7ulp and imx8qxp lpuart here, the minimum delay is required before clearing the software reset, so here the usleep is needed.

Best Regards
Sherry

Powered by blists - more mailing lists