All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Alex_Gagniuc@Dellteam.com
Cc: helgaas@kernel.org, oohall@gmail.com, gregkh@linuxfoundation.org,
	mr.nuke.me@gmail.com, linux-pci@vger.kernel.org,
	Austin.Bolen@dell.com, Shyam.Iyer@dell.com,
	linux-kernel@vger.kernel.org, jonathan.derrick@intel.com,
	lukas@wunner.de, ruscur@russell.cc, sbobroff@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected
Date: Wed, 14 Nov 2018 13:23:33 -0700	[thread overview]
Message-ID: <20181114202333.GE11416@localhost.localdomain> (raw)
In-Reply-To: <1eb0fa27924f426992715684f5e63346@ausx13mps321.AMER.DELL.COM>

On Wed, Nov 14, 2018 at 07:22:04PM +0000, Alex_Gagniuc@Dellteam.com wrote:
> On 11/14/2018 12:00 AM, Bjorn Helgaas wrote:
> > Just to make sure we're on the same page, can you point me to this
> > rule?  I do see that OSPM must request control of AER using _OSC
> > before it touches the AER registers.  What I don't see is the
> > connection between firmware-first and the AER registers.
> 
> ACPI 6.2 - 6.2.11.3, Table 6-197:
> 
> PCI Express Advanced Error Reporting control:
>   * The firmware sets this bit to 1 to grant control over PCI Express 
> Advanced Error Reporting. If firmware allows the OS control of this 
> feature, then in the context of the _OSC method it must ensure that 
> error messages are routed to device interrupts as described in the PCI 
> Express Base Specification[...]
> 
> Now I'm confused too:
>   * HEST -> __aer_firmware_first
> 	This is used for touching/not touching AER bits
>   * _OSC -> bridge->native_aer
> 	Used to enable/not enable AER portdrv service
> Maybe Keith knows better why we're doing it this way. From ACPI text, it 
> doesn't seem that control of AER would be tied to HEST entries, although 
> in practice, it is.

I'm not sure, that predates me.  HEST does have a FIRMWARE_FIRST flag, but
spec does not say anymore on relation to _OSC control or AER capability.
Nothing in PCIe spec either.

I also don't know why Linux disables the AER driver if only one
device has a FIRMWARE_FIRST HEST. Shouldn't that just be a per-device
decision?

> > The closest I can find is the "Enabled" field in the HEST PCIe
> > AER structures (ACPI v6.2, sec 18.3.2.4, .5, .6), where it says:
> > 
> >    If the field value is 1, indicates this error source is
> >    to be enabled.
> > 
> >    If the field value is 0, indicates that the error source
> >    is not to be enabled.
> > 
> >    If FIRMWARE_FIRST is set in the flags field, the Enabled
> >    field is ignored by the OSPM.
> > 
> > AFAICT, Linux completely ignores the Enabled field in these
> > structures.
> 
> I don't think ignoring the field is a problem:
>   * With FFS, OS should ignore it.
>   * Without FFS, we have control, and we get to make the decisions anyway.
> In the latter case we decide whether to use AER, independent of the crap 
> in ACPI. I'm not even sure why "Enabled" matters in native AER handling. 
> Probably one of the check-boxes in "Binary table designer's handbook"?

And why doesn't Linux do anything with _OSC response other than logging
it? If OS control wasn't granted, shouldn't that take priority over HEST?

WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@intel.com>
To: Alex_Gagniuc@Dellteam.com
Cc: gregkh@linuxfoundation.org, sbobroff@linux.ibm.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Shyam.Iyer@dell.com, lukas@wunner.de, oohall@gmail.com,
	mr.nuke.me@gmail.com, Austin.Bolen@dell.com, helgaas@kernel.org,
	linuxppc-dev@lists.ozlabs.org, jonathan.derrick@intel.com
Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected
Date: Wed, 14 Nov 2018 13:23:33 -0700	[thread overview]
Message-ID: <20181114202333.GE11416@localhost.localdomain> (raw)
In-Reply-To: <1eb0fa27924f426992715684f5e63346@ausx13mps321.AMER.DELL.COM>

On Wed, Nov 14, 2018 at 07:22:04PM +0000, Alex_Gagniuc@Dellteam.com wrote:
> On 11/14/2018 12:00 AM, Bjorn Helgaas wrote:
> > Just to make sure we're on the same page, can you point me to this
> > rule?  I do see that OSPM must request control of AER using _OSC
> > before it touches the AER registers.  What I don't see is the
> > connection between firmware-first and the AER registers.
> 
> ACPI 6.2 - 6.2.11.3, Table 6-197:
> 
> PCI Express Advanced Error Reporting control:
>   * The firmware sets this bit to 1 to grant control over PCI Express 
> Advanced Error Reporting. If firmware allows the OS control of this 
> feature, then in the context of the _OSC method it must ensure that 
> error messages are routed to device interrupts as described in the PCI 
> Express Base Specification[...]
> 
> Now I'm confused too:
>   * HEST -> __aer_firmware_first
> 	This is used for touching/not touching AER bits
>   * _OSC -> bridge->native_aer
> 	Used to enable/not enable AER portdrv service
> Maybe Keith knows better why we're doing it this way. From ACPI text, it 
> doesn't seem that control of AER would be tied to HEST entries, although 
> in practice, it is.

I'm not sure, that predates me.  HEST does have a FIRMWARE_FIRST flag, but
spec does not say anymore on relation to _OSC control or AER capability.
Nothing in PCIe spec either.

I also don't know why Linux disables the AER driver if only one
device has a FIRMWARE_FIRST HEST. Shouldn't that just be a per-device
decision?

> > The closest I can find is the "Enabled" field in the HEST PCIe
> > AER structures (ACPI v6.2, sec 18.3.2.4, .5, .6), where it says:
> > 
> >    If the field value is 1, indicates this error source is
> >    to be enabled.
> > 
> >    If the field value is 0, indicates that the error source
> >    is not to be enabled.
> > 
> >    If FIRMWARE_FIRST is set in the flags field, the Enabled
> >    field is ignored by the OSPM.
> > 
> > AFAICT, Linux completely ignores the Enabled field in these
> > structures.
> 
> I don't think ignoring the field is a problem:
>   * With FFS, OS should ignore it.
>   * Without FFS, we have control, and we get to make the decisions anyway.
> In the latter case we decide whether to use AER, independent of the crap 
> in ACPI. I'm not even sure why "Enabled" matters in native AER handling. 
> Probably one of the check-boxes in "Binary table designer's handbook"?

And why doesn't Linux do anything with _OSC response other than logging
it? If OS control wasn't granted, shouldn't that take priority over HEST?

  parent reply	other threads:[~2018-11-14 20:27 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18 22:15 [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected Alexandru Gagniuc
2018-11-06  0:32 ` Alex G.
2018-11-07 17:04   ` Derrick, Jonathan
2018-11-07 23:42 ` Bjorn Helgaas
2018-11-08 20:09   ` Bjorn Helgaas
2018-11-08 20:09     ` Bjorn Helgaas
2018-11-08 21:49     ` Keith Busch
2018-11-08 21:49       ` Keith Busch
2018-11-08 22:01     ` Greg Kroah-Hartman
2018-11-08 22:01       ` Greg Kroah-Hartman
2018-11-08 22:32       ` Keith Busch
2018-11-08 22:32         ` Keith Busch
2018-11-08 22:42         ` Greg Kroah-Hartman
2018-11-08 22:42           ` Greg Kroah-Hartman
2018-11-08 22:49           ` Alex_Gagniuc
2018-11-08 22:49             ` Alex_Gagniuc
2018-11-08 22:51             ` Greg KH
2018-11-08 22:51               ` Greg KH
2018-11-08 23:06               ` Alex_Gagniuc
2018-11-08 23:06                 ` Alex_Gagniuc
2018-11-12  5:49                 ` Oliver O'Halloran
2018-11-12  5:49                   ` Oliver O'Halloran
2018-11-12 20:05                   ` Alex_Gagniuc
2018-11-12 20:05                     ` Alex_Gagniuc
2018-11-13  5:02                     ` Bjorn Helgaas
2018-11-13  5:02                       ` Bjorn Helgaas
2018-11-13 22:39                       ` Alex_Gagniuc
2018-11-13 22:39                         ` Alex_Gagniuc
2018-11-13 22:52                         ` Keith Busch
2018-11-13 22:52                           ` Keith Busch
2018-11-14  0:31                           ` Alex_Gagniuc
2018-11-14  0:31                             ` Alex_Gagniuc
2018-11-14  5:59                         ` Bjorn Helgaas
2018-11-14  5:59                           ` Bjorn Helgaas
2018-11-14 19:22                           ` Alex_Gagniuc
2018-11-14 19:22                             ` Alex_Gagniuc
2018-11-14 19:41                             ` Derrick, Jonathan
2018-11-14 19:41                               ` Derrick, Jonathan
2018-11-14 20:23                             ` Keith Busch [this message]
2018-11-14 20:23                               ` Keith Busch
2018-11-14 20:52                               ` Alex_Gagniuc
2018-11-14 20:52                                 ` Alex_Gagniuc
2018-11-14 20:58                                 ` Keith Busch
2018-11-14 20:58                                   ` Keith Busch
2018-11-15  6:24                             ` Bjorn Helgaas
2018-11-15  6:24                               ` Bjorn Helgaas
2018-11-16  0:19                               ` Alex_Gagniuc
2018-11-16  0:19                                 ` Alex_Gagniuc
2018-11-08 23:03           ` Keith Busch
2018-11-08 23:03             ` Keith Busch
2018-11-09  7:29       ` Lukas Wunner
2018-11-09 11:32         ` Greg Kroah-Hartman
2018-11-09 11:32           ` Greg Kroah-Hartman
2018-11-09 16:36           ` Keith Busch
2018-11-09 16:36             ` Keith Busch
2018-11-08 22:20     ` Alex_Gagniuc
2018-11-08 22:20       ` Alex_Gagniuc
2018-11-09  7:11     ` Lukas Wunner
2018-11-12  5:48       ` Oliver O'Halloran
2018-11-12  5:48         ` Oliver O'Halloran
2018-12-27 19:28     ` Alex_Gagniuc
2018-12-27 19:28       ` Alex_Gagniuc

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=20181114202333.GE11416@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=Alex_Gagniuc@Dellteam.com \
    --cc=Austin.Bolen@dell.com \
    --cc=Shyam.Iyer@dell.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=mr.nuke.me@gmail.com \
    --cc=oohall@gmail.com \
    --cc=ruscur@russell.cc \
    --cc=sbobroff@linux.ibm.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.