Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Sep 2022 17:19:35 +0300 (EEST)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
cc:     Lennert Buytenhek <buytenh@wantstofly.org>,
        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
In-Reply-To: <YyhyvazTBBmMSnXk@smile.fi.intel.com>
Message-ID: <d5bc5b97-25db-d70-17dc-aab49f8fbc77@linux.intel.com>
References: <YyF/dogp/0C87zLb@wantstofly.org> <YyGoZLTFhYQvlf+P@smile.fi.intel.com> <YyG2tDdq9PWTlaBQ@wantstofly.org> <YyHR4o5bOnODZzZ9@smile.fi.intel.com> <7fd034a9-c1e1-2dca-693b-129c9d2649@linux.intel.com> <YyRiPMa26qDptj3L@wantstofly.org>
 <YyhyvazTBBmMSnXk@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1542528522-1663597179=:1603"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1542528522-1663597179=:1603
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT

On Mon, 19 Sep 2022, Andy Shevchenko wrote:

> 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.

I added my own wording already but I could adds of Lennert's far superior 
descriptions verbatim if he is OK with that?


-- 
 i.

--8323329-1542528522-1663597179=:1603--