2019-05-27 14:55:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* pci_root.c - ACPI PCI Root Bridge Driver ($Revision: 40 $)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
*/
|
|
|
|
|
2021-06-02 16:54:30 +08:00
|
|
|
#define pr_fmt(fmt) "ACPI: " fmt
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/types.h>
|
2012-09-18 14:21:31 +08:00
|
|
|
#include <linux/mutex.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/pm.h>
|
2010-02-18 06:44:09 +08:00
|
|
|
#include <linux/pm_runtime.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/pci.h>
|
2008-11-11 06:30:45 +08:00
|
|
|
#include <linux/pci-acpi.h>
|
2014-11-09 22:48:03 +08:00
|
|
|
#include <linux/dmar.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/acpi.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
ACPI: Support _OSI("Darwin") correctly
Apple hardware queries _OSI("Darwin") in order to determine whether the
system is running OS X, and changes firmware behaviour based on the
answer. The most obvious difference in behaviour is that Thunderbolt
hardware is forcibly powered down unless the system is running OS X. The
obvious solution would be to simply add Darwin to the list of supported
_OSI strings, but this causes problems.
Recent Apple hardware includes two separate methods for checking _OSI
strings. The first will check whether Darwin is supported, and if so
will exit. The second will check whether Darwin is supported, but will
then continue to check for further operating systems. If a further
operating system is found then later firmware code will assume that the
OS is not OS X. This results in the unfortunate situation where the
Thunderbolt controller is available at boot time but remains powered
down after suspend.
The easiest way to handle this is to special-case it in the
Linux-specific OSI handling code. If we see Darwin, we should answer
true and then disable all other _OSI vendor strings.
The next problem is that the Apple PCI _OSC method has the following
code:
if (LEqual (0x01, OSDW ()))
if (LAnd (LEqual (Arg0, GUID), NEXP)
(do stuff)
else
(fail)
NEXP is a value in high memory and is presumably under the control of
the firmware. No methods sets it. The methods that are called in the "do
stuff" path are dummies. Unless there's some additional firmware call in
early boot, there's no way for this call to succeed - and even if it
does, it doesn't do anything.
The easiest way to handle this is simply to ignore it. We know which
flags would be set, so just set them by hand if the platform is running
in Darwin mode.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
[andreas.noever@gmail.com: merged two patches, do not touch ACPICA]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-20 19:19:47 +08:00
|
|
|
#include <linux/dmi.h>
|
2017-08-01 20:10:41 +08:00
|
|
|
#include <linux/platform_data/x86/apple.h>
|
2013-12-03 08:49:16 +08:00
|
|
|
#include <acpi/apei.h> /* for acpi_hest_init() */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-11-07 08:41:48 +08:00
|
|
|
#include "internal.h"
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define ACPI_PCI_ROOT_CLASS "pci_bridge"
|
|
|
|
#define ACPI_PCI_ROOT_DEVICE_NAME "PCI Root Bridge"
|
2013-01-30 21:27:33 +08:00
|
|
|
static int acpi_pci_root_add(struct acpi_device *device,
|
|
|
|
const struct acpi_device_id *not_used);
|
|
|
|
static void acpi_pci_root_remove(struct acpi_device *device);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-11-23 04:55:20 +08:00
|
|
|
static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
|
|
|
|
{
|
2014-02-04 07:45:13 +08:00
|
|
|
acpiphp_check_host_bridge(adev);
|
2013-11-23 04:55:20 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-09-06 05:07:39 +08:00
|
|
|
#define ACPI_PCIE_REQ_SUPPORT (OSC_PCI_EXT_CONFIG_SUPPORT \
|
|
|
|
| OSC_PCI_ASPM_SUPPORT \
|
|
|
|
| OSC_PCI_CLOCK_PM_SUPPORT \
|
|
|
|
| OSC_PCI_MSI_SUPPORT)
|
2011-01-07 07:55:09 +08:00
|
|
|
|
2010-01-11 00:15:36 +08:00
|
|
|
static const struct acpi_device_id root_device_ids[] = {
|
2007-07-23 20:44:41 +08:00
|
|
|
{"PNP0A03", 0},
|
|
|
|
{"", 0},
|
|
|
|
};
|
|
|
|
|
2013-01-30 21:27:33 +08:00
|
|
|
static struct acpi_scan_handler pci_root_handler = {
|
2007-07-23 20:44:41 +08:00
|
|
|
.ids = root_device_ids,
|
2013-01-30 21:27:33 +08:00
|
|
|
.attach = acpi_pci_root_add,
|
|
|
|
.detach = acpi_pci_root_remove,
|
2013-11-20 21:25:34 +08:00
|
|
|
.hotplug = {
|
2013-11-23 04:55:20 +08:00
|
|
|
.enabled = true,
|
|
|
|
.scan_dependent = acpi_pci_root_scan_dependent,
|
2013-11-20 21:25:34 +08:00
|
|
|
},
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2009-06-11 03:55:14 +08:00
|
|
|
/**
|
|
|
|
* acpi_is_root_bridge - determine whether an ACPI CA node is a PCI root bridge
|
2020-09-22 10:32:25 +08:00
|
|
|
* @handle: the ACPI CA node in question.
|
2009-06-11 03:55:14 +08:00
|
|
|
*
|
|
|
|
* Note: we could make this API take a struct acpi_device * instead, but
|
|
|
|
* for now, it's more convenient to operate on an acpi_handle.
|
|
|
|
*/
|
|
|
|
int acpi_is_root_bridge(acpi_handle handle)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct acpi_device *device;
|
|
|
|
|
|
|
|
ret = acpi_bus_get_device(handle, &device);
|
|
|
|
if (ret)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = acpi_match_device_ids(device, root_device_ids);
|
|
|
|
if (ret)
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_is_root_bridge);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static acpi_status
|
2005-08-05 12:44:28 +08:00
|
|
|
get_root_bridge_busnr_callback(struct acpi_resource *resource, void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-03-12 03:20:06 +08:00
|
|
|
struct resource *res = data;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct acpi_resource_address64 address;
|
2012-06-22 13:48:50 +08:00
|
|
|
acpi_status status;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-06-22 13:48:50 +08:00
|
|
|
status = acpi_resource_to_address64(resource, &address);
|
|
|
|
if (ACPI_FAILURE(status))
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
2015-01-26 16:58:56 +08:00
|
|
|
if ((address.address.address_length > 0) &&
|
2010-03-12 03:20:06 +08:00
|
|
|
(address.resource_type == ACPI_BUS_NUMBER_RANGE)) {
|
2015-01-26 16:58:56 +08:00
|
|
|
res->start = address.address.minimum;
|
|
|
|
res->end = address.address.minimum + address.address.address_length - 1;
|
2010-03-12 03:20:06 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2009-06-19 04:46:52 +08:00
|
|
|
static acpi_status try_get_root_bridge_busnr(acpi_handle handle,
|
2010-03-12 03:20:06 +08:00
|
|
|
struct resource *res)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
2010-03-12 03:20:06 +08:00
|
|
|
res->start = -1;
|
2005-08-05 12:44:28 +08:00
|
|
|
status =
|
|
|
|
acpi_walk_resources(handle, METHOD_NAME__CRS,
|
2010-03-12 03:20:06 +08:00
|
|
|
get_root_bridge_busnr_callback, res);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
2010-03-12 03:20:06 +08:00
|
|
|
if (res->start == -1)
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_ERROR;
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2013-09-06 05:07:45 +08:00
|
|
|
struct pci_osc_bit_struct {
|
|
|
|
u32 bit;
|
|
|
|
char *desc;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct pci_osc_bit_struct pci_osc_support_bit[] = {
|
|
|
|
{ OSC_PCI_EXT_CONFIG_SUPPORT, "ExtendedConfig" },
|
|
|
|
{ OSC_PCI_ASPM_SUPPORT, "ASPM" },
|
|
|
|
{ OSC_PCI_CLOCK_PM_SUPPORT, "ClockPM" },
|
|
|
|
{ OSC_PCI_SEGMENT_GROUPS_SUPPORT, "Segments" },
|
|
|
|
{ OSC_PCI_MSI_SUPPORT, "MSI" },
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
{ OSC_PCI_EDR_SUPPORT, "EDR" },
|
2019-03-16 03:29:40 +08:00
|
|
|
{ OSC_PCI_HPX_TYPE_3_SUPPORT, "HPX-Type3" },
|
2013-09-06 05:07:45 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct pci_osc_bit_struct pci_osc_control_bit[] = {
|
|
|
|
{ OSC_PCI_EXPRESS_NATIVE_HP_CONTROL, "PCIeHotplug" },
|
|
|
|
{ OSC_PCI_SHPC_NATIVE_HP_CONTROL, "SHPCHotplug" },
|
|
|
|
{ OSC_PCI_EXPRESS_PME_CONTROL, "PME" },
|
|
|
|
{ OSC_PCI_EXPRESS_AER_CONTROL, "AER" },
|
|
|
|
{ OSC_PCI_EXPRESS_CAPABILITY_CONTROL, "PCIeCapability" },
|
2018-04-17 23:58:09 +08:00
|
|
|
{ OSC_PCI_EXPRESS_LTR_CONTROL, "LTR" },
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
{ OSC_PCI_EXPRESS_DPC_CONTROL, "DPC" },
|
2013-09-06 05:07:45 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static void decode_osc_bits(struct acpi_pci_root *root, char *msg, u32 word,
|
|
|
|
struct pci_osc_bit_struct *table, int size)
|
|
|
|
{
|
|
|
|
char buf[80];
|
|
|
|
int i, len = 0;
|
|
|
|
struct pci_osc_bit_struct *entry;
|
|
|
|
|
|
|
|
buf[0] = '\0';
|
|
|
|
for (i = 0, entry = table; i < size; i++, entry++)
|
|
|
|
if (word & entry->bit)
|
2020-03-11 15:09:58 +08:00
|
|
|
len += scnprintf(buf + len, sizeof(buf) - len, "%s%s",
|
2013-09-06 05:07:45 +08:00
|
|
|
len ? " " : "", entry->desc);
|
|
|
|
|
|
|
|
dev_info(&root->device->dev, "_OSC: %s [%s]\n", msg, buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void decode_osc_support(struct acpi_pci_root *root, char *msg, u32 word)
|
|
|
|
{
|
|
|
|
decode_osc_bits(root, msg, word, pci_osc_support_bit,
|
|
|
|
ARRAY_SIZE(pci_osc_support_bit));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void decode_osc_control(struct acpi_pci_root *root, char *msg, u32 word)
|
|
|
|
{
|
|
|
|
decode_osc_bits(root, msg, word, pci_osc_control_bit,
|
|
|
|
ARRAY_SIZE(pci_osc_control_bit));
|
|
|
|
}
|
|
|
|
|
2009-10-29 11:04:50 +08:00
|
|
|
static u8 pci_osc_uuid_str[] = "33DB4D5B-1FF7-401C-9657-7441C03DD766";
|
2009-02-09 14:59:29 +08:00
|
|
|
|
|
|
|
static acpi_status acpi_pci_run_osc(acpi_handle handle,
|
|
|
|
const u32 *capbuf, u32 *retval)
|
|
|
|
{
|
2009-10-29 11:04:50 +08:00
|
|
|
struct acpi_osc_context context = {
|
|
|
|
.uuid_str = pci_osc_uuid_str,
|
|
|
|
.rev = 1,
|
|
|
|
.cap.length = 12,
|
|
|
|
.cap.pointer = (void *)capbuf,
|
|
|
|
};
|
2009-02-09 14:59:29 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
2009-10-29 11:04:50 +08:00
|
|
|
status = acpi_run_osc(handle, &context);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
*retval = *((u32 *)(context.ret.pointer + 8));
|
|
|
|
kfree(context.ret.pointer);
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2010-08-21 07:53:27 +08:00
|
|
|
static acpi_status acpi_pci_query_osc(struct acpi_pci_root *root,
|
|
|
|
u32 support,
|
|
|
|
u32 *control)
|
2009-02-09 14:59:29 +08:00
|
|
|
{
|
|
|
|
acpi_status status;
|
2010-08-21 07:53:27 +08:00
|
|
|
u32 result, capbuf[3];
|
|
|
|
|
|
|
|
support &= OSC_PCI_SUPPORT_MASKS;
|
|
|
|
support |= root->osc_support_set;
|
2009-02-09 14:59:29 +08:00
|
|
|
|
2013-09-06 05:05:54 +08:00
|
|
|
capbuf[OSC_QUERY_DWORD] = OSC_QUERY_ENABLE;
|
|
|
|
capbuf[OSC_SUPPORT_DWORD] = support;
|
2010-08-21 07:53:27 +08:00
|
|
|
if (control) {
|
|
|
|
*control &= OSC_PCI_CONTROL_MASKS;
|
2013-09-06 05:05:54 +08:00
|
|
|
capbuf[OSC_CONTROL_DWORD] = *control | root->osc_control_set;
|
2010-08-21 07:53:27 +08:00
|
|
|
} else {
|
PCI / ACPI: Don't query OSC support with all possible controls
Found problem on system that firmware that could handle pci aer.
Firmware get error reporting after pci injecting error, before os boots.
But after os boots, firmware can not get report anymore, even pci=noaer
is passed.
Root cause: BIOS _OSC has problem with query bit checking.
It turns out that BIOS vendor is copying example code from ACPI Spec.
In ACPI Spec 5.0, page 290:
If (Not(And(CDW1,1))) // Query flag clear?
{ // Disable GPEs for features granted native control.
If (And(CTRL,0x01)) // Hot plug control granted?
{
Store(0,HPCE) // clear the hot plug SCI enable bit
Store(1,HPCS) // clear the hot plug SCI status bit
}
...
}
When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffffffe.
So it will get into code path that should be for control set only.
BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))"
Current kernel code is using _OSC query to notify firmware about support
from OS and then use _OSC to set control bits.
During query support, current code is using all possible controls.
So will execute code that should be only for control set stage.
That will have problem when pci=noaer or aer firmware_first is used.
As firmware have that control set for os aer already in query support stage,
but later will not os aer handling.
We should avoid passing all possible controls, just use osc_control_set
instead.
That should workaround BIOS bugs with affected systems on the field
as more bios vendors are copying sample code from ACPI spec.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-28 12:28:58 +08:00
|
|
|
/* Run _OSC query only with existing controls. */
|
2013-09-06 05:05:54 +08:00
|
|
|
capbuf[OSC_CONTROL_DWORD] = root->osc_control_set;
|
2010-08-21 07:53:27 +08:00
|
|
|
}
|
2009-02-09 14:59:29 +08:00
|
|
|
|
|
|
|
status = acpi_pci_run_osc(root->device->handle, capbuf, &result);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
2010-08-21 07:53:27 +08:00
|
|
|
root->osc_support_set = support;
|
ACPI/PCI: Do not preserve _OSC control bits returned by a query
There is the assumption in acpi_pci_osc_control_set() that it is
always sufficient to compare the mask of _OSC control bits to be
requested with the result of an _OSC query where all of the known
control bits have been checked. However, in general, that need not
be the case. For example, if an _OSC feature A depends on an _OSC
feature B and control of A, B plus another _OSC feature C is
requested simultaneously, the BIOS may return A, B, C, while it would
only return C if A and C were requested without B.
That may result in passing a wrong mask of _OSC control bits to an
_OSC control request, in which case the BIOS may only grant control
of a subset of the requested features. Moreover, acpi_pci_run_osc()
will return error code if that happens and the caller of
acpi_pci_osc_control_set() will not know that it's been granted
control of some _OSC features. Consequently, the system will
generally not work as expected.
Apart from this acpi_pci_osc_control_set() always uses the mask
of _OSC control bits returned by the very first invocation of
acpi_pci_query_osc(), but that is done with the second argument
equal to OSC_PCI_SEGMENT_GROUPS_SUPPORT which generally happens
to affect the returned _OSC control bits.
For these reasons, make acpi_pci_osc_control_set() always check if
control of the requested _OSC features will be granted before making
the final control request. As a result, the osc_control_qry and
osc_queried members of struct acpi_pci_root are not necessary any
more, so drop them and remove the remaining code referring to them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 05:55:59 +08:00
|
|
|
if (control)
|
2010-08-21 07:53:27 +08:00
|
|
|
*control = result;
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
static acpi_status acpi_pci_osc_support(struct acpi_pci_root *root, u32 flags)
|
|
|
|
{
|
2020-06-03 06:27:33 +08:00
|
|
|
return acpi_pci_query_osc(root, flags, NULL);
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
|
|
|
|
2009-07-24 07:03:00 +08:00
|
|
|
struct acpi_pci_root *acpi_pci_find_root(acpi_handle handle)
|
2009-02-09 14:59:29 +08:00
|
|
|
{
|
|
|
|
struct acpi_pci_root *root;
|
2012-09-18 14:23:23 +08:00
|
|
|
struct acpi_device *device;
|
2009-06-19 04:47:02 +08:00
|
|
|
|
2012-09-18 14:23:23 +08:00
|
|
|
if (acpi_bus_get_device(handle, &device) ||
|
|
|
|
acpi_match_device_ids(device, root_device_ids))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
root = acpi_driver_data(device);
|
|
|
|
|
|
|
|
return root;
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
2009-07-24 07:03:00 +08:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_pci_find_root);
|
2009-02-09 14:59:29 +08:00
|
|
|
|
2009-06-11 03:55:20 +08:00
|
|
|
struct acpi_handle_node {
|
|
|
|
struct list_head node;
|
|
|
|
acpi_handle handle;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_get_pci_dev - convert ACPI CA handle to struct pci_dev
|
|
|
|
* @handle: the handle in question
|
|
|
|
*
|
|
|
|
* Given an ACPI CA handle, the desired PCI device is located in the
|
|
|
|
* list of PCI devices.
|
|
|
|
*
|
|
|
|
* If the device is found, its reference count is increased and this
|
|
|
|
* function returns a pointer to its data structure. The caller must
|
|
|
|
* decrement the reference count by calling pci_dev_put().
|
|
|
|
* If no device is found, %NULL is returned.
|
|
|
|
*/
|
|
|
|
struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
|
|
|
|
{
|
|
|
|
int dev, fn;
|
|
|
|
unsigned long long adr;
|
|
|
|
acpi_status status;
|
|
|
|
acpi_handle phandle;
|
|
|
|
struct pci_bus *pbus;
|
|
|
|
struct pci_dev *pdev = NULL;
|
|
|
|
struct acpi_handle_node *node, *tmp;
|
|
|
|
struct acpi_pci_root *root;
|
|
|
|
LIST_HEAD(device_list);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Walk up the ACPI CA namespace until we reach a PCI root bridge.
|
|
|
|
*/
|
|
|
|
phandle = handle;
|
|
|
|
while (!acpi_is_root_bridge(phandle)) {
|
|
|
|
node = kzalloc(sizeof(struct acpi_handle_node), GFP_KERNEL);
|
|
|
|
if (!node)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&node->node);
|
|
|
|
node->handle = phandle;
|
|
|
|
list_add(&node->node, &device_list);
|
|
|
|
|
|
|
|
status = acpi_get_parent(phandle, &phandle);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
root = acpi_pci_find_root(phandle);
|
|
|
|
if (!root)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
pbus = root->bus;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now, walk back down the PCI device tree until we return to our
|
|
|
|
* original handle. Assumes that everything between the PCI root
|
|
|
|
* bridge and the device we're looking for must be a P2P bridge.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(node, &device_list, node) {
|
|
|
|
acpi_handle hnd = node->handle;
|
|
|
|
status = acpi_evaluate_integer(hnd, "_ADR", NULL, &adr);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto out;
|
|
|
|
dev = (adr >> 16) & 0xffff;
|
|
|
|
fn = adr & 0xffff;
|
|
|
|
|
|
|
|
pdev = pci_get_slot(pbus, PCI_DEVFN(dev, fn));
|
2009-06-26 07:05:35 +08:00
|
|
|
if (!pdev || hnd == handle)
|
2009-06-11 03:55:20 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
pbus = pdev->subordinate;
|
|
|
|
pci_dev_put(pdev);
|
2009-10-13 07:01:57 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This function may be called for a non-PCI device that has a
|
|
|
|
* PCI parent (eg. a disk under a PCI SATA controller). In that
|
|
|
|
* case pdev->subordinate will be NULL for the parent.
|
|
|
|
*/
|
|
|
|
if (!pbus) {
|
|
|
|
dev_dbg(&pdev->dev, "Not a PCI-to-PCI bridge\n");
|
|
|
|
pdev = NULL;
|
|
|
|
break;
|
|
|
|
}
|
2009-06-11 03:55:20 +08:00
|
|
|
}
|
|
|
|
out:
|
|
|
|
list_for_each_entry_safe(node, tmp, &device_list, node)
|
|
|
|
kfree(node);
|
|
|
|
|
|
|
|
return pdev;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_get_pci_dev);
|
|
|
|
|
2009-02-09 14:59:29 +08:00
|
|
|
/**
|
2010-08-24 05:53:11 +08:00
|
|
|
* acpi_pci_osc_control_set - Request control of PCI root _OSC features.
|
|
|
|
* @handle: ACPI handle of a PCI root bridge (or PCIe Root Complex).
|
|
|
|
* @mask: Mask of _OSC bits to request control of, place to store control mask.
|
|
|
|
* @req: Mask of _OSC bits the control of is essential to the caller.
|
2009-02-09 14:59:29 +08:00
|
|
|
*
|
2010-08-24 05:53:11 +08:00
|
|
|
* Run _OSC query for @mask and if that is successful, compare the returned
|
|
|
|
* mask of control bits with @req. If all of the @req bits are set in the
|
|
|
|
* returned mask, run _OSC request for it.
|
|
|
|
*
|
|
|
|
* The variable at the @mask address may be modified regardless of whether or
|
|
|
|
* not the function returns success. On success it will contain the mask of
|
|
|
|
* _OSC bits the BIOS has granted control of, but its contents are meaningless
|
|
|
|
* on failure.
|
2009-02-09 14:59:29 +08:00
|
|
|
**/
|
2020-06-03 04:56:55 +08:00
|
|
|
static acpi_status acpi_pci_osc_control_set(acpi_handle handle, u32 *mask, u32 req)
|
2009-02-09 14:59:29 +08:00
|
|
|
{
|
2010-08-24 05:53:11 +08:00
|
|
|
struct acpi_pci_root *root;
|
2020-06-03 06:27:33 +08:00
|
|
|
acpi_status status;
|
2010-08-24 05:53:11 +08:00
|
|
|
u32 ctrl, capbuf[3];
|
2009-02-09 14:59:29 +08:00
|
|
|
|
2010-08-24 05:53:11 +08:00
|
|
|
if (!mask)
|
|
|
|
return AE_BAD_PARAMETER;
|
|
|
|
|
|
|
|
ctrl = *mask & OSC_PCI_CONTROL_MASKS;
|
|
|
|
if ((ctrl & req) != req)
|
2009-02-09 14:59:29 +08:00
|
|
|
return AE_TYPE;
|
|
|
|
|
|
|
|
root = acpi_pci_find_root(handle);
|
|
|
|
if (!root)
|
|
|
|
return AE_NOT_EXIST;
|
|
|
|
|
2010-08-24 05:53:11 +08:00
|
|
|
*mask = ctrl | root->osc_control_set;
|
2009-02-09 14:59:29 +08:00
|
|
|
/* No need to evaluate _OSC if the control was already granted. */
|
2010-08-24 05:53:11 +08:00
|
|
|
if ((root->osc_control_set & ctrl) == ctrl)
|
2020-06-03 06:27:33 +08:00
|
|
|
return AE_OK;
|
2009-02-09 14:59:29 +08:00
|
|
|
|
2010-08-24 05:53:11 +08:00
|
|
|
/* Need to check the available controls bits before requesting them. */
|
|
|
|
while (*mask) {
|
|
|
|
status = acpi_pci_query_osc(root, root->osc_support_set, mask);
|
|
|
|
if (ACPI_FAILURE(status))
|
2020-06-03 06:27:33 +08:00
|
|
|
return status;
|
2010-08-24 05:53:11 +08:00
|
|
|
if (ctrl == *mask)
|
|
|
|
break;
|
2013-09-06 05:07:45 +08:00
|
|
|
decode_osc_control(root, "platform does not support",
|
|
|
|
ctrl & ~(*mask));
|
2010-08-24 05:53:11 +08:00
|
|
|
ctrl = *mask;
|
|
|
|
}
|
ACPI/PCI: Do not preserve _OSC control bits returned by a query
There is the assumption in acpi_pci_osc_control_set() that it is
always sufficient to compare the mask of _OSC control bits to be
requested with the result of an _OSC query where all of the known
control bits have been checked. However, in general, that need not
be the case. For example, if an _OSC feature A depends on an _OSC
feature B and control of A, B plus another _OSC feature C is
requested simultaneously, the BIOS may return A, B, C, while it would
only return C if A and C were requested without B.
That may result in passing a wrong mask of _OSC control bits to an
_OSC control request, in which case the BIOS may only grant control
of a subset of the requested features. Moreover, acpi_pci_run_osc()
will return error code if that happens and the caller of
acpi_pci_osc_control_set() will not know that it's been granted
control of some _OSC features. Consequently, the system will
generally not work as expected.
Apart from this acpi_pci_osc_control_set() always uses the mask
of _OSC control bits returned by the very first invocation of
acpi_pci_query_osc(), but that is done with the second argument
equal to OSC_PCI_SEGMENT_GROUPS_SUPPORT which generally happens
to affect the returned _OSC control bits.
For these reasons, make acpi_pci_osc_control_set() always check if
control of the requested _OSC features will be granted before making
the final control request. As a result, the osc_control_qry and
osc_queried members of struct acpi_pci_root are not necessary any
more, so drop them and remove the remaining code referring to them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 05:55:59 +08:00
|
|
|
|
2010-08-24 05:53:11 +08:00
|
|
|
if ((ctrl & req) != req) {
|
2013-09-06 05:07:45 +08:00
|
|
|
decode_osc_control(root, "not requesting control; platform does not support",
|
|
|
|
req & ~(ctrl));
|
2020-06-03 06:27:33 +08:00
|
|
|
return AE_SUPPORT;
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
|
|
|
|
2013-09-06 05:05:54 +08:00
|
|
|
capbuf[OSC_QUERY_DWORD] = 0;
|
|
|
|
capbuf[OSC_SUPPORT_DWORD] = root->osc_support_set;
|
|
|
|
capbuf[OSC_CONTROL_DWORD] = ctrl;
|
2010-08-24 05:53:11 +08:00
|
|
|
status = acpi_pci_run_osc(handle, capbuf, mask);
|
2020-06-03 06:27:33 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
|
|
|
|
root->osc_control_set = *mask;
|
|
|
|
return AE_OK;
|
2009-02-09 14:59:29 +08:00
|
|
|
}
|
|
|
|
|
2018-08-10 12:32:12 +08:00
|
|
|
static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm,
|
|
|
|
bool is_pcie)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-09-06 05:07:45 +08:00
|
|
|
u32 support, control, requested;
|
2013-09-06 05:07:41 +08:00
|
|
|
acpi_status status;
|
|
|
|
struct acpi_device *device = root->device;
|
2013-05-29 08:31:27 +08:00
|
|
|
acpi_handle handle = device->handle;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
ACPI: Support _OSI("Darwin") correctly
Apple hardware queries _OSI("Darwin") in order to determine whether the
system is running OS X, and changes firmware behaviour based on the
answer. The most obvious difference in behaviour is that Thunderbolt
hardware is forcibly powered down unless the system is running OS X. The
obvious solution would be to simply add Darwin to the list of supported
_OSI strings, but this causes problems.
Recent Apple hardware includes two separate methods for checking _OSI
strings. The first will check whether Darwin is supported, and if so
will exit. The second will check whether Darwin is supported, but will
then continue to check for further operating systems. If a further
operating system is found then later firmware code will assume that the
OS is not OS X. This results in the unfortunate situation where the
Thunderbolt controller is available at boot time but remains powered
down after suspend.
The easiest way to handle this is to special-case it in the
Linux-specific OSI handling code. If we see Darwin, we should answer
true and then disable all other _OSI vendor strings.
The next problem is that the Apple PCI _OSC method has the following
code:
if (LEqual (0x01, OSDW ()))
if (LAnd (LEqual (Arg0, GUID), NEXP)
(do stuff)
else
(fail)
NEXP is a value in high memory and is presumably under the control of
the firmware. No methods sets it. The methods that are called in the "do
stuff" path are dummies. Unless there's some additional firmware call in
early boot, there's no way for this call to succeed - and even if it
does, it doesn't do anything.
The easiest way to handle this is simply to ignore it. We know which
flags would be set, so just set them by hand if the platform is running
in Darwin mode.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
[andreas.noever@gmail.com: merged two patches, do not touch ACPICA]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-20 19:19:47 +08:00
|
|
|
/*
|
|
|
|
* Apple always return failure on _OSC calls when _OSI("Darwin") has
|
|
|
|
* been called successfully. We know the feature set supported by the
|
|
|
|
* platform, so avoid calling _OSC at all
|
|
|
|
*/
|
2017-08-01 20:10:41 +08:00
|
|
|
if (x86_apple_machine) {
|
ACPI: Support _OSI("Darwin") correctly
Apple hardware queries _OSI("Darwin") in order to determine whether the
system is running OS X, and changes firmware behaviour based on the
answer. The most obvious difference in behaviour is that Thunderbolt
hardware is forcibly powered down unless the system is running OS X. The
obvious solution would be to simply add Darwin to the list of supported
_OSI strings, but this causes problems.
Recent Apple hardware includes two separate methods for checking _OSI
strings. The first will check whether Darwin is supported, and if so
will exit. The second will check whether Darwin is supported, but will
then continue to check for further operating systems. If a further
operating system is found then later firmware code will assume that the
OS is not OS X. This results in the unfortunate situation where the
Thunderbolt controller is available at boot time but remains powered
down after suspend.
The easiest way to handle this is to special-case it in the
Linux-specific OSI handling code. If we see Darwin, we should answer
true and then disable all other _OSI vendor strings.
The next problem is that the Apple PCI _OSC method has the following
code:
if (LEqual (0x01, OSDW ()))
if (LAnd (LEqual (Arg0, GUID), NEXP)
(do stuff)
else
(fail)
NEXP is a value in high memory and is presumably under the control of
the firmware. No methods sets it. The methods that are called in the "do
stuff" path are dummies. Unless there's some additional firmware call in
early boot, there's no way for this call to succeed - and even if it
does, it doesn't do anything.
The easiest way to handle this is simply to ignore it. We know which
flags would be set, so just set them by hand if the platform is running
in Darwin mode.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
[andreas.noever@gmail.com: merged two patches, do not touch ACPICA]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-20 19:19:47 +08:00
|
|
|
root->osc_control_set = ~OSC_PCI_EXPRESS_PME_CONTROL;
|
|
|
|
decode_osc_control(root, "OS assumes control of",
|
|
|
|
root->osc_control_set);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2006-12-21 15:21:13 +08:00
|
|
|
/*
|
2008-11-11 06:30:45 +08:00
|
|
|
* All supported architectures that use ACPI have support for
|
|
|
|
* PCI domains, so we indicate this in _OSC support capabilities.
|
2006-12-21 15:21:13 +08:00
|
|
|
*/
|
2013-09-06 05:07:43 +08:00
|
|
|
support = OSC_PCI_SEGMENT_GROUPS_SUPPORT;
|
2019-03-16 03:29:40 +08:00
|
|
|
support |= OSC_PCI_HPX_TYPE_3_SUPPORT;
|
2012-10-30 14:27:13 +08:00
|
|
|
if (pci_ext_cfg_avail())
|
2013-09-06 05:07:42 +08:00
|
|
|
support |= OSC_PCI_EXT_CONFIG_SUPPORT;
|
2013-09-06 05:07:42 +08:00
|
|
|
if (pcie_aspm_support_enabled())
|
2013-09-06 05:07:42 +08:00
|
|
|
support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
|
2008-11-11 06:31:05 +08:00
|
|
|
if (pci_msi_enabled())
|
2013-09-06 05:07:42 +08:00
|
|
|
support |= OSC_PCI_MSI_SUPPORT;
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
if (IS_ENABLED(CONFIG_PCIE_EDR))
|
|
|
|
support |= OSC_PCI_EDR_SUPPORT;
|
2013-09-06 05:07:45 +08:00
|
|
|
|
|
|
|
decode_osc_support(root, "OS supports", support);
|
2013-09-06 05:07:42 +08:00
|
|
|
status = acpi_pci_osc_support(root, support);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2018-08-10 12:32:12 +08:00
|
|
|
*no_aspm = 1;
|
|
|
|
|
|
|
|
/* _OSC is optional for PCI host bridges */
|
|
|
|
if ((status == AE_NOT_FOUND) && !is_pcie)
|
|
|
|
return;
|
|
|
|
|
2020-06-03 05:42:33 +08:00
|
|
|
dev_info(&device->dev, "_OSC: platform retains control of PCIe features (%s)\n",
|
|
|
|
acpi_format_exception(status));
|
2013-09-06 05:07:43 +08:00
|
|
|
return;
|
2012-07-31 04:40:32 +08:00
|
|
|
}
|
2013-04-02 05:47:39 +08:00
|
|
|
|
2013-09-06 05:07:43 +08:00
|
|
|
if (pcie_ports_disabled) {
|
|
|
|
dev_info(&device->dev, "PCIe port services disabled; not requesting _OSC control\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-09-06 05:50:52 +08:00
|
|
|
if ((support & ACPI_PCIE_REQ_SUPPORT) != ACPI_PCIE_REQ_SUPPORT) {
|
2013-09-06 05:07:45 +08:00
|
|
|
decode_osc_support(root, "not requesting OS control; OS requires",
|
|
|
|
ACPI_PCIE_REQ_SUPPORT);
|
2013-09-06 05:50:52 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
control = OSC_PCI_EXPRESS_CAPABILITY_CONTROL
|
|
|
|
| OSC_PCI_EXPRESS_PME_CONTROL;
|
|
|
|
|
2018-04-17 23:58:09 +08:00
|
|
|
if (IS_ENABLED(CONFIG_PCIEASPM))
|
|
|
|
control |= OSC_PCI_EXPRESS_LTR_CONTROL;
|
|
|
|
|
2018-05-24 06:19:22 +08:00
|
|
|
if (IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
|
|
|
|
control |= OSC_PCI_EXPRESS_NATIVE_HP_CONTROL;
|
|
|
|
|
2018-05-24 06:40:23 +08:00
|
|
|
if (IS_ENABLED(CONFIG_HOTPLUG_PCI_SHPC))
|
|
|
|
control |= OSC_PCI_SHPC_NATIVE_HP_CONTROL;
|
|
|
|
|
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>
2020-04-28 07:25:13 +08:00
|
|
|
if (pci_aer_available())
|
|
|
|
control |= OSC_PCI_EXPRESS_AER_CONTROL;
|
2011-01-07 07:55:09 +08:00
|
|
|
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
/*
|
|
|
|
* Per the Downstream Port Containment Related Enhancements ECN to
|
|
|
|
* the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
|
|
|
|
* OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
|
|
|
|
* and EDR.
|
|
|
|
*/
|
|
|
|
if (IS_ENABLED(CONFIG_PCIE_DPC) && IS_ENABLED(CONFIG_PCIE_EDR))
|
|
|
|
control |= OSC_PCI_EXPRESS_DPC_CONTROL;
|
|
|
|
|
2013-09-06 05:07:45 +08:00
|
|
|
requested = control;
|
2013-09-06 05:50:52 +08:00
|
|
|
status = acpi_pci_osc_control_set(handle, &control,
|
|
|
|
OSC_PCI_EXPRESS_CAPABILITY_CONTROL);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
2013-09-06 05:07:45 +08:00
|
|
|
decode_osc_control(root, "OS now controls", control);
|
2013-09-06 05:50:52 +08:00
|
|
|
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
|
PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.
The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.
But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.
Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.
This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.
To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.
Tested successfully by myself.
[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
2013-08-30 04:17:05 +08:00
|
|
|
/*
|
2015-04-08 02:07:00 +08:00
|
|
|
* We have ASPM control, but the FADT indicates that
|
|
|
|
* it's unsupported. Leave existing configuration
|
|
|
|
* intact and prevent the OS from touching it.
|
PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.
The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.
But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.
Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.
This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.
To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.
Tested successfully by myself.
[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
2013-08-30 04:17:05 +08:00
|
|
|
*/
|
2015-04-08 02:07:00 +08:00
|
|
|
dev_info(&device->dev, "FADT indicates ASPM is unsupported, using BIOS configuration\n");
|
|
|
|
*no_aspm = 1;
|
2011-03-21 11:29:20 +08:00
|
|
|
}
|
2011-04-30 06:21:38 +08:00
|
|
|
} else {
|
2013-09-06 05:07:45 +08:00
|
|
|
decode_osc_control(root, "OS requested", requested);
|
|
|
|
decode_osc_control(root, "platform willing to grant", control);
|
2020-06-03 05:42:33 +08:00
|
|
|
dev_info(&device->dev, "_OSC: platform retains control of PCIe features (%s)\n",
|
2013-09-06 05:07:45 +08:00
|
|
|
acpi_format_exception(status));
|
|
|
|
|
2013-09-06 05:50:52 +08:00
|
|
|
/*
|
|
|
|
* We want to disable ASPM here, but aspm_disabled
|
|
|
|
* needs to remain in its state from boot so that we
|
|
|
|
* properly handle PCIe 1.1 devices. So we set this
|
|
|
|
* flag here, to defer the action until after the ACPI
|
|
|
|
* root scan.
|
|
|
|
*/
|
|
|
|
*no_aspm = 1;
|
2011-01-07 07:55:09 +08:00
|
|
|
}
|
2013-09-06 05:07:41 +08:00
|
|
|
}
|
|
|
|
|
2013-01-30 21:27:33 +08:00
|
|
|
static int acpi_pci_root_add(struct acpi_device *device,
|
|
|
|
const struct acpi_device_id *not_used)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-06-19 04:46:52 +08:00
|
|
|
unsigned long long segment, bus;
|
|
|
|
acpi_status status;
|
|
|
|
int result;
|
|
|
|
struct acpi_pci_root *root;
|
2013-05-29 08:31:27 +08:00
|
|
|
acpi_handle handle = device->handle;
|
2015-04-08 02:07:00 +08:00
|
|
|
int no_aspm = 0;
|
2017-05-17 02:42:38 +08:00
|
|
|
bool hotadd = system_state == SYSTEM_RUNNING;
|
2018-08-10 12:32:12 +08:00
|
|
|
bool is_pcie;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-03-12 03:20:06 +08:00
|
|
|
root = kzalloc(sizeof(struct acpi_pci_root), GFP_KERNEL);
|
|
|
|
if (!root)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2009-06-19 04:46:52 +08:00
|
|
|
segment = 0;
|
2013-05-29 08:31:27 +08:00
|
|
|
status = acpi_evaluate_integer(handle, METHOD_NAME__SEG, NULL,
|
2009-06-19 04:46:52 +08:00
|
|
|
&segment);
|
|
|
|
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
|
2013-05-29 08:10:05 +08:00
|
|
|
dev_err(&device->dev, "can't evaluate _SEG\n");
|
2010-03-12 03:20:06 +08:00
|
|
|
result = -ENODEV;
|
|
|
|
goto end;
|
2009-06-19 04:46:52 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-06-19 04:46:52 +08:00
|
|
|
/* Check _CRS first, then _BBN. If no _BBN, default to zero. */
|
2010-03-12 03:20:06 +08:00
|
|
|
root->secondary.flags = IORESOURCE_BUS;
|
2013-05-29 08:31:27 +08:00
|
|
|
status = try_get_root_bridge_busnr(handle, &root->secondary);
|
2009-06-19 04:46:52 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2010-03-12 03:20:06 +08:00
|
|
|
/*
|
|
|
|
* We need both the start and end of the downstream bus range
|
|
|
|
* to interpret _CBA (MMCONFIG base address), so it really is
|
|
|
|
* supposed to be in _CRS. If we don't find it there, all we
|
|
|
|
* can do is assume [_BBN-0xFF] or [0-0xFF].
|
|
|
|
*/
|
|
|
|
root->secondary.end = 0xFF;
|
2013-05-29 08:10:05 +08:00
|
|
|
dev_warn(&device->dev,
|
|
|
|
FW_BUG "no secondary bus range in _CRS\n");
|
2013-05-29 08:31:27 +08:00
|
|
|
status = acpi_evaluate_integer(handle, METHOD_NAME__BBN,
|
2011-06-20 07:51:37 +08:00
|
|
|
NULL, &bus);
|
2010-03-12 03:20:06 +08:00
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
root->secondary.start = bus;
|
|
|
|
else if (status == AE_NOT_FOUND)
|
|
|
|
root->secondary.start = 0;
|
|
|
|
else {
|
2013-05-29 08:10:05 +08:00
|
|
|
dev_err(&device->dev, "can't evaluate _BBN\n");
|
2010-03-12 03:20:06 +08:00
|
|
|
result = -ENODEV;
|
|
|
|
goto end;
|
2009-06-19 04:46:52 +08:00
|
|
|
}
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-05-20 04:54:39 +08:00
|
|
|
root->device = device;
|
2009-06-19 04:47:07 +08:00
|
|
|
root->segment = segment & 0xFFFF;
|
2005-04-17 06:20:36 +08:00
|
|
|
strcpy(acpi_device_name(device), ACPI_PCI_ROOT_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
|
2008-09-23 05:37:34 +08:00
|
|
|
device->driver_data = root;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-11-09 22:48:03 +08:00
|
|
|
if (hotadd && dmar_device_add(handle)) {
|
|
|
|
result = -ENXIO;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
2021-06-02 16:54:30 +08:00
|
|
|
pr_info("%s [%s] (domain %04x %pR)\n",
|
2005-08-05 12:44:28 +08:00
|
|
|
acpi_device_name(device), acpi_device_bid(device),
|
2010-03-12 03:20:06 +08:00
|
|
|
root->segment, &root->secondary);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-05-29 08:31:27 +08:00
|
|
|
root->mcfg_addr = acpi_pci_root_get_mcfg_addr(handle);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-08-10 12:32:12 +08:00
|
|
|
is_pcie = strcmp(acpi_device_hid(device), "PNP0A08") == 0;
|
|
|
|
negotiate_os_control(root, &no_aspm, is_pcie);
|
2011-01-07 07:55:09 +08:00
|
|
|
|
PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.
The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.
But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.
Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.
This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.
To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.
Tested successfully by myself.
[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
2013-08-30 04:17:05 +08:00
|
|
|
/*
|
|
|
|
* TBD: Need PCI interface for enumeration/configuration of roots.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the Root Bridge
|
|
|
|
* --------------------
|
|
|
|
* Must do this prior to any attempt to bind the root device, as the
|
|
|
|
* PCI namespace does not get created until this call is made (and
|
|
|
|
* thus the root bridge's pci_dev does not exist).
|
|
|
|
*/
|
|
|
|
root->bus = pci_acpi_scan_root(root);
|
|
|
|
if (!root->bus) {
|
|
|
|
dev_err(&device->dev,
|
|
|
|
"Bus %04x:%02x not present in PCI namespace\n",
|
|
|
|
root->segment, (unsigned int)root->secondary.start);
|
2013-11-14 07:54:17 +08:00
|
|
|
device->driver_data = NULL;
|
PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.
The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.
But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.
Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.
This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.
To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.
Tested successfully by myself.
[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
2013-08-30 04:17:05 +08:00
|
|
|
result = -ENODEV;
|
2014-11-09 22:48:03 +08:00
|
|
|
goto remove_dmar;
|
PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available
This fixes the problem of acpiphp claiming slots that should be managed
by pciehp, which may keep ExpressCard slots from working.
The acpiphp driver claims PCIe slots unless the BIOS has granted us
control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp
.add method (add_bridge()) was always called *after* we had requested
native hotplug control with _OSC.
But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism"), which appeared in v3.10, acpiphp initialization is done
during the bus scan via the pcibios_add_bus() hook, and this happens
*before* we request native hotplug control.
Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
and it claims slots that we should be handling with native hotplug.
This patch requests native hotplug control earlier, so we know whether
the BIOS granted it to us before we initialize acpiphp.
To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert
"PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
_OSC earlier but defer the actual ASPM calls until after the bus scan is
complete.
Tested successfully by myself.
[bhelgaas: changelog, mark for stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.10+
CC: Len Brown <lenb@kernel.org>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
2013-08-30 04:17:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (no_aspm)
|
|
|
|
pcie_no_aspm();
|
|
|
|
|
2014-07-23 07:00:45 +08:00
|
|
|
pci_acpi_add_bus_pm_notifier(device);
|
2017-06-24 07:58:53 +08:00
|
|
|
device_set_wakeup_capable(root->bus->bridge, device->wakeup.flags.valid);
|
2010-02-18 06:44:09 +08:00
|
|
|
|
2014-11-09 22:48:03 +08:00
|
|
|
if (hotadd) {
|
2012-11-04 12:39:31 +08:00
|
|
|
pcibios_resource_survey_bus(root->bus);
|
2013-07-23 05:37:18 +08:00
|
|
|
pci_assign_unassigned_root_bus_resources(root->bus);
|
2016-08-17 16:00:34 +08:00
|
|
|
/*
|
|
|
|
* This is only called for the hotadd case. For the boot-time
|
|
|
|
* case, we need to wait until after PCI initialization in
|
|
|
|
* order to deal with IOAPICs mapped in on a PCI BAR.
|
|
|
|
*
|
|
|
|
* This is currently x86-specific, because acpi_ioapic_add()
|
|
|
|
* is an empty function without CONFIG_ACPI_HOTPLUG_IOAPIC.
|
|
|
|
* And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC
|
|
|
|
* (see drivers/acpi/Kconfig).
|
|
|
|
*/
|
2016-08-17 16:00:33 +08:00
|
|
|
acpi_ioapic_add(root->device->handle);
|
2013-05-29 08:04:46 +08:00
|
|
|
}
|
2012-10-31 04:31:32 +08:00
|
|
|
|
2014-01-10 22:23:14 +08:00
|
|
|
pci_lock_rescan_remove();
|
2009-06-19 04:46:57 +08:00
|
|
|
pci_bus_add_devices(root->bus);
|
2014-01-10 22:23:14 +08:00
|
|
|
pci_unlock_rescan_remove();
|
2013-01-30 21:27:33 +08:00
|
|
|
return 1;
|
2012-12-21 07:36:45 +08:00
|
|
|
|
2014-11-09 22:48:03 +08:00
|
|
|
remove_dmar:
|
|
|
|
if (hotadd)
|
|
|
|
dmar_device_remove(handle);
|
2012-12-21 07:36:45 +08:00
|
|
|
end:
|
|
|
|
kfree(root);
|
|
|
|
return result;
|
2005-04-28 15:25:45 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-01-30 21:27:33 +08:00
|
|
|
static void acpi_pci_root_remove(struct acpi_device *device)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-06-19 04:46:57 +08:00
|
|
|
struct acpi_pci_root *root = acpi_driver_data(device);
|
2012-09-18 14:20:34 +08:00
|
|
|
|
2014-01-10 22:23:14 +08:00
|
|
|
pci_lock_rescan_remove();
|
|
|
|
|
2012-10-31 04:31:43 +08:00
|
|
|
pci_stop_root_bus(root->bus);
|
|
|
|
|
2017-02-28 21:34:29 +08:00
|
|
|
pci_ioapic_remove(root);
|
2017-06-24 07:58:53 +08:00
|
|
|
device_set_wakeup_capable(root->bus->bridge, false);
|
2010-02-18 06:44:09 +08:00
|
|
|
pci_acpi_remove_bus_pm_notifier(device);
|
|
|
|
|
2012-10-31 04:31:43 +08:00
|
|
|
pci_remove_root_bus(root->bus);
|
2017-02-28 21:34:29 +08:00
|
|
|
WARN_ON(acpi_ioapic_remove(root));
|
2012-10-31 04:31:43 +08:00
|
|
|
|
2014-11-09 22:48:03 +08:00
|
|
|
dmar_device_remove(device->handle);
|
|
|
|
|
2014-01-10 22:23:14 +08:00
|
|
|
pci_unlock_rescan_remove();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(root);
|
|
|
|
}
|
|
|
|
|
2015-10-14 14:29:39 +08:00
|
|
|
/*
|
|
|
|
* Following code to support acpi_pci_root_create() is copied from
|
|
|
|
* arch/x86/pci/acpi.c and modified so it could be reused by x86, IA64
|
|
|
|
* and ARM64.
|
|
|
|
*/
|
|
|
|
static void acpi_pci_root_validate_resources(struct device *dev,
|
|
|
|
struct list_head *resources,
|
|
|
|
unsigned long type)
|
|
|
|
{
|
|
|
|
LIST_HEAD(list);
|
|
|
|
struct resource *res1, *res2, *root = NULL;
|
|
|
|
struct resource_entry *tmp, *entry, *entry2;
|
|
|
|
|
|
|
|
BUG_ON((type & (IORESOURCE_MEM | IORESOURCE_IO)) == 0);
|
|
|
|
root = (type & IORESOURCE_MEM) ? &iomem_resource : &ioport_resource;
|
|
|
|
|
|
|
|
list_splice_init(resources, &list);
|
|
|
|
resource_list_for_each_entry_safe(entry, tmp, &list) {
|
|
|
|
bool free = false;
|
|
|
|
resource_size_t end;
|
|
|
|
|
|
|
|
res1 = entry->res;
|
|
|
|
if (!(res1->flags & type))
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
/* Exclude non-addressable range or non-addressable portion */
|
|
|
|
end = min(res1->end, root->end);
|
|
|
|
if (end <= res1->start) {
|
|
|
|
dev_info(dev, "host bridge window %pR (ignored, not CPU addressable)\n",
|
|
|
|
res1);
|
|
|
|
free = true;
|
|
|
|
goto next;
|
|
|
|
} else if (res1->end != end) {
|
|
|
|
dev_info(dev, "host bridge window %pR ([%#llx-%#llx] ignored, not CPU addressable)\n",
|
|
|
|
res1, (unsigned long long)end + 1,
|
|
|
|
(unsigned long long)res1->end);
|
|
|
|
res1->end = end;
|
|
|
|
}
|
|
|
|
|
|
|
|
resource_list_for_each_entry(entry2, resources) {
|
|
|
|
res2 = entry2->res;
|
|
|
|
if (!(res2->flags & type))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* I don't like throwing away windows because then
|
|
|
|
* our resources no longer match the ACPI _CRS, but
|
|
|
|
* the kernel resource tree doesn't allow overlaps.
|
|
|
|
*/
|
2020-11-04 04:45:09 +08:00
|
|
|
if (resource_union(res1, res2, res2)) {
|
2015-10-14 14:29:39 +08:00
|
|
|
dev_info(dev, "host bridge window expanded to %pR; %pR ignored\n",
|
|
|
|
res2, res1);
|
|
|
|
free = true;
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
next:
|
|
|
|
resource_list_del(entry);
|
|
|
|
if (free)
|
|
|
|
resource_list_free_entry(entry);
|
|
|
|
else
|
|
|
|
resource_list_add_tail(entry, resources);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-15 02:15:52 +08:00
|
|
|
static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
|
|
|
|
struct resource_entry *entry)
|
2016-06-11 03:55:12 +08:00
|
|
|
{
|
|
|
|
#ifdef PCI_IOBASE
|
|
|
|
struct resource *res = entry->res;
|
|
|
|
resource_size_t cpu_addr = res->start;
|
|
|
|
resource_size_t pci_addr = cpu_addr - entry->offset;
|
|
|
|
resource_size_t length = resource_size(res);
|
|
|
|
unsigned long port;
|
|
|
|
|
2018-03-15 02:15:52 +08:00
|
|
|
if (pci_register_io_range(fwnode, cpu_addr, length))
|
2016-06-11 03:55:12 +08:00
|
|
|
goto err;
|
|
|
|
|
|
|
|
port = pci_address_to_pio(cpu_addr);
|
|
|
|
if (port == (unsigned long)-1)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
res->start = port;
|
|
|
|
res->end = port + length - 1;
|
|
|
|
entry->offset = port - pci_addr;
|
|
|
|
|
|
|
|
if (pci_remap_iospace(res, cpu_addr) < 0)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
pr_info("Remapped I/O %pa to %pR\n", &cpu_addr, res);
|
|
|
|
return;
|
|
|
|
err:
|
|
|
|
res->flags |= IORESOURCE_DISABLED;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-10-14 14:29:39 +08:00
|
|
|
int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct list_head *list = &info->resources;
|
|
|
|
struct acpi_device *device = info->bridge;
|
|
|
|
struct resource_entry *entry, *tmp;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_MEM_8AND16BIT;
|
|
|
|
ret = acpi_dev_get_resources(device, list,
|
|
|
|
acpi_dev_filter_resource_type_cb,
|
|
|
|
(void *)flags);
|
|
|
|
if (ret < 0)
|
|
|
|
dev_warn(&device->dev,
|
|
|
|
"failed to parse _CRS method, error code %d\n", ret);
|
|
|
|
else if (ret == 0)
|
|
|
|
dev_dbg(&device->dev,
|
|
|
|
"no IO and memory resources present in _CRS\n");
|
|
|
|
else {
|
|
|
|
resource_list_for_each_entry_safe(entry, tmp, list) {
|
2016-06-11 03:55:12 +08:00
|
|
|
if (entry->res->flags & IORESOURCE_IO)
|
2018-03-15 02:15:52 +08:00
|
|
|
acpi_pci_root_remap_iospace(&device->fwnode,
|
|
|
|
entry);
|
2016-06-11 03:55:12 +08:00
|
|
|
|
2015-10-14 14:29:39 +08:00
|
|
|
if (entry->res->flags & IORESOURCE_DISABLED)
|
|
|
|
resource_list_destroy_entry(entry);
|
|
|
|
else
|
|
|
|
entry->res->name = info->name;
|
|
|
|
}
|
|
|
|
acpi_pci_root_validate_resources(&device->dev, list,
|
|
|
|
IORESOURCE_MEM);
|
|
|
|
acpi_pci_root_validate_resources(&device->dev, list,
|
|
|
|
IORESOURCE_IO);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_acpi_root_add_resources(struct acpi_pci_root_info *info)
|
|
|
|
{
|
|
|
|
struct resource_entry *entry, *tmp;
|
|
|
|
struct resource *res, *conflict, *root = NULL;
|
|
|
|
|
|
|
|
resource_list_for_each_entry_safe(entry, tmp, &info->resources) {
|
|
|
|
res = entry->res;
|
|
|
|
if (res->flags & IORESOURCE_MEM)
|
|
|
|
root = &iomem_resource;
|
|
|
|
else if (res->flags & IORESOURCE_IO)
|
|
|
|
root = &ioport_resource;
|
|
|
|
else
|
|
|
|
continue;
|
|
|
|
|
2015-11-27 11:12:33 +08:00
|
|
|
/*
|
|
|
|
* Some legacy x86 host bridge drivers use iomem_resource and
|
|
|
|
* ioport_resource as default resource pool, skip it.
|
|
|
|
*/
|
|
|
|
if (res == root)
|
|
|
|
continue;
|
|
|
|
|
2015-10-14 14:29:39 +08:00
|
|
|
conflict = insert_resource_conflict(root, res);
|
|
|
|
if (conflict) {
|
|
|
|
dev_info(&info->bridge->dev,
|
|
|
|
"ignoring host bridge window %pR (conflicts with %s %pR)\n",
|
|
|
|
res, conflict->name, conflict);
|
|
|
|
resource_list_destroy_entry(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __acpi_pci_root_release_info(struct acpi_pci_root_info *info)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
struct resource_entry *entry, *tmp;
|
|
|
|
|
|
|
|
if (!info)
|
|
|
|
return;
|
|
|
|
|
|
|
|
resource_list_for_each_entry_safe(entry, tmp, &info->resources) {
|
|
|
|
res = entry->res;
|
|
|
|
if (res->parent &&
|
|
|
|
(res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
|
|
|
|
release_resource(res);
|
|
|
|
resource_list_destroy_entry(entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
info->ops->release_info(info);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_pci_root_release_info(struct pci_host_bridge *bridge)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
struct resource_entry *entry;
|
|
|
|
|
|
|
|
resource_list_for_each_entry(entry, &bridge->windows) {
|
|
|
|
res = entry->res;
|
2016-06-11 03:55:12 +08:00
|
|
|
if (res->flags & IORESOURCE_IO)
|
|
|
|
pci_unmap_iospace(res);
|
2015-10-14 14:29:39 +08:00
|
|
|
if (res->parent &&
|
|
|
|
(res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
|
|
|
|
release_resource(res);
|
|
|
|
}
|
|
|
|
__acpi_pci_root_release_info(bridge->release_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
|
|
|
|
struct acpi_pci_root_ops *ops,
|
|
|
|
struct acpi_pci_root_info *info,
|
|
|
|
void *sysdata)
|
|
|
|
{
|
|
|
|
int ret, busnum = root->secondary.start;
|
|
|
|
struct acpi_device *device = root->device;
|
|
|
|
int node = acpi_get_node(device->handle);
|
|
|
|
struct pci_bus *bus;
|
2018-03-10 01:21:25 +08:00
|
|
|
struct pci_host_bridge *host_bridge;
|
2019-06-15 08:23:57 +08:00
|
|
|
union acpi_object *obj;
|
2015-10-14 14:29:39 +08:00
|
|
|
|
|
|
|
info->root = root;
|
|
|
|
info->bridge = device;
|
|
|
|
info->ops = ops;
|
|
|
|
INIT_LIST_HEAD(&info->resources);
|
|
|
|
snprintf(info->name, sizeof(info->name), "PCI Bus %04x:%02x",
|
|
|
|
root->segment, busnum);
|
|
|
|
|
|
|
|
if (ops->init_info && ops->init_info(info))
|
|
|
|
goto out_release_info;
|
|
|
|
if (ops->prepare_resources)
|
|
|
|
ret = ops->prepare_resources(info);
|
|
|
|
else
|
|
|
|
ret = acpi_pci_probe_root_resources(info);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out_release_info;
|
|
|
|
|
|
|
|
pci_acpi_root_add_resources(info);
|
|
|
|
pci_add_resource(&info->resources, &root->secondary);
|
|
|
|
bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
|
|
|
|
sysdata, &info->resources);
|
|
|
|
if (!bus)
|
|
|
|
goto out_release_info;
|
|
|
|
|
2018-03-10 01:21:25 +08:00
|
|
|
host_bridge = to_pci_host_bridge(bus->bridge);
|
|
|
|
if (!(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL))
|
2018-05-24 06:22:19 +08:00
|
|
|
host_bridge->native_pcie_hotplug = 0;
|
2018-05-24 06:40:23 +08:00
|
|
|
if (!(root->osc_control_set & OSC_PCI_SHPC_NATIVE_HP_CONTROL))
|
|
|
|
host_bridge->native_shpc_hotplug = 0;
|
2018-03-10 01:21:25 +08:00
|
|
|
if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL))
|
|
|
|
host_bridge->native_aer = 0;
|
|
|
|
if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL))
|
|
|
|
host_bridge->native_pme = 0;
|
2018-04-17 23:58:09 +08:00
|
|
|
if (!(root->osc_control_set & OSC_PCI_EXPRESS_LTR_CONTROL))
|
|
|
|
host_bridge->native_ltr = 0;
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL))
|
|
|
|
host_bridge->native_dpc = 0;
|
2018-03-10 01:21:25 +08:00
|
|
|
|
2019-06-15 08:23:57 +08:00
|
|
|
/*
|
|
|
|
* Evaluate the "PCI Boot Configuration" _DSM Function. If it
|
|
|
|
* exists and returns 0, we must preserve any PCI resource
|
|
|
|
* assignments made by firmware for this host bridge.
|
|
|
|
*/
|
|
|
|
obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid, 1,
|
2020-05-27 05:39:05 +08:00
|
|
|
DSM_PCI_PRESERVE_BOOT_CONFIG, NULL);
|
2019-06-15 08:23:57 +08:00
|
|
|
if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0)
|
|
|
|
host_bridge->preserve_config = 1;
|
|
|
|
ACPI_FREE(obj);
|
|
|
|
|
2015-10-14 14:29:39 +08:00
|
|
|
pci_scan_child_bus(bus);
|
2018-03-10 01:21:25 +08:00
|
|
|
pci_set_host_bridge_release(host_bridge, acpi_pci_root_release_info,
|
|
|
|
info);
|
2015-10-14 14:29:39 +08:00
|
|
|
if (node != NUMA_NO_NODE)
|
|
|
|
dev_printk(KERN_DEBUG, &bus->dev, "on NUMA node %d\n", node);
|
|
|
|
return bus;
|
|
|
|
|
|
|
|
out_release_info:
|
|
|
|
__acpi_pci_root_release_info(info);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-01-30 21:27:33 +08:00
|
|
|
void __init acpi_pci_root_init(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2011-01-17 03:44:22 +08:00
|
|
|
acpi_hest_init();
|
2013-11-23 04:55:20 +08:00
|
|
|
if (acpi_pci_disabled)
|
2013-01-22 05:20:48 +08:00
|
|
|
return;
|
|
|
|
|
2013-11-23 04:55:20 +08:00
|
|
|
pci_acpi_crs_quirks();
|
|
|
|
acpi_scan_add_handler_with_hotplug(&pci_root_handler, "pci_root");
|
2013-01-22 05:20:48 +08:00
|
|
|
}
|