[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyhyvazTBBmMSnXk@smile.fi.intel.com>
Date: Mon, 19 Sep 2022 16:46:37 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Lennert Buytenhek <buytenh@...tstofly.org>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
linux-serial <linux-serial@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: I/O page faults from 8250_mid PCIe UART after TIOCVHANGUP
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
Powered by blists - more mailing lists