PCI/CXL: Export native CXL error reporting control

CXL _OSC Error Reporting Control is used by the OS to determine if
Firmware has control of various CXL error reporting capabilities
including the e

PCI/CXL: Export native CXL error reporting control

CXL _OSC Error Reporting Control is used by the OS to determine if
Firmware has control of various CXL error reporting capabilities
including the event logs.

Expose the result of negotiating CXL Error Reporting Control in struct
pci_host_bridge for consumption by the CXL drivers.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: linux-pci@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Link: https://lore.kernel.org/r/20221212070627.1372402-2-ira.weiny@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...

cxl/acpi: Set ACPI's CXL _OSC to indicate RCD mode support

ACPI uses the CXL _OSC support method to communicate the available CXL
functionality to FW. The CXL _OSC support method includes a field to

cxl/acpi: Set ACPI's CXL _OSC to indicate RCD mode support

ACPI uses the CXL _OSC support method to communicate the available CXL
functionality to FW. The CXL _OSC support method includes a field to
indicate the OS is capable of RCD mode. FW can potentially change it's
operation depending on the _OSC support method reported by the OS.

The ACPI driver currently only sets the ACPI _OSC support method to
indicate CXL VH mode. Change the capability reported to also include
CXL RCD mode.

[1] CXL3.0 Table 9-26 'Interpretation of CXL _OSC Support Field'

Signed-off-by: Terry Bowman <terry.bowman@amd.com>
[rrichter@amd.com: Reworded patch description.]
Signed-off-by: Robert Richter <rrichter@amd.com>
Link: http://lore.kernel.org/r/Y4cRV/Sj0epVW7bE@rric.localdomain
Link: https://lore.kernel.org/r/166993046717.1882361.10587956243041624761.stgit@dwillia2-xfh.jf.intel.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...

ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()

Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
to reference count the device returned by acpi_get_pci_dev() as
exp

ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()

Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
to reference count the device returned by acpi_get_pci_dev() as
expected by its callers which in some cases may cause device objects
to be dropped prematurely.

Add the missing get_device() to acpi_get_pci_dev().

Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

ACPI: PCI: Rework acpi_get_pci_dev()

The PCI device returned by acpi_get_pci_dev() needs to be registered,
so if it corresponds to an ACPI device object, the struct acpi_device
representing that obj

ACPI: PCI: Rework acpi_get_pci_dev()

The PCI device returned by acpi_get_pci_dev() needs to be registered,
so if it corresponds to an ACPI device object, the struct acpi_device
representing that object must be registered too and, moreover, it
should be the ACPI companion of the given PCI device. Thus it should
be sufficient to look for it in the ACPI device object's list of
physical nodes associated with it.

Modify the code accordingly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

PCI/ACPI: negotiate CXL _OSC

Add full support for negotiating _OSC as defined in the CXL 2.0 spec, as
applicable to CXL-enabled platforms. Advertise support for the CXL
features we support - 'CXL 2.

PCI/ACPI: negotiate CXL _OSC

Add full support for negotiating _OSC as defined in the CXL 2.0 spec, as
applicable to CXL-enabled platforms. Advertise support for the CXL
features we support - 'CXL 2.0 port/device register access', 'Protocol
Error Reporting', and 'CXL Native Hot Plug'. Request control for 'CXL
Memory Error Reporting'. The requests are dependent on CONFIG_* based
prerequisites, and prior PCI enabling, similar to how the standard PCI
_OSC bits are determined.

The CXL specification does not define any additional constraints on
the hotplug flow beyond PCIe native hotplug, so a kernel that supports
native PCIe hotplug, supports CXL hotplug. For error handling protocol
and link errors just use PCIe AER. There is nascent support for
amending AER events with CXL specific status [1], but there's
otherwise no additional OS responsibility for CXL errors beyond PCIe
AER. CXL Memory Errors behave the same as typical memory errors so
CONFIG_MEMORY_FAILURE is sufficient to indicate support to platform
firmware.

[1]: https://lore.kernel.org/linux-cxl/164740402242.3912056.8303625392871313860.stgit@dwillia2-desk3.amr.corp.intel.com/

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20220413073618.291335-4-vishal.l.verma@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...

PCI/ACPI: Prefer CXL _OSC instead of PCIe _OSC for CXL host bridges

OB In preparation for negotiating OS control of CXL _OSC features, do the
minimal enabling to use CXL _OSC to handle the base PCIe

PCI/ACPI: Prefer CXL _OSC instead of PCIe _OSC for CXL host bridges

OB In preparation for negotiating OS control of CXL _OSC features, do the
minimal enabling to use CXL _OSC to handle the base PCIe feature
negotiation. Recall that CXL _OSC is a super-set of PCIe _OSC and the
CXL 2.0 specification mandates: "If a CXL Host Bridge device exposes CXL
_OSC, CXL aware OSPM shall evaluate CXL _OSC and not evaluate PCIe
_OSC."

Rather than pass a boolean flag alongside @root to all the helper
functions that need to consider PCIe specifics, add is_pcie() and
is_cxl() helper functions to check the flavor of @root. This also
allows for dynamic fallback to PCIe _OSC in cases where an attempt to
use CXL _OXC fails. This can happen on CXL 1.1 platforms that publish
ACPI0016 devices to indicate CXL host bridges, but do not publish the
optional CXL _OSC method. CXL _OSC is mandatory for CXL 2.0 hosts.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20220413073618.291335-3-vishal.l.verma@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...

PCI/ACPI: add a helper for retrieving _OSC Control DWORDs

During _OSC negotiation, when the 'Control' DWORD is needed from the
result buffer after running _OSC, a couple of places performed manual
p

PCI/ACPI: add a helper for retrieving _OSC Control DWORDs

During _OSC negotiation, when the 'Control' DWORD is needed from the
result buffer after running _OSC, a couple of places performed manual
pointer arithmetic to offset into the right spot in the raw buffer.
Add a acpi_osc_ctx_get_pci_control() helper to use the #define'd
DWORD offsets to fetch the DWORDs needed from @acpi_osc_context, and
replace the above instances of the open-coded arithmetic.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Suggested-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed by: Adam Manzanares <a.manzanares@samsung.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20220413073618.291335-2-vishal.l.verma@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

show more ...

PCI: ACPI: PM: Power up devices in D3cold before scanning them

The initial configuration of ACPI power resources on some systems
implies that some PCI devices on them are initially in D3cold.

In so

PCI: ACPI: PM: Power up devices in D3cold before scanning them

The initial configuration of ACPI power resources on some systems
implies that some PCI devices on them are initially in D3cold.

In some cases, especially for PCIe Root Ports, this is a "logical"
D3cold, meaning that the configuration space of the device is
accessible, but some of its functionality may be missing, but it
very well may be real D3cold, in which case the device will not
be accessible at all. However, the PCI bus type driver will need
to access its configuration space in order to enumerate it.

To prevent possible device enumeration failures that may ensue as
a result of ACPI power resources being initially in the "off"
state, power up all children of the host bridge ACPI device object
that hold valid _ADR objects (which indicates that they will be
enumerated by the PCI bus type driver) and do that to all children
of the ACPI device objects corresponding to PCI bridges (including
PCIe ports).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

show more ...

ACPI: APEI: explicit init of HEST and GHES in apci_init()

From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
memory pool") was merged, ghes_init() relies on acpi_hest_init() to m

ACPI: APEI: explicit init of HEST and GHES in apci_init()

From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage
the estatus memory pool. On the other hand, ghes_init() relies on
sdei_init() to detect the SDEI version and (un)register events. The
dependencies are as follows:

ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
ghes_init() => sdei_init()

HEST is not PCI-specific and initcall ordering is implicit and not
well-defined within a level.

Based on above, remove acpi_hest_init() from acpi_pci_root_init() and
convert ghes_init() and sdei_init() from initcalls to explicit calls in the
following order:

acpi_hest_init()
ghes_init()
sdei_init()

Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

PCI/ACPI: Fix acpi_pci_osc_control_set() kernel-doc comment

Add the description of @support and remove @req in
acpi_pci_osc_control_set() kernel-doc comment to remove warnings found
by running scrip

PCI/ACPI: Fix acpi_pci_osc_control_set() kernel-doc comment

Add the description of @support and remove @req in
acpi_pci_osc_control_set() kernel-doc comment to remove warnings found
by running scripts/kernel-doc, which is caused by using 'make W=1'.

drivers/acpi/pci_root.c:337: warning: Excess function parameter 'req'
description in 'acpi_pci_osc_control_set'
drivers/acpi/pci_root.c:337: warning: Function parameter or member
'support' not described in 'acpi_pci_osc_control_set'

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: 6bc779ee05d4 ("PCI/ACPI: Check for _OSC support in acpi_pci_osc_control_set()")
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.

Signed-off-by: Rafael J. Wysock

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

show more ...

PCI/ACPI: Check for _OSC support in acpi_pci_osc_control_set()

Get rid of acpi_pci_osc_support() and check for _OSC supported features
directly in acpi_pci_osc_control_set(). There is no point in do

PCI/ACPI: Check for _OSC support in acpi_pci_osc_control_set()

Get rid of acpi_pci_osc_support() and check for _OSC supported features
directly in acpi_pci_osc_control_set(). There is no point in doing an
unconditional _OSC query with control=0 even when the kernel later wants to
take control over more features.

This saves one _OSC query and simplifies the code by getting rid of the
acpi_pci_osc_support() function. As a side effect, the !control checks in
acpi_pci_query_osc() can also be removed.

Link: https://lore.kernel.org/r/20210824122054.29481-5-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>

show more ...

PCI/ACPI: Move _OSC query checks to separate function

Move the checks about whether the _OSC controls are requested from the
firmware to a separate function.

Link: https://lore.kernel.org/r/2021082

PCI/ACPI: Move _OSC query checks to separate function

Move the checks about whether the _OSC controls are requested from the
firmware to a separate function.

Link: https://lore.kernel.org/r/20210824122054.29481-4-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>

show more ...

PCI/ACPI: Move supported and control calculations to separate functions

Move the calculations of supported and controlled _OSC features out of
negotiate_os_control() into separate functions.

Link:

PCI/ACPI: Move supported and control calculations to separate functions

Move the calculations of supported and controlled _OSC features out of
negotiate_os_control() into separate functions.

Link: https://lore.kernel.org/r/20210824122054.29481-3-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>

show more ...

PCI/ACPI: Remove OSC_PCI_SUPPORT_MASKS and OSC_PCI_CONTROL_MASKS

These masks are only used internally in the PCI Host Bridge _OSC
negotiation code, which already makes sure nothing outside of these

PCI/ACPI: Remove OSC_PCI_SUPPORT_MASKS and OSC_PCI_CONTROL_MASKS

These masks are only used internally in the PCI Host Bridge _OSC
negotiation code, which already makes sure nothing outside of these masks
is set. Remove the masks and simplify the code.

Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20210824122054.29481-2-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>

show more ...

ACPI: APEI: explicit init of HEST and GHES in apci_init()

[ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]

From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
memory

ACPI: APEI: explicit init of HEST and GHES in apci_init()

[ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]

From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus
memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage
the estatus memory pool. On the other hand, ghes_init() relies on
sdei_init() to detect the SDEI version and (un)register events. The
dependencies are as follows:

ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
ghes_init() => sdei_init()

HEST is not PCI-specific and initcall ordering is implicit and not
well-defined within a level.

Based on above, remove acpi_hest_init() from acpi_pci_root_init() and
convert ghes_init() and sdei_init() from initcalls to explicit calls in the
following order:

acpi_hest_init()
ghes_init()
sdei_init()

Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ACPI: pci_root: Unify the message printing

In acpi_pci_root_add(), pr_info() is added with PREFIX, but
in acpi_pci_root_remap_iospace() the pr_info() with no
PREFIX.

Introduce pr_fmt() to unify the

ACPI: pci_root: Unify the message printing

In acpi_pci_root_add(), pr_info() is added with PREFIX, but
in acpi_pci_root_remap_iospace() the pr_info() with no
PREFIX.

Introduce pr_fmt() to unify the message printing and remove
the PREFIX.

Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

PCI/ACPI: Clarify message about _OSC failure

This message:

acpi PNP0A08:02: _OSC failed (AE_NOT_FOUND); disabling ASPM

is alarming and slightly misleading. Per the PCI Firmware Spec, r3.2, sec

PCI/ACPI: Clarify message about _OSC failure

This message:

acpi PNP0A08:02: _OSC failed (AE_NOT_FOUND); disabling ASPM

is alarming and slightly misleading. Per the PCI Firmware Spec, r3.2, sec
4.5.1, _OSC is required for PCIe hierarchies. If _OSC is absent or fails,
the OS must not attempt to use any of the features defined for _OSC. That
includes native hotplug, native PME, AER, and other things as well as ASPM.

Rephrase the message to:

acpi PNP0A08:02: _OSC: platform retains control of PCIe features (AE_NOT_FOUND)

Previous discussion at https://lore.kernel.org/r/20200602223618.GA845676@bjorn-Precision-5520/

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Sinan Kaya <okaya@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Yicong Yang <yangyicong@hisilicon.com>

show more ...

PCI/ACPI: Remove unnecessary osc_lock

9778c14b4ca2 ("ACPI/PCI: Fix possible race condition on _OSC evaluation")
added locking around _OSC calls to protect the acpi_osc_data_list that
stored the resu

PCI/ACPI: Remove unnecessary osc_lock

9778c14b4ca2 ("ACPI/PCI: Fix possible race condition on _OSC evaluation")
added locking around _OSC calls to protect the acpi_osc_data_list that
stored the results.

63f10f0f6df4 ("PCI/ACPI: move _OSC code to pci_root.c") moved the results
from acpi_osc_data_list to the struct acpi_pci_root, where it no longer
needs locking, but did not remove the lock.

Remove the unnecessary locking around _OSC calls.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

PCI/ACPI: Make acpi_pci_osc_control_set() static

acpi_pci_osc_control_set() is only called from pci_root.c, so stop
exporting it and make it static.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.co

PCI/ACPI: Make acpi_pci_osc_control_set() static

acpi_pci_osc_control_set() is only called from pci_root.c, so stop
exporting it and make it static.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

PCI/ACPI: Replace open coded variant of resource_union()

Since we have resource_union() helper, let's utilize it here.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by

PCI/ACPI: Replace open coded variant of resource_union()

Since we have resource_union() helper, let's utilize it here.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Tested-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

ACPI: PCI: Remove unused ACPICA debug code

The ACPICA debug code _COMPONENT and ACPI_MODULE_NAME() are
not used, so can be removed.

Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
[ rjw: Subject e

ACPI: PCI: Remove unused ACPICA debug code

The ACPICA debug code _COMPONENT and ACPI_MODULE_NAME() are
not used, so can be removed.

Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

ACPI: PCI: update kernel-doc line comments

Update kernel-doc line comments to fix warnings reported by make W=1:

drivers/acpi/pci_root.c:71: warning: Function parameter or
member 'handle' not descr

ACPI: PCI: update kernel-doc line comments

Update kernel-doc line comments to fix warnings reported by make W=1:

drivers/acpi/pci_root.c:71: warning: Function parameter or
member 'handle' not described in 'acpi_is_root_bridge'

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

PCI: Rename _DSM constants to align with spec

Rename PCI-related _DSM constants to align them with the PCI Firmware Spec,
r3.2, sec 4.6. No functional change intended.

Link: https://lore.kernel.or

PCI: Rename _DSM constants to align with spec

Rename PCI-related _DSM constants to align them with the PCI Firmware Spec,
r3.2, sec 4.6. No functional change intended.

Link: https://lore.kernel.org/r/20200526213905.2479381-1-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

show more ...

PCI/AER: Use only _OSC to determine AER ownership

Per the PCI Firmware spec, r3.2, sec 4.5.1, the OS can request control of
AER via bit 3 of the _OSC Control Field. In the returned value of the
Con

PCI/AER: Use only _OSC to determine AER ownership

Per the PCI Firmware spec, r3.2, sec 4.5.1, the OS can request control of
AER via bit 3 of the _OSC Control Field. In the returned value of the
Control Field:

The firmware sets [bit 3] to 1 to grant control over PCI Express Advanced
Error Reporting. ... after control is transferred to the operating
system, firmware must not modify the Advanced Error Reporting Capability.
If control of this feature was requested and denied or was not requested,
firmware returns this bit set to 0.

Previously the pci_root driver looked at the HEST FIRMWARE_FIRST bit to
determine whether to request ownership of the AER Capability. This was
based on ACPI spec v6.3, sec 18.3.2.4, and similar sections, which say
things like:

Bit [0] - FIRMWARE_FIRST: If set, indicates that system firmware will
handle errors from this source first.

Bit [1] - GLOBAL: If set, indicates that the settings contained in this
structure apply globally to all PCI Express Devices.

These ACPI references don't say anything about ownership of the AER
Capability.

Remove use of the FIRMWARE_FIRST bit and rely only on the _OSC bit to
determine whether we have control of the AER Capability.

Link: https://lore.kernel.org/r/20181115231605.24352-1-mr.nuke.me@gmail.com/ v1
Link: https://lore.kernel.org/r/20190326172343.28946-1-mr.nuke.me@gmail.com/ v2
Link: https://lore.kernel.org/r/67af2931705bed9a588b5a39d369cb70b9942190.1587925636.git.sathyanarayanan.kuppuswamy@linux.intel.com
[bhelgaas: commit log, note: Alex posted this identical patch 18 months
ago, and I failed to apply it then, so I made him the author, added links
to his postings, and added his Signed-off-by]
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>

show more ...