From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-serial <linux-serial@vger.kernel.org>,
qianfan Zhao <qianfanguijin@163.com>,
Adriana Nicolae <adriana@arista.com>,
LKML <linux-kernel@vger.kernel.org>,
"Bandal, Shankar" <shankar.bandal@intel.com>,
"Murthy, Shanth" <shanth.murthy@intel.com>
Subject: Re: [PATCH 3/6] serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
Date: Tue, 27 Jan 2026 15:48:46 +0200 [thread overview]
Message-ID: <aXjCPu9BglNWec_F@smile.fi.intel.com> (raw)
In-Reply-To: <2aa4aaa4-07b5-2003-eba7-6e1e6fa89611@linux.intel.com>
On Tue, Jan 27, 2026 at 02:48:30PM +0200, Ilpo Järvinen wrote:
> On Sat, 24 Jan 2026, Andy Shevchenko wrote:
> > On Fri, Jan 23, 2026 at 07:27:36PM +0200, Ilpo Järvinen wrote:
...
> > > dw8250_handle_irq() takes port's lock multiple times with no good
> > > reason to release it in between and calls serial8250_handle_irq()
> > > that also takes port's lock.
> > >
> > > As serial8250_handle_irq() takes port's lock itself, create
> > > serial8250_handle_irq_locked() that allows caller to hold port's lock
> > > across the call. Take port's lock only once in dw8250_handle_irq() and
> > > call serial8250_handle_irq_locked() directly.
> >
> > Sounds to me that the latter can be split to a prerequisite patch.
>
> It's not easy to split this DW-side IIR rework and locking changes. What I
> can do is to make 8250_port change separately. I guess I'll do just that
> and only the 8250_dw change in this patch.
Yes, that's what I had in mind.
...
> > > +++ b/drivers/tty/serial/8250/8250_port.c
> >
> > > #include <linux/ioport.h>
> > > #include <linux/init.h>
> > > #include <linux/irq.h>
> >
> > > +#include <linux/lockdep.h>
> >
> > I would still keep more order.
> >
> > > #include <linux/console.h>
> > > #include <linux/gpio/consumer.h>
> >
> > Giving the context we have, the better place for a new inclusion is somewhere
> > here.
>
> Feels to me something that is in the eye of the beholder, but whatever, I
> can move it from one's "correct" place to somebody elses "correct"
> place. :-)
The idea is to have the longest ordered chain even if it's broken by some
unordered pieces. In long-term it helps to cleanup without an additional
churn.
> > > #include <linux/sysrq.h>
> >
> > (Also perhaps sorting headers in a separate patch helps with finding better
> > places for the future inclusions?)
>
> Yes, later (not in this series).
Sure!
...
> > > +EXPORT_SYMBOL_GPL(serial8250_handle_irq_locked);
> >
> > Wondering if we can start exporting with a namespace...
>
> I'll do that. I picked "SERIAL_8250", is that fine or should I use e.g.
> "8250" instead?
Since it's a string now, I have no preferences, but SERIAL_8250 sounds like
slightly better choice as it has not only digits (its own namespace in the
naming) and less chances to collide in the future.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-01-27 13:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 17:27 [PATCH 0/6] 8250 DW UART fixes when under constant Rx pressure Ilpo Järvinen
2026-01-23 17:27 ` [PATCH 1/6] serial: 8250: Protect LCR write in shutdown Ilpo Järvinen
2026-01-23 17:27 ` [PATCH 2/6] serial: 8250_dw: Avoid unnecessary LCR writes Ilpo Järvinen
2026-01-23 21:41 ` Andy Shevchenko
2026-01-23 17:27 ` [PATCH 3/6] serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling Ilpo Järvinen
2026-01-23 22:05 ` Andy Shevchenko
2026-01-27 12:48 ` Ilpo Järvinen
2026-01-27 13:48 ` Andy Shevchenko [this message]
2026-01-23 17:27 ` [PATCH 4/6] serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm Ilpo Järvinen
2026-01-23 22:13 ` Andy Shevchenko
2026-01-27 13:01 ` Ilpo Järvinen
2026-01-27 13:57 ` Andy Shevchenko
2026-01-23 17:27 ` [PATCH 5/6] serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY Ilpo Järvinen
2026-01-23 17:27 ` [PATCH 6/6] serial: 8250_dw: Ensure BUSY is deasserted Ilpo Järvinen
2026-01-23 22:42 ` Andy Shevchenko
2026-01-27 13:35 ` Ilpo Järvinen
2026-01-27 14:10 ` Andy Shevchenko
2026-01-27 14:40 ` Ilpo Järvinen
2026-01-27 16:19 ` John Ogness
2026-01-26 15:22 ` Greg Kroah-Hartman
2026-01-27 14:45 ` Ilpo Järvinen
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=aXjCPu9BglNWec_F@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=adriana@arista.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=qianfanguijin@163.com \
--cc=shankar.bandal@intel.com \
--cc=shanth.murthy@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.