[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181113225232.GB10134@localhost.localdomain>
Date: Tue, 13 Nov 2018 15:52:32 -0700
From: Keith Busch <keith.busch@...el.com>
To: Alex_Gagniuc@...lteam.com
Cc: helgaas@...nel.org, oohall@...il.com, gregkh@...uxfoundation.org,
mr.nuke.me@...il.com, linux-pci@...r.kernel.org,
Austin.Bolen@...l.com, Shyam.Iyer@...l.com,
linux-kernel@...r.kernel.org, jonathan.derrick@...el.com,
lukas@...ner.de, ruscur@...sell.cc, sbobroff@...ux.ibm.com,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is
disconnected
On Tue, Nov 13, 2018 at 10:39:15PM +0000, Alex_Gagniuc@...lteam.com wrote:
> On 11/12/2018 11:02 PM, Bjorn Helgaas wrote:
> > The whole issue of firmware-first, the mechanism by which firmware
> > gets control, the System Error enables in Root Port Root Control
> > registers, etc., is very murky to me. Jon has a sort of similar issue
> > with VMD where he needs to leave System Errors enabled instead of
> > disabling them as we currently do.
>
> Well, OS gets control via _OSC method, and based on that it should
> touch/not touch the AER bits. The bits that get set/cleared come from
> _HPX method, and there's a more about the FFS described in ACPI spec. It
> seems that if platform, wants to enable VMD, it should pass the correct
> bits via _HPX. I'm curious to know in what new twisted way FFS doesn't
> work as intended.
When VMD is enabled, the platform sees a VMD endpoint. It doesn't see
any of the root ports on that domain, so ACPI can't provide policies for
them nor AER registers for the platform to consider controlling.
Powered by blists - more mailing lists