public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: yunhui cui <cuiyunhui@bytedance.com>,
	arnd@arndb.de, andriy.shevchenko@linux.intel.com,
	benjamin.larsson@genexis.eu, cuiyunhui@bytedance.com,
	gregkh@linuxfoundation.org, heikki.krogerus@linux.intel.com,
	ilpo.jarvinen@linux.intel.com, jirislaby@kernel.org,
	jkeeping@inmusicbrands.com, linux-kernel@vger.kernel.org,
	linux-serial@vger.kernel.org, markus.mayer@linaro.org,
	matt.porter@linaro.org, namcao@linutronix.de, paulmck@kernel.org,
	pmladek@suse.com, schnelle@linux.ibm.com,
	sunilvl@ventanamicro.com, tim.kryger@linaro.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH v9 2/4] serial: 8250_dw: fix PSLVERR on RX_TIMEOUT
Date: Mon, 23 Jun 2025 10:38:23 +0206	[thread overview]
Message-ID: <84cyauq2nc.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <CAEEQ3w=pUPEVOM4fG6wr06eOD_uO6_ZBzORaG1zhtPswD8HLNQ@mail.gmail.com>

Hi Yunhui,

On 2025-06-23, yunhui cui <cuiyunhui@bytedance.com> wrote:
>> The DW UART may trigger the RX_TIMEOUT interrupt without data
>> present and remain stuck in this state indefinitely. The
>> dw8250_handle_irq() function detects this condition by checking
>> if the UART_LSR_DR bit is not set when RX_TIMEOUT occurs. When
>> detected, it performs a "dummy read" to recover the DW UART from
>> this state.
>>
>> When the PSLVERR_RESP_EN parameter is set to 1, reading the UART_RX
>> while the FIFO is enabled and UART_LSR_DR is not set will generate a
>> PSLVERR error, which may lead to a system panic. There are two methods
>> to prevent PSLVERR: one is to check if UART_LSR_DR is set before reading
>> UART_RX when the FIFO is enabled, and the other is to read UART_RX when
>> the FIFO is disabled.
>>
>> Given these two scenarios, the FIFO must be disabled before the
>> "dummy read" operation and re-enabled afterward to maintain normal
>> UART functionality.
>>
>> Fixes: 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt")
>> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
>> Cc: stable@vger.kernel.org
>> ---
>>  drivers/tty/serial/8250/8250_dw.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
>> index 1902f29444a1c..082b7fcf251db 100644
>> --- a/drivers/tty/serial/8250/8250_dw.c
>> +++ b/drivers/tty/serial/8250/8250_dw.c
>> @@ -297,9 +297,17 @@ static int dw8250_handle_irq(struct uart_port *p)
>>                 uart_port_lock_irqsave(p, &flags);
>>                 status = serial_lsr_in(up);
>>
>> -               if (!(status & (UART_LSR_DR | UART_LSR_BI)))
>> +               if (!(status & (UART_LSR_DR | UART_LSR_BI))) {
>> +                       /* To avoid PSLVERR, disable the FIFO first. */
>> +                       if (up->fcr & UART_FCR_ENABLE_FIFO)
>> +                               serial_out(up, UART_FCR, 0);
>> +
>>                         serial_port_in(p, UART_RX);
>>
>> +                       if (up->fcr & UART_FCR_ENABLE_FIFO)
>> +                               serial_out(up, UART_FCR, up->fcr);
>> +               }
>> +
>>                 uart_port_unlock_irqrestore(p, flags);
>>         }
>>
>> --
>> 2.39.5
>
> Any comments on this patch?

I do not know enough about the hardware. Is a dummy read really the only
way to exit the RX_TIMEOUT state?

What if there are bytes in the TX-FIFO. Are they in danger of being
cleared?

From [0] I see:

"Writing a "0" to bit 0 will disable the FIFOs, in essence turning the
 UART into 8250 compatibility mode. In effect this also renders the rest
 of the settings in this register to become useless. If you write a "0"
 here it will also stop the FIFOs from sending or receiving data, so any
 data that is sent through the serial data port may be scrambled after
 this setting has been changed. It would be recommended to disable FIFOs
 only if you are trying to reset the serial communication protocol and
 clearing any working buffers you may have in your application
 software. Some documentation suggests that setting this bit to "0" also
 clears the FIFO buffers, but I would recommend explicit buffer clearing
 instead using bits 1 and 2."

Have you performed tests where you fill the TX-FIFO and then
disable/enable the FIFO to see if the TX-bytes survive?

John Ogness

[0] https://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming

  reply	other threads:[~2025-06-23  8:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10  9:21 [PATCH v9 0/4] Serial: 8250: Fix PSLVERR related issues Yunhui Cui
2025-06-10  9:21 ` [PATCH v9 1/4] serial: 8250: fix panic due to PSLVERR Yunhui Cui
2025-06-20 11:19   ` John Ogness
2025-07-17 12:19     ` [External] " yunhui cui
2025-07-17 12:32       ` Greg KH
2025-06-10  9:21 ` [PATCH v9 2/4] serial: 8250_dw: fix PSLVERR on RX_TIMEOUT Yunhui Cui
2025-06-23  6:50   ` yunhui cui
2025-06-23  8:32     ` John Ogness [this message]
2025-07-11  2:19       ` [External] " yunhui cui
2025-07-17 14:14         ` John Ogness
2025-07-18 15:20           ` Doug Anderson
2025-06-10  9:21 ` [PATCH v9 3/4] serial: 8250: avoid potential PSLVERR issue Yunhui Cui
2025-06-20 11:20   ` John Ogness
2025-06-10  9:21 ` [PATCH v9 4/4] serial: 8250_dw: assert port->lock is held in dw8250_force_idle() Yunhui Cui
2025-06-20 12:14   ` John Ogness
2025-06-23  6:44     ` [External] " yunhui cui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84cyauq2nc.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=benjamin.larsson@genexis.eu \
    --cc=cuiyunhui@bytedance.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jirislaby@kernel.org \
    --cc=jkeeping@inmusicbrands.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=markus.mayer@linaro.org \
    --cc=matt.porter@linaro.org \
    --cc=namcao@linutronix.de \
    --cc=paulmck@kernel.org \
    --cc=pmladek@suse.com \
    --cc=schnelle@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=sunilvl@ventanamicro.com \
    --cc=tim.kryger@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox