From: Bjorn Helgaas <helgaas@kernel.org>
To: Austin.Bolen@dell.com
Cc: sathyanarayanan.kuppuswamy@linux.intel.com,
Mario.Limonciello@dell.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, ashok.raj@intel.com,
jonathan.derrick@intel.com, mr.nuke.me@gmail.com,
rjw@rjwysocki.net
Subject: Re: [PATCH v1 1/1] PCI/AER: Use _OSC negotiation to determine AER ownership
Date: Wed, 29 Apr 2020 12:10:32 -0500 [thread overview]
Message-ID: <20200429171032.GA30596@google.com> (raw)
In-Reply-To: <a3535fbc69604425b1e8f008348950ab@AUSX13MPC107.AMER.DELL.COM>
On Wed, Apr 29, 2020 at 03:24:41PM +0000, Austin.Bolen@dell.com wrote:
> On 4/28/2020 3:37 PM, Bjorn Helgaas wrote:
> > [EXTERNAL EMAIL]
> >
> > [+to Mario, Austin, Rafael; Dell folks, I suspect this commit will
> > break Dell servers but I'd like your opinion]
> >
> > <snip>
> Thanks Bjorn, for the heads up. I checked with our server BIOS team and
> they say that only checking _OSC for AER should work on our servers. We
> always configure_OSC and the HEST FIRMWARE_FIRST flag to retain firmware
> control of AER so either could be checked.
>
> > I *really* want the patch because the current mix of using both _OSC
> > and FIRMWARE_FIRST to determine AER capability ownership is a mess and
> > getting worse, but I'm more and more doubtful.
> >
> > My contention is that if firmware doesn't want the OS to use the AER
> > capability it should simply decline to grant control via _OSC.
>
> I agree per spec that _OSC should be used and this was confirmed by the
> ACPI working group. Alex had submitted a patch for us [2] to switch to
> using _OSC to determine AER ownership following the decision in the ACPI
> working group.
Perfect, thank you! I had forgotten that Alex posted that. We should
add credit to him and a link to that discussion. Thanks again!
> [2] https://lkml.org/lkml/2018/11/16/202
>
> > But things like 0584396157ad ("PCI: PCIe AER: honor ACPI HEST FIRMWARE
> > FIRST mode") [1] suggest that some machines grant AER control to the
> > OS via _OSC, but still expect the OS to leave AER alone for certain
> > devices.
>
> AFAIK, no Dell server, including the 11G servers mentioned in that
> patch, have granted control of AER via _OSC and set HEST FIRMWARE_FIRST
> for some devices. I don't think this model is even support by the
> ACPI/PCIe standards. Yes, you can set the bits that way, but there is
> no text I've found that says how the OS/firmware should behave in that
> scenario. In order to be interoperable, I think someone would need to
> standardized how the OS/firmware would could co-ordinate in such a model.
I agree and I want to get Linux out of the current muddle where we
try to make sense out of it.
> > I think the FIRMWARE_FIRST language in the ACPI spec is really too
> > vague to tell the OS not to use the AER Capability, but it seems like
> > that's what commits like [1] rely on.
> >
> > The current _OSC definition (PCI Firmware r3.2) applies only to
> > PNP0A03/PNP0A08 devices, but it's conceivable that it could be
> > extended to other devices if we need per-device AER Capability
> > ownership.
> >
> > [1] https://git.kernel.org/linus/0584396157ad
<snip>
next prev parent reply other threads:[~2020-04-29 17:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-26 18:30 [PATCH v1 1/1] PCI/AER: Use _OSC negotiation to determine AER ownership sathyanarayanan.kuppuswamy
2020-04-28 0:02 ` Bjorn Helgaas
2020-04-28 3:20 ` Kuppuswamy, Sathyanarayanan
2020-04-28 11:45 ` Bjorn Helgaas
2020-04-28 14:49 ` Derrick, Jonathan
2020-04-28 20:36 ` Bjorn Helgaas
2020-04-29 15:24 ` Austin.Bolen
2020-04-29 17:10 ` Bjorn Helgaas [this message]
2020-04-30 21:04 ` Bjorn Helgaas
2020-04-30 22:40 ` Bjorn Helgaas
2020-04-30 23:02 ` Bjorn Helgaas
2020-05-01 14:40 ` Austin.Bolen
2020-05-01 15:02 ` Bjorn Helgaas
2020-05-01 0:35 ` Kuppuswamy, Sathyanarayanan
2020-05-01 15:29 ` Bjorn Helgaas
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=20200429171032.GA30596@google.com \
--to=helgaas@kernel.org \
--cc=Austin.Bolen@dell.com \
--cc=Mario.Limonciello@dell.com \
--cc=ashok.raj@intel.com \
--cc=jonathan.derrick@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mr.nuke.me@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=sathyanarayanan.kuppuswamy@linux.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.