linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).