[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aPPizEp9w3gcwa0H@ashevche-desk.local>
Date: Sat, 18 Oct 2025 21:56:12 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: Peng Zhang <zhangpeng.00@...edance.com>, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
songmuchun@...edance.com,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
buytenh@...sta.com
Subject: Re: [PATCH] serial: 8250: always disable IRQ during THRE test
On Wed, Oct 15, 2025 at 05:49:34PM +0200, Jiri Slaby wrote:
> On 14. 10. 25, 14:19, Peng Zhang wrote:
> > 在 2025/10/14 19:47, Peng Zhang 写道:
> > > commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
> > > has been set up") moved IRQ setup before the THRE test, so the interrupt
> > > handler can run during the test and race with its IIR reads. This can
> > > produce wrong THRE test results and cause spurious registration of the
> > > serial8250_backup_timeout timer. Unconditionally disable the IRQ for the
> > > short duration of the test and re-enable it afterwards to avoid the race.
...
> > > --- a/drivers/tty/serial/8250/8250_port.c
> > > +++ b/drivers/tty/serial/8250/8250_port.c
> > > @@ -2147,8 +2147,7 @@ static void serial8250_THRE_test(struct
> > > uart_port *port)
> > > if (up->port.flags & UPF_NO_THRE_TEST)
> > > return;
> > > - if (port->irqflags & IRQF_SHARED)
> > > - disable_irq_nosync(port->irq);
> > > + disable_irq_nosync(port->irq);
> > disable_irq_nosync() may need to be changed to disable_irq() to prevent
> > interrupts that are currently being handled.
>
> Make sense to me. Care to Cc the people from 039d4926379b next time, so that
> they can comment?
Thanks for sharing, Jiri!
The above commit message is unclear about the scope (HW wise) of the problem.
Is this only appears on a certain platform or on a wide range of
8250-compatible devices?
If this is only about a single platform, perhaps it needs a simple
UPF_NO_THRE_TEST flag to be set?
Otherwise, I think the above mentioned commit missed to explain the case of
the delayed THRE test. Brief look at the code doesn't reveal a problem to me:
the THRE test and timer backup is for Tx, and if we got already an interrupt
before THRE test it either Rx, so no timer is involved, or Tx on the platforms
that do _not_ need this backup solution. Ilpo, am I right?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists