linux-kernel - Re: [PATCH] serial: sc16is7xx: address RX timeout interrupt errata

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]

Message-Id: <20231115094953.f2a3fee202765c11421b7fb7@hugovil.com>
Date:   Wed, 15 Nov 2023 09:49:53 -0500
From:   Hugo Villeneuve <hugo@...ovil.com>
To:     Daniel Mack <daniel@...que.org>
Cc:     gregkh@...uxfoundation.org, jirislaby@...nel.org,
        lech.perczak@...lingroup.com, u.kleine-koenig@...gutronix.de,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Maxim Popov <maxim.snafu@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH] serial: sc16is7xx: address RX timeout interrupt errata

On Tue, 14 Nov 2023 08:49:04 +0100
Daniel Mack <daniel@...que.org> wrote:

Hi Daniel,

> This devices has a silicon bug that makes it report a timeout interrupt

devices -> device

> but no data in FIFO.
> 
> The datasheet states the following in the errata section 18.1.4:
> 
>   "If the host reads the receive FIFO at the at the same time as a

"at the at the" -> "at the"

Note: I know this error is part of the errata in NXP datasheet.


>   time-out interrupt condition happens, the host might read 0xCC
>   (time-out) in the Interrupt Indication Register (IIR), but bit 0
>   of the Line Status Register (LSR) is not set (means there is not
>   data in the receive FIFO)."
> 
> When this happens, the loop in sc16is7xx_irq() will run forever,
> which effectively blocks the i2c bus and breaks the functionality

i2c -> i2c/spi

Hugo.


> of the UART.
> 
> From the information above, it is assumed that when the bug is
> triggered, the FIFO does in fact have payload in its buffer, but the
> fill level reporting is off-by-one. Hence this patch fixes the issue
> by reading one byte from the FIFO when that condition is detected.
> 
> This clears the interrupt and hence breaks the polling loop.
> 
> Signed-off-by: Daniel Mack <daniel@...que.org>
> Co-Developed-by: Maxim Popov <maxim.snafu@...il.com>
> Cc: stable@...r.kernel.org
> ---
>  drivers/tty/serial/sc16is7xx.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> index 289ca7d4e566..76f76e510ed1 100644
> --- a/drivers/tty/serial/sc16is7xx.c
> +++ b/drivers/tty/serial/sc16is7xx.c
> @@ -765,6 +765,18 @@ static bool sc16is7xx_port_irq(struct sc16is7xx_port *s, int portno)
>  		case SC16IS7XX_IIR_RTOI_SRC:
>  		case SC16IS7XX_IIR_XOFFI_SRC:
>  			rxlen = sc16is7xx_port_read(port, SC16IS7XX_RXLVL_REG);
> +
> +			/*
> +			 * There is a silicon bug that makes the chip report a
> +			 * time-out interrupt but no data in the FIFO. This is
> +			 * described in errata section 18.1.4.
> +			 *
> +			 * When this happens, read one byte from the FIFO to
> +			 * clear the interrupt.
> +			 */
> +			if (iir == SC16IS7XX_IIR_RTOI_SRC && !rxlen)
> +				rxlen = 1;
> +
>  			if (rxlen)
>  				sc16is7xx_handle_rx(port, rxlen, iir);
>  			break;
> -- 
> 2.41.0
>