On Thu, Dec 01, 2022 at 10:54:08AM +0200, Ilpo Järvinen wrote:
> [ Upstream commit 76bad3f88750f8cc465c489e6846249e0bc3d8f5 ]
>
> lpuart_global_reset() shouldn't break the on-going transmit engine, 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.
>
> Also move the lpuart_global_reset() down, then we can reuse the
> lpuart32_tx_empty() without declaration.
>
> Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp")
> Signed-off-by: Sherry Sun <sherry.sun@xxxxxxx>
> Link: https://lore.kernel.org/r/20221024085844.22786-1-sherry.sun@xxxxxxx
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> ---
>
> Hi stable folks,
>
> These two stable-deps seem to be pulled into stable only due to diff
> context:
>
> 07481f448b63 ("serial: fsl_lpuart: Fill in rs485_supported")
> 8925c31c1ac2 ("serial: Add rs485_supported to uart_port")
>
> I think those two should be dropped from the stable queue and the queued
> fix for 76bad3f88750 ("tty: serial: fsl_lpuart: don't break the on-going
> transfer when global reset") replaced with this backport.
As the above are already applied, can you send a fix-up patch to resolve
the problems in the backport that you found?
thanks,
greg k-h
