From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
linux-serial <linux-serial@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: I/O page faults from 8250_mid PCIe UART after TIOCVHANGUP
Date: Mon, 19 Sep 2022 16:46:37 +0300 [thread overview]
Message-ID: <YyhyvazTBBmMSnXk@smile.fi.intel.com> (raw)
In-Reply-To: <YyRiPMa26qDptj3L@wantstofly.org>
On Fri, Sep 16, 2022 at 02:47:08PM +0300, Lennert Buytenhek wrote:
> On Thu, Sep 15, 2022 at 07:27:45PM +0300, Ilpo Järvinen wrote:
...
> Thanks for the fix!
>
> > [...] I'm far from sure if it's the
> > best fix though as I don't fully understand what causes the faults during
> > the THRE tests because the port->irq is disabled by the THRE test block.
>
> If the IRQ hasn't been set up yet, the UART will have zeroes in its MSI
> address/data registers. Disabling the IRQ at the interrupt controller
> won't stop the UART from performing a DMA write to the address programmed
> in its MSI address register (zero) when it wants to signal an interrupt.
>
> (These UARTs (in Ice Lake-D) implement PCI 2.1 style MSI without masking
> capability, so there is no way to mask the interrupt at the source PCI
> function level, except disabling the MSI capability entirely, but that
> would cause it to fall back to INTx# assertion, and the PCI specification
> prohibits disabling the MSI capability as a way to mask a function's
> interrupt service request.)
This sounds to me like a good part to be injected into commit message of
the proposed fix.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-09-19 13:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 7:15 I/O page faults from 8250_mid PCIe UART after TIOCVHANGUP Lennert Buytenhek
2022-09-14 10:09 ` Andy Shevchenko
2022-09-14 11:10 ` Lennert Buytenhek
2022-09-14 13:06 ` Andy Shevchenko
2022-09-15 16:27 ` Ilpo Järvinen
2022-09-16 11:47 ` Lennert Buytenhek
2022-09-16 12:02 ` Ilpo Järvinen
2022-09-16 13:18 ` Lennert Buytenhek
2022-09-19 13:46 ` Andy Shevchenko [this message]
2022-09-19 14:19 ` Ilpo Järvinen
2022-09-19 14:22 ` Lennert Buytenhek
2022-09-19 13:46 ` Andy Shevchenko
2022-09-19 14:12 ` 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=YyhyvazTBBmMSnXk@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=buytenh@wantstofly.org \
--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 \
/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.