License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2008-10-13 11:18:07 +00:00
|
|
|
#ifndef DRIVERS_PCI_H
|
|
|
|
|
#define DRIVERS_PCI_H
|
|
|
|
|
|
2018-11-28 22:28:04 +00:00
|
|
|
#include <linux/pci.h>
|
|
|
|
|
|
2019-12-10 21:51:33 +00:00
|
|
|
/* Number of possible devfns: 0.0 to 1f.7 inclusive */
|
|
|
|
|
#define MAX_NR_DEVFNS 256
|
|
|
|
|
|
2015-06-30 01:16:41 +00:00
|
|
|
#define PCI_FIND_CAP_TTL 48
|
|
|
|
|
|
PCI: Recognize Thunderbolt devices
Detect on probe whether a PCI device is part of a Thunderbolt controller.
Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
on such devices. Detect presence of this VSEC and cache it in a newly
added is_thunderbolt bit in struct pci_dev.
Also, add a helper to check whether a given PCI device is situated on a
Thunderbolt daisy chain (i.e., below a PCI device with is_thunderbolt
set).
The necessity arises from the following:
* If an external Thunderbolt GPU is connected to a dual GPU laptop,
that GPU is currently registered with vga_switcheroo even though it
can neither drive the laptop's panel nor be powered off by the
platform. To vga_switcheroo it will appear as if two discrete
GPUs are present. As a result, when the external GPU is runtime
suspended, vga_switcheroo will cut power to the internal discrete GPU
which may not be runtime suspended at all at this moment. The
solution is to not register external GPUs with vga_switcheroo, which
necessitates a way to recognize if they're on a Thunderbolt daisy
chain.
* Dual GPU MacBook Pros introduced 2011+ can no longer switch external
DisplayPort ports between GPUs. (They're no longer just used for DP
but have become combined DP/Thunderbolt ports.) The driver to switch
the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence
of a Thunderbolt controller and, if found, keep external ports
permanently switched to the discrete GPU.
v2: Make kerneldoc for pci_is_thunderbolt_attached() more precise,
drop portion of commit message pertaining to separate series.
(Bjorn Helgaas)
Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Michael Jamet <michael.jamet@intel.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Amir Levy <amir.jer.levy@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/0ab165a4a35c0b60f29d4c306c653ead14fcd8f9.1489145162.git.lukas@wunner.de
2017-03-10 20:23:45 +00:00
|
|
|
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
|
|
|
|
|
|
2013-07-31 06:53:16 +00:00
|
|
|
extern const unsigned char pcie_link_speed[];
|
2018-06-05 02:16:09 +00:00
|
|
|
extern bool pci_early_dump;
|
2013-07-31 06:53:16 +00:00
|
|
|
|
2014-11-11 20:09:46 +00:00
|
|
|
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
|
2019-10-18 16:52:21 +00:00
|
|
|
bool pcie_cap_has_rtctl(const struct pci_dev *dev);
|
2014-11-11 20:09:46 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Functions internal to the PCI core code */
|
|
|
|
|
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_create_sysfs_dev_files(struct pci_dev *pdev);
|
|
|
|
|
void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
|
|
|
|
|
void pci_cleanup_rom(struct pci_dev *dev);
|
PCI/sysfs: Convert "index", "acpi_index", "label" to static attributes
The "label", "index", and "acpi_index" sysfs attributes show firmware label
information about the device. If the ACPI Device Name _DSM is implemented
for the device, we have:
label Device name (optional, may be null)
acpi_index Instance number (unique under \_SB scope)
When there is no ACPI _DSM and SMBIOS provides an Onboard Devices structure
for the device, we have:
label Reference Designation, e.g., a silkscreen label
index Device Type Instance
Previously these attributes were dynamically created either by
pci_bus_add_device() or the pci_sysfs_init() initcall, but since they don't
need to be created or removed dynamically, we can use a static attribute so
the device model takes care of addition and removal automatically.
Convert "label", "index", and "acpi_index" to static attributes.
Presence of the ACPI _DSM (device_has_acpi_name()) determines whether the
ACPI information (label, acpi_index) or the SMBIOS information (label,
index) is visible.
[bhelgaas: commit log, split to separate patch, add "pci_dev_" prefix]
Suggested-by: Oliver O'Halloran <oohall@gmail.com>
Link: https://lore.kernel.org/r/20210416205856.3234481-6-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-04-27 15:49:16 +00:00
|
|
|
#ifdef CONFIG_DMI
|
|
|
|
|
extern const struct attribute_group pci_dev_smbios_attr_group;
|
|
|
|
|
#endif
|
2017-04-12 12:25:59 +00:00
|
|
|
|
2010-11-10 10:03:21 +00:00
|
|
|
enum pci_mmap_api {
|
|
|
|
|
PCI_MMAP_SYSFS, /* mmap on /sys/bus/pci/devices/<BDF>/resource<N> */
|
|
|
|
|
PCI_MMAP_PROCFS /* mmap on /proc/bus/pci/<BDF> */
|
|
|
|
|
};
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vmai,
|
|
|
|
|
enum pci_mmap_api mmap_api);
|
2017-04-12 12:25:59 +00:00
|
|
|
|
2021-08-17 18:04:54 +00:00
|
|
|
bool pci_reset_supported(struct pci_dev *dev);
|
|
|
|
|
void pci_init_reset_methods(struct pci_dev *dev);
|
2018-07-19 23:04:11 +00:00
|
|
|
int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
|
2018-09-20 16:27:11 +00:00
|
|
|
int pci_bus_error_reset(struct pci_dev *dev);
|
2007-07-17 04:27:10 +00:00
|
|
|
|
2020-09-29 19:24:11 +00:00
|
|
|
#define PCI_PM_D2_DELAY 200 /* usec; see PCIe r4.0, sec 5.9.1 */
|
|
|
|
|
#define PCI_PM_D3HOT_WAIT 10 /* msec */
|
|
|
|
|
#define PCI_PM_D3COLD_WAIT 100 /* msec */
|
2019-07-24 23:38:38 +00:00
|
|
|
|
2008-07-07 01:32:02 +00:00
|
|
|
/**
|
2009-01-10 01:04:26 +00:00
|
|
|
* struct pci_platform_pm_ops - Firmware PM callbacks
|
2008-07-07 01:32:02 +00:00
|
|
|
*
|
2018-09-27 21:57:14 +00:00
|
|
|
* @bridge_d3: Does the bridge allow entering into D3
|
|
|
|
|
*
|
2009-01-10 01:04:26 +00:00
|
|
|
* @is_manageable: returns 'true' if given device is power manageable by the
|
2017-12-02 19:21:37 +00:00
|
|
|
* platform firmware
|
2008-07-07 01:32:02 +00:00
|
|
|
*
|
2009-01-10 01:04:26 +00:00
|
|
|
* @set_state: invokes the platform firmware to set the device's power state
|
2008-07-07 01:32:02 +00:00
|
|
|
*
|
2016-09-18 03:39:20 +00:00
|
|
|
* @get_state: queries the platform firmware for a device's current power state
|
|
|
|
|
*
|
2019-06-25 12:09:12 +00:00
|
|
|
* @refresh_state: asks the platform to refresh the device's power state data
|
|
|
|
|
*
|
2009-01-10 01:04:26 +00:00
|
|
|
* @choose_state: returns PCI power state of given device preferred by the
|
2017-12-02 19:21:37 +00:00
|
|
|
* platform; to be used during system-wide transitions from a
|
|
|
|
|
* sleeping state to the working state and vice versa
|
2008-07-07 01:32:02 +00:00
|
|
|
*
|
2017-06-23 23:57:35 +00:00
|
|
|
* @set_wakeup: enables/disables wakeup capability for the device
|
2010-02-17 22:44:09 +00:00
|
|
|
*
|
2015-01-21 01:17:42 +00:00
|
|
|
* @need_resume: returns 'true' if the given device (which is currently
|
2017-12-02 19:21:37 +00:00
|
|
|
* suspended) needs to be resumed to be configured for system
|
|
|
|
|
* wakeup.
|
2015-01-21 01:17:42 +00:00
|
|
|
*
|
2008-07-07 01:32:02 +00:00
|
|
|
* If given platform is generally capable of power managing PCI devices, all of
|
|
|
|
|
* these callbacks are mandatory.
|
|
|
|
|
*/
|
|
|
|
|
struct pci_platform_pm_ops {
|
2018-09-27 21:57:14 +00:00
|
|
|
bool (*bridge_d3)(struct pci_dev *dev);
|
2008-07-07 01:32:02 +00:00
|
|
|
bool (*is_manageable)(struct pci_dev *dev);
|
|
|
|
|
int (*set_state)(struct pci_dev *dev, pci_power_t state);
|
2016-09-18 03:39:20 +00:00
|
|
|
pci_power_t (*get_state)(struct pci_dev *dev);
|
2019-06-25 12:09:12 +00:00
|
|
|
void (*refresh_state)(struct pci_dev *dev);
|
2008-07-07 01:32:02 +00:00
|
|
|
pci_power_t (*choose_state)(struct pci_dev *dev);
|
2017-06-23 23:57:35 +00:00
|
|
|
int (*set_wakeup)(struct pci_dev *dev, bool enable);
|
2015-01-21 01:17:42 +00:00
|
|
|
bool (*need_resume)(struct pci_dev *dev);
|
2008-07-07 01:32:02 +00:00
|
|
|
};
|
|
|
|
|
|
2015-12-06 16:33:45 +00:00
|
|
|
int pci_set_platform_pm(const struct pci_platform_pm_ops *ops);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
|
2019-06-25 12:09:12 +00:00
|
|
|
void pci_refresh_power_state(struct pci_dev *dev);
|
2019-11-05 10:27:49 +00:00
|
|
|
int pci_power_up(struct pci_dev *dev);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_disable_enabled_device(struct pci_dev *dev);
|
|
|
|
|
int pci_finish_runtime_suspend(struct pci_dev *dev);
|
2020-07-16 22:34:30 +00:00
|
|
|
void pcie_clear_device_status(struct pci_dev *dev);
|
2018-03-09 17:06:53 +00:00
|
|
|
void pcie_clear_root_pme_status(struct pci_dev *dev);
|
2019-07-24 23:38:39 +00:00
|
|
|
bool pci_check_pme_status(struct pci_dev *dev);
|
|
|
|
|
void pci_pme_wakeup_bus(struct pci_bus *bus);
|
2013-04-12 18:02:59 +00:00
|
|
|
int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
|
2017-07-12 01:05:39 +00:00
|
|
|
void pci_pme_restore(struct pci_dev *dev);
|
2019-06-06 22:32:31 +00:00
|
|
|
bool pci_dev_need_resume(struct pci_dev *dev);
|
|
|
|
|
void pci_dev_adjust_pme(struct pci_dev *dev);
|
2015-09-29 23:10:24 +00:00
|
|
|
void pci_dev_complete_resume(struct pci_dev *pci_dev);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_config_pm_runtime_get(struct pci_dev *dev);
|
|
|
|
|
void pci_config_pm_runtime_put(struct pci_dev *dev);
|
|
|
|
|
void pci_pm_init(struct pci_dev *dev);
|
2015-10-29 22:35:39 +00:00
|
|
|
void pci_ea_init(struct pci_dev *dev);
|
2020-12-03 18:51:08 +00:00
|
|
|
void pci_msi_init(struct pci_dev *dev);
|
|
|
|
|
void pci_msix_init(struct pci_dev *dev);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_allocate_cap_save_buffers(struct pci_dev *dev);
|
2012-02-11 08:18:30 +00:00
|
|
|
void pci_free_cap_save_buffers(struct pci_dev *dev);
|
2016-10-28 08:52:06 +00:00
|
|
|
bool pci_bridge_d3_possible(struct pci_dev *dev);
|
2016-10-28 08:52:06 +00:00
|
|
|
void pci_bridge_d3_update(struct pci_dev *dev);
|
PCI/PM: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that consists
of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe Gen3
so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 5.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that we
must follow the rules in PCIe 5.0 section 6.6.1.
For the PCIe Gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0 GT/s,
software must wait a minimum of 100 ms after Link training completes
before sending a Configuration Request to the device immediately below
that Port. Software can determine when Link training completes by polling
the Data Link Layer Link Active bit or by setting up an associated
interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
0000:00:1b.0: wait for 100 ms after DLLLA is set before access to 0000:01:00.0
0000:02:00.0: wait for 100 ms after DLLLA is set before access to 0000:03:00.0
0000:02:02.0: wait for 100 ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with some additional logging so we can see the
actual delays performed:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
For the switch upstream port (01:00.0 reachable through 00:1b.0 root port)
we wait for 100 ms but not taking into account the DLLLA requirement. We
then wait 10 ms for D3hot -> D0 transition of the root port and the two
downstream hotplug ports. This means that we deviate from what the spec
requires.
Performing the same check for system sleep (s2idle) transitions it turns
out to be even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays but
this platform does not provide the _DSM and does not go to S3 anyway so no
firmware is involved that could already handle these delays.
On this particular platform these delays are not actually needed because
there is an additional delay as part of the ACPI power resource that is
used to turn on power to the hierarchy but since that additional delay is
not required by any of standards (PCIe, ACPI) it is not present in the
Intel Ice Lake, for example where missing the mandatory delays causes
pciehp to start tearing down the stack too early (links are not yet
trained). Below is an example how it looks like when this happens:
pcieport 0000:83:04.0: pciehp: Slot(4): Card not present
pcieport 0000:87:04.0: PME# disabled
pcieport 0000:83:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:86:00
pcieport 0000:86:00.0: Refused to change power state, currently in D3
pcieport 0000:86:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x201ff)
pcieport 0000:86:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0)
...
There is also one reported case (see the bugzilla link below) where the
missing delay causes xHCI on a Titan Ridge controller fail to runtime
resume when USB-C dock is plugged. This does not involve pciehp but instead
the PCI core fails to runtime resume the xHCI device:
pcieport 0000:04:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:04:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100406)
xhci_hcd 0000:39:00.0: Refused to change power state, currently in D3
xhci_hcd 0000:39:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x1ff)
xhci_hcd 0000:39:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0)
...
Add a new function pci_bridge_wait_for_secondary_bus() that is called on
PCI core resume and runtime resume paths accordingly if the bridge entered
D3cold (and thus went through reset).
This is second attempt to add the missing delays. The previous solution in
c2bf1fc212f7 ("PCI: Add missing link delays required by the PCIe spec") was
reverted because of two issues it caused:
1. One system become unresponsive after S3 resume due to PME service
spinning in pcie_pme_work_fn(). The root port in question reports that
the xHCI sent PME but the xHCI device itself does not have PME status
set. The PME status bit is never cleared in the root port resulting
the indefinite loop in pcie_pme_work_fn().
2. Slows down resume if the root/downstream port does not support Data
Link Layer Active Reporting because pcie_wait_for_link_delay() waits
1100 ms in that case.
This version should avoid the above issues because we restrict the delay to
happen only if the port went into D3cold.
Link: https://lore.kernel.org/linux-pci/SL2P216MB01878BBCD75F21D882AEEA2880C60@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203885
Link: https://lore.kernel.org/r/20191112091617.70282-3-mika.westerberg@linux.intel.com
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-11-12 09:16:17 +00:00
|
|
|
void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev);
|
2009-01-16 20:54:43 +00:00
|
|
|
|
2010-12-29 12:21:23 +00:00
|
|
|
static inline void pci_wakeup_event(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
/* Wait 100 ms before the system can be put into a sleep state. */
|
|
|
|
|
pm_wakeup_event(&dev->dev, 100);
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-04 04:23:36 +00:00
|
|
|
static inline bool pci_has_subordinate(struct pci_dev *pci_dev)
|
2009-01-16 20:54:43 +00:00
|
|
|
{
|
|
|
|
|
return !!(pci_dev->subordinate);
|
|
|
|
|
}
|
2005-03-19 05:15:48 +00:00
|
|
|
|
2016-06-02 08:17:12 +00:00
|
|
|
static inline bool pci_power_manageable(struct pci_dev *pci_dev)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Currently we allow normal PCI devices and PCI bridges transition
|
|
|
|
|
* into D3 if their bridge_d3 is set.
|
|
|
|
|
*/
|
|
|
|
|
return !pci_has_subordinate(pci_dev) || pci_dev->bridge_d3;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-22 08:55:52 +00:00
|
|
|
static inline bool pcie_downstream_port(const struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
int type = pci_pcie_type(dev);
|
|
|
|
|
|
|
|
|
|
return type == PCI_EXP_TYPE_ROOT_PORT ||
|
|
|
|
|
type == PCI_EXP_TYPE_DOWNSTREAM ||
|
|
|
|
|
type == PCI_EXP_TYPE_PCIE_BRIDGE;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-01 16:37:47 +00:00
|
|
|
void pci_vpd_init(struct pci_dev *dev);
|
2016-02-22 19:58:06 +00:00
|
|
|
void pci_vpd_release(struct pci_dev *dev);
|
2021-04-16 20:58:40 +00:00
|
|
|
extern const struct attribute_group pci_dev_vpd_attr_group;
|
2008-03-05 16:52:39 +00:00
|
|
|
|
2019-07-24 23:38:41 +00:00
|
|
|
/* PCI Virtual Channel */
|
|
|
|
|
int pci_save_vc_state(struct pci_dev *dev);
|
|
|
|
|
void pci_restore_vc_state(struct pci_dev *dev);
|
|
|
|
|
void pci_allocate_vc_save_buffers(struct pci_dev *dev);
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* PCI /proc functions */
|
|
|
|
|
#ifdef CONFIG_PROC_FS
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_proc_attach_device(struct pci_dev *dev);
|
|
|
|
|
int pci_proc_detach_device(struct pci_dev *dev);
|
|
|
|
|
int pci_proc_detach_bus(struct pci_bus *bus);
|
2005-04-16 22:20:36 +00:00
|
|
|
#else
|
|
|
|
|
static inline int pci_proc_attach_device(struct pci_dev *dev) { return 0; }
|
|
|
|
|
static inline int pci_proc_detach_device(struct pci_dev *dev) { return 0; }
|
|
|
|
|
static inline int pci_proc_detach_bus(struct pci_bus *bus) { return 0; }
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Functions for PCI Hotplug drivers to use */
|
2012-05-18 19:46:34 +00:00
|
|
|
int pci_hp_add_bridge(struct pci_dev *dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-10-03 09:49:32 +00:00
|
|
|
#ifdef HAVE_PCI_LEGACY
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_create_legacy_files(struct pci_bus *bus);
|
|
|
|
|
void pci_remove_legacy_files(struct pci_bus *bus);
|
2008-10-03 09:49:32 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_create_legacy_files(struct pci_bus *bus) { return; }
|
|
|
|
|
static inline void pci_remove_legacy_files(struct pci_bus *bus) { return; }
|
|
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
/* Lock for read/write access to pci device and bus lists */
|
2006-06-02 04:35:43 +00:00
|
|
|
extern struct rw_semaphore pci_bus_sem;
|
2018-09-20 16:27:11 +00:00
|
|
|
extern struct mutex pci_slot_mutex;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-11-04 08:46:00 +00:00
|
|
|
extern raw_spinlock_t pci_lock;
|
|
|
|
|
|
2020-07-30 21:08:48 +00:00
|
|
|
extern unsigned int pci_pm_d3hot_delay;
|
2007-01-25 08:34:07 +00:00
|
|
|
|
2005-08-16 22:16:05 +00:00
|
|
|
#ifdef CONFIG_PCI_MSI
|
2006-03-06 05:33:34 +00:00
|
|
|
void pci_no_msi(void);
|
2005-08-16 22:16:05 +00:00
|
|
|
#else
|
2006-03-06 05:33:34 +00:00
|
|
|
static inline void pci_no_msi(void) { }
|
2005-08-16 22:16:05 +00:00
|
|
|
#endif
|
2007-01-25 08:34:08 +00:00
|
|
|
|
2012-02-24 03:23:30 +00:00
|
|
|
void pci_realloc_get_opt(char *);
|
2011-07-07 18:19:10 +00:00
|
|
|
|
2006-07-12 15:59:00 +00:00
|
|
|
static inline int pci_no_d1d2(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
unsigned int parent_dstates = 0;
|
2005-08-16 22:16:05 +00:00
|
|
|
|
2006-07-12 15:59:00 +00:00
|
|
|
if (dev->bus->self)
|
|
|
|
|
parent_dstates = dev->bus->self->no_d1d2;
|
|
|
|
|
return (dev->no_d1d2 || parent_dstates);
|
|
|
|
|
|
|
|
|
|
}
|
2013-10-07 06:55:40 +00:00
|
|
|
extern const struct attribute_group *pci_dev_groups[];
|
2013-07-24 22:05:17 +00:00
|
|
|
extern const struct attribute_group *pcibus_groups[];
|
2017-09-12 11:13:33 +00:00
|
|
|
extern const struct device_type pci_dev_type;
|
2013-10-07 20:51:02 +00:00
|
|
|
extern const struct attribute_group *pci_bus_groups[];
|
2009-03-20 20:56:31 +00:00
|
|
|
|
2019-07-24 23:38:42 +00:00
|
|
|
extern unsigned long pci_hotplug_io_size;
|
2019-10-23 12:12:29 +00:00
|
|
|
extern unsigned long pci_hotplug_mmio_size;
|
|
|
|
|
extern unsigned long pci_hotplug_mmio_pref_size;
|
2019-07-24 23:38:42 +00:00
|
|
|
extern unsigned long pci_hotplug_bus_size;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pci_match_one_device - Tell if a PCI device structure has a matching
|
2017-12-02 19:21:37 +00:00
|
|
|
* PCI device id structure
|
2005-04-16 22:20:36 +00:00
|
|
|
* @id: single PCI device id structure to match
|
|
|
|
|
* @dev: the PCI device structure to match against
|
2008-01-30 23:21:33 +00:00
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
* Returns the matching pci_device_id structure or %NULL if there is no match.
|
|
|
|
|
*/
|
|
|
|
|
static inline const struct pci_device_id *
|
|
|
|
|
pci_match_one_device(const struct pci_device_id *id, const struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
if ((id->vendor == PCI_ANY_ID || id->vendor == dev->vendor) &&
|
|
|
|
|
(id->device == PCI_ANY_ID || id->device == dev->device) &&
|
|
|
|
|
(id->subvendor == PCI_ANY_ID || id->subvendor == dev->subsystem_vendor) &&
|
|
|
|
|
(id->subdevice == PCI_ANY_ID || id->subdevice == dev->subsystem_device) &&
|
|
|
|
|
!((id->class ^ dev->class) & id->class_mask))
|
|
|
|
|
return id;
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-10 21:28:50 +00:00
|
|
|
/* PCI slot sysfs helper code */
|
|
|
|
|
#define to_pci_slot(s) container_of(s, struct pci_slot, kobj)
|
|
|
|
|
|
|
|
|
|
extern struct kset *pci_slots_kset;
|
|
|
|
|
|
|
|
|
|
struct pci_slot_attribute {
|
|
|
|
|
struct attribute attr;
|
|
|
|
|
ssize_t (*show)(struct pci_slot *, char *);
|
|
|
|
|
ssize_t (*store)(struct pci_slot *, const char *, size_t);
|
|
|
|
|
};
|
|
|
|
|
#define to_pci_slot_attr(s) container_of(s, struct pci_slot_attribute, attr)
|
|
|
|
|
|
2008-11-21 18:40:40 +00:00
|
|
|
enum pci_bar_type {
|
|
|
|
|
pci_bar_unknown, /* Standard PCI BAR probe */
|
2017-12-02 19:21:37 +00:00
|
|
|
pci_bar_io, /* An I/O port BAR */
|
2008-11-21 18:40:40 +00:00
|
|
|
pci_bar_mem32, /* A 32-bit memory BAR */
|
|
|
|
|
pci_bar_mem64, /* A 64-bit memory BAR */
|
|
|
|
|
};
|
|
|
|
|
|
2019-07-24 23:38:40 +00:00
|
|
|
struct device *pci_get_host_bridge_device(struct pci_dev *dev);
|
|
|
|
|
void pci_put_host_bridge_device(struct device *dev);
|
|
|
|
|
|
2017-07-12 04:04:14 +00:00
|
|
|
int pci_configure_extended_tags(struct pci_dev *dev, void *ign);
|
2012-01-27 18:55:10 +00:00
|
|
|
bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
|
|
|
|
|
int crs_timeout);
|
PCI: Workaround IDT switch ACS Source Validation erratum
Some IDT switches incorrectly flag an ACS Source Validation error on
completions for config read requests even though PCIe r4.0, sec 6.12.1.1,
says that completions are never affected by ACS Source Validation. Here's
the text of IDT 89H32H8G3-YC, erratum #36:
Item #36 - Downstream port applies ACS Source Validation to Completions
Section 6.12.1.1 of the PCI Express Base Specification 3.1 states that
completions are never affected by ACS Source Validation. However,
completions received by a downstream port of the PCIe switch from a
device that has not yet captured a PCIe bus number are incorrectly
dropped by ACS Source Validation by the switch downstream port.
Workaround: Issue a CfgWr1 to the downstream device before issuing the
first CfgRd1 to the device. This allows the downstream device to capture
its bus number; ACS Source Validation no longer stops completions from
being forwarded by the downstream port. It has been observed that
Microsoft Windows implements this workaround already; however, some
versions of Linux and other operating systems may not.
When doing the first config read to probe for a device, if the device is
behind an IDT switch with this erratum:
1. Disable ACS Source Validation if enabled
2. Wait for device to become ready to accept config accesses (by using
the Config Request Retry Status mechanism)
3. Do a config write to the endpoint
4. Enable ACS Source Validation (if it was enabled to begin with)
The workaround suggested by IDT is basically only step 3, but we don't know
when the device is ready to accept config requests. That means we need to
do config reads until we receive a non-Config Request Retry Status, which
means we need to disable ACS SV temporarily.
Signed-off-by: James Puthukattukaran <james.puthukattukaran@oracle.com>
[bhelgaas: changelog, clean up whitespace, fold in unused variable fix
from Anders Roxell <anders.roxell@linaro.org>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2018-07-09 15:31:25 +00:00
|
|
|
bool pci_bus_generic_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
|
|
|
|
|
int crs_timeout);
|
|
|
|
|
int pci_idt_bus_quirk(struct pci_bus *bus, int devfn, u32 *pl, int crs_timeout);
|
|
|
|
|
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_setup_device(struct pci_dev *dev);
|
|
|
|
|
int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
|
|
|
|
|
struct resource *res, unsigned int reg);
|
|
|
|
|
void pci_configure_ari(struct pci_dev *dev);
|
2014-04-14 22:11:40 +00:00
|
|
|
void __pci_bus_size_bridges(struct pci_bus *bus,
|
PCI / ACPI: Use boot-time resource allocation rules during hotplug
On x86 platforms, the kernel respects PCI resource assignments from
the BIOS and only reassigns resources for unassigned BARs at boot
time. However, with the ACPI-based hotplug (acpiphp), it ignores the
BIOS' PCI resource assignments completely and reassigns all resources
by itself. This causes differences in PCI resource allocation
between boot time and runtime hotplug to occur, which is generally
undesirable and sometimes actively breaks things.
Namely, if there are enough resources, reassigning all PCI resources
during runtime hotplug should work, but it may fail if the resources
are constrained. This may happen, for instance, when some PCI
devices with huge MMIO BARs are involved in the runtime hotplug
operations, because the current PCI MMIO alignment algorithm may
waste huge chunks of MMIO address space in those cases.
On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited
MMIO resources for the dock station which contains a device
(graphics adapter) with a 256MB MMIO BAR. An attempt to reassign
that during runtime hotplug causes the dock station MMIO window to be
exhausted and acpiphp fails to allocate resources for the majority
of devices on the dock station as a result.
To prevent that from happening, modify acpiphp to follow the boot
time resources allocation behavior so that the BIOS' resource
assignments are respected during runtime hotplug too.
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=56531
Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com>
Tested-by: Illya Klymov <xanf@xanf.me>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-22 23:01:35 +00:00
|
|
|
struct list_head *realloc_head);
|
2014-04-14 22:11:40 +00:00
|
|
|
void __pci_bus_assign_resources(const struct pci_bus *bus,
|
|
|
|
|
struct list_head *realloc_head,
|
|
|
|
|
struct list_head *fail_head);
|
2015-01-15 22:21:49 +00:00
|
|
|
bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
|
2013-01-27 00:35:58 +00:00
|
|
|
|
2012-02-16 05:40:31 +00:00
|
|
|
void pci_reassigndev_resource_alignment(struct pci_dev *dev);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_disable_bridge_window(struct pci_dev *dev);
|
2019-07-24 23:38:43 +00:00
|
|
|
struct pci_bus *pci_bus_get(struct pci_bus *bus);
|
|
|
|
|
void pci_bus_put(struct pci_bus *bus);
|
2009-03-16 08:13:39 +00:00
|
|
|
|
2020-02-17 11:13:03 +00:00
|
|
|
/* PCIe link information from Link Capabilities 2 */
|
|
|
|
|
#define PCIE_LNKCAP2_SLS2SPEED(lnkcap2) \
|
2020-11-18 22:49:20 +00:00
|
|
|
((lnkcap2) & PCI_EXP_LNKCAP2_SLS_64_0GB ? PCIE_SPEED_64_0GT : \
|
|
|
|
|
(lnkcap2) & PCI_EXP_LNKCAP2_SLS_32_0GB ? PCIE_SPEED_32_0GT : \
|
2020-02-17 11:13:03 +00:00
|
|
|
(lnkcap2) & PCI_EXP_LNKCAP2_SLS_16_0GB ? PCIE_SPEED_16_0GT : \
|
|
|
|
|
(lnkcap2) & PCI_EXP_LNKCAP2_SLS_8_0GB ? PCIE_SPEED_8_0GT : \
|
|
|
|
|
(lnkcap2) & PCI_EXP_LNKCAP2_SLS_5_0GB ? PCIE_SPEED_5_0GT : \
|
|
|
|
|
(lnkcap2) & PCI_EXP_LNKCAP2_SLS_2_5GB ? PCIE_SPEED_2_5GT : \
|
|
|
|
|
PCI_SPEED_UNKNOWN)
|
2018-03-30 12:44:05 +00:00
|
|
|
|
2018-03-30 13:32:03 +00:00
|
|
|
/* PCIe speed to Mb/s reduced by encoding overhead */
|
|
|
|
|
#define PCIE_SPEED2MBS_ENC(speed) \
|
2020-11-18 22:49:20 +00:00
|
|
|
((speed) == PCIE_SPEED_64_0GT ? 64000*128/130 : \
|
|
|
|
|
(speed) == PCIE_SPEED_32_0GT ? 32000*128/130 : \
|
2020-02-17 11:12:55 +00:00
|
|
|
(speed) == PCIE_SPEED_16_0GT ? 16000*128/130 : \
|
2018-03-30 13:32:03 +00:00
|
|
|
(speed) == PCIE_SPEED_8_0GT ? 8000*128/130 : \
|
|
|
|
|
(speed) == PCIE_SPEED_5_0GT ? 5000*8/10 : \
|
|
|
|
|
(speed) == PCIE_SPEED_2_5GT ? 2500*8/10 : \
|
|
|
|
|
0)
|
|
|
|
|
|
2020-02-28 21:02:03 +00:00
|
|
|
const char *pci_speed_string(enum pci_bus_speed speed);
|
2018-03-30 12:44:05 +00:00
|
|
|
enum pci_bus_speed pcie_get_speed_cap(struct pci_dev *dev);
|
2018-03-30 13:24:36 +00:00
|
|
|
enum pcie_link_width pcie_get_width_cap(struct pci_dev *dev);
|
2018-03-30 13:32:03 +00:00
|
|
|
u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
|
|
|
|
|
enum pcie_link_width *width);
|
2018-08-06 23:25:35 +00:00
|
|
|
void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
|
2019-03-20 11:05:30 +00:00
|
|
|
void pcie_report_downtraining(struct pci_dev *dev);
|
2019-07-24 23:38:44 +00:00
|
|
|
void pcie_update_link_speed(struct pci_bus *bus, u16 link_status);
|
2018-03-30 12:44:05 +00:00
|
|
|
|
2009-03-20 03:25:11 +00:00
|
|
|
/* Single Root I/O Virtualization */
|
|
|
|
|
struct pci_sriov {
|
2017-12-02 19:21:37 +00:00
|
|
|
int pos; /* Capability position */
|
|
|
|
|
int nres; /* Number of resources */
|
|
|
|
|
u32 cap; /* SR-IOV Capabilities */
|
|
|
|
|
u16 ctrl; /* SR-IOV Control */
|
|
|
|
|
u16 total_VFs; /* Total VFs associated with the PF */
|
|
|
|
|
u16 initial_VFs; /* Initial VFs associated with the PF */
|
|
|
|
|
u16 num_VFs; /* Number of VFs available */
|
|
|
|
|
u16 offset; /* First VF Routing ID offset */
|
|
|
|
|
u16 stride; /* Following VF stride */
|
|
|
|
|
u16 vf_device; /* VF device ID */
|
|
|
|
|
u32 pgsz; /* Page size for BAR alignment */
|
|
|
|
|
u8 link; /* Function Dependency Link */
|
|
|
|
|
u8 max_VF_buses; /* Max buses consumed by VFs */
|
|
|
|
|
u16 driver_max_VFs; /* Max num VFs driver supports */
|
|
|
|
|
struct pci_dev *dev; /* Lowest numbered PF */
|
|
|
|
|
struct pci_dev *self; /* This PF */
|
2018-03-19 20:06:00 +00:00
|
|
|
u32 class; /* VF device */
|
|
|
|
|
u8 hdr_type; /* VF header type */
|
|
|
|
|
u16 subsystem_vendor; /* VF subsystem vendor */
|
|
|
|
|
u16 subsystem_device; /* VF subsystem device */
|
2017-12-02 19:21:37 +00:00
|
|
|
resource_size_t barsz[PCI_SRIOV_NUM_BARS]; /* VF BAR size */
|
|
|
|
|
bool drivers_autoprobe; /* Auto probing of VFs by driver */
|
2009-03-20 03:25:11 +00:00
|
|
|
};
|
|
|
|
|
|
2018-09-20 16:27:16 +00:00
|
|
|
/**
|
|
|
|
|
* pci_dev_set_io_state - Set the new error state if possible.
|
|
|
|
|
*
|
2021-07-03 15:13:02 +00:00
|
|
|
* @dev: PCI device to set new error_state
|
|
|
|
|
* @new: the state we want dev to be in
|
2018-09-20 16:27:16 +00:00
|
|
|
*
|
|
|
|
|
* Must be called with device_lock held.
|
|
|
|
|
*
|
|
|
|
|
* Returns true if state has been changed to the requested state.
|
|
|
|
|
*/
|
|
|
|
|
static inline bool pci_dev_set_io_state(struct pci_dev *dev,
|
|
|
|
|
pci_channel_state_t new)
|
|
|
|
|
{
|
|
|
|
|
bool changed = false;
|
|
|
|
|
|
|
|
|
|
device_lock_assert(&dev->dev);
|
|
|
|
|
switch (new) {
|
|
|
|
|
case pci_channel_io_perm_failure:
|
|
|
|
|
switch (dev->error_state) {
|
|
|
|
|
case pci_channel_io_frozen:
|
|
|
|
|
case pci_channel_io_normal:
|
|
|
|
|
case pci_channel_io_perm_failure:
|
|
|
|
|
changed = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case pci_channel_io_frozen:
|
|
|
|
|
switch (dev->error_state) {
|
|
|
|
|
case pci_channel_io_frozen:
|
|
|
|
|
case pci_channel_io_normal:
|
|
|
|
|
changed = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case pci_channel_io_normal:
|
|
|
|
|
switch (dev->error_state) {
|
|
|
|
|
case pci_channel_io_frozen:
|
|
|
|
|
case pci_channel_io_normal:
|
|
|
|
|
changed = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (changed)
|
|
|
|
|
dev->error_state = new;
|
|
|
|
|
return changed;
|
|
|
|
|
}
|
2017-03-30 03:48:59 +00:00
|
|
|
|
|
|
|
|
static inline int pci_dev_set_disconnected(struct pci_dev *dev, void *unused)
|
|
|
|
|
{
|
2018-09-20 16:27:16 +00:00
|
|
|
device_lock(&dev->dev);
|
|
|
|
|
pci_dev_set_io_state(dev, pci_channel_io_perm_failure);
|
|
|
|
|
device_unlock(&dev->dev);
|
|
|
|
|
|
2017-03-30 03:48:59 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool pci_dev_is_disconnected(const struct pci_dev *dev)
|
|
|
|
|
{
|
2018-09-20 16:27:16 +00:00
|
|
|
return dev->error_state == pci_channel_io_perm_failure;
|
2017-03-30 03:48:59 +00:00
|
|
|
}
|
|
|
|
|
|
2018-09-20 16:27:16 +00:00
|
|
|
/* pci_dev priv_flags */
|
|
|
|
|
#define PCI_DEV_ADDED 0
|
PCI: pciehp: Ignore Link Down/Up caused by DPC
Downstream Port Containment (PCIe r5.0, sec. 6.2.10) disables the link upon
an error and attempts to re-enable it when instructed by the DPC driver.
A slot which is both DPC- and hotplug-capable is currently powered off by
pciehp once DPC is triggered (due to the link change) and powered back up
on successful recovery. That's undesirable, the slot should remain powered
so the hotplugged device remains bound to its driver. DPC notifies the
driver of the error and of successful recovery in pcie_do_recovery() and
the driver may then restore the device to working state.
Moreover, Sinan points out that turning off slot power by pciehp may foil
recovery by DPC: Power off/on is a cold reset concurrently to DPC's warm
reset. Sathyanarayanan reports extended delays or failure in link
retraining by DPC if pciehp brings down the slot.
Fix by detecting whether a Link Down event is caused by DPC and awaiting
recovery if so. On successful recovery, ignore both the Link Down and the
subsequent Link Up event.
Afterwards, check whether the link is down to detect surprise-removal or
another DPC event immediately after DPC recovery. Ensure that the
corresponding DLLSC event is not ignored by synthesizing it and invoking
irq_wake_thread() to trigger a re-run of pciehp_ist().
The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and
dpc_handler(), race against each other. If pciehp is faster than DPC, it
will wait until DPC recovery completes.
Recovery consists of two steps: The first step (waiting for link
disablement) is recognizable by pciehp through a set DPC Trigger Status
bit. The second step (waiting for link retraining) is recognizable through
a newly introduced PCI_DPC_RECOVERING flag.
If DPC is faster than pciehp, neither of the two flags will be set and
pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag.
The flag is zero if DPC didn't occur at all, hence DLLSC events are not
ignored by default.
pciehp waits up to 4 seconds before assuming that DPC recovery failed and
bringing down the slot. This timeout is not taken from the spec (it
doesn't mandate one) but based on a report from Yicong Yang that DPC may
take a bit more than 3 seconds on HiSilicon's Kunpeng platform.
The timeout is necessary because the DPC Trigger Status bit may never
clear: On Root Ports which support RP Extensions for DPC, the DPC driver
polls the DPC RP Busy bit for up to 1 second before giving up on DPC
recovery. Without the timeout, pciehp would then wait indefinitely for DPC
to complete.
This commit draws inspiration from previous attempts to synchronize DPC
with pciehp:
By Sinan Kaya, August 2018:
https://lore.kernel.org/linux-pci/20180818065126.77912-1-okaya@kernel.org/
By Ethan Zhao, October 2020:
https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.zhao@intel.com/
By Kuppuswamy Sathyanarayanan, March 2021:
https://lore.kernel.org/linux-pci/59cb30f5e5ac6d65427ceaadf1012b2ba8dbf66c.1615606143.git.sathyanarayanan.kuppuswamy@linux.intel.com/
Link: https://lore.kernel.org/r/0be565d97438fe2a6d57354b3aa4e8626952a00b.1619857124.git.lukas@wunner.de
Reported-by: Sinan Kaya <okaya@kernel.org>
Reported-by: Ethan Zhao <haifeng.zhao@intel.com>
Reported-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Keith Busch <kbusch@kernel.org>
2021-05-01 08:29:00 +00:00
|
|
|
#define PCI_DPC_RECOVERED 1
|
|
|
|
|
#define PCI_DPC_RECOVERING 2
|
2018-09-20 16:27:16 +00:00
|
|
|
|
2018-07-03 09:05:41 +00:00
|
|
|
static inline void pci_dev_assign_added(struct pci_dev *dev, bool added)
|
|
|
|
|
{
|
|
|
|
|
assign_bit(PCI_DEV_ADDED, &dev->priv_flags, added);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool pci_dev_is_added(const struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
return test_bit(PCI_DEV_ADDED, &dev->priv_flags);
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-19 21:16:55 +00:00
|
|
|
#ifdef CONFIG_PCIEAER
|
|
|
|
|
#include <linux/aer.h>
|
|
|
|
|
|
|
|
|
|
#define AER_MAX_MULTI_ERR_DEVICES 5 /* Not likely to have more */
|
|
|
|
|
|
|
|
|
|
struct aer_err_info {
|
|
|
|
|
struct pci_dev *dev[AER_MAX_MULTI_ERR_DEVICES];
|
|
|
|
|
int error_dev_num;
|
|
|
|
|
|
|
|
|
|
unsigned int id:16;
|
|
|
|
|
|
|
|
|
|
unsigned int severity:2; /* 0:NONFATAL | 1:FATAL | 2:COR */
|
|
|
|
|
unsigned int __pad1:5;
|
|
|
|
|
unsigned int multi_error_valid:1;
|
|
|
|
|
|
|
|
|
|
unsigned int first_error:5;
|
|
|
|
|
unsigned int __pad2:2;
|
|
|
|
|
unsigned int tlp_header_valid:1;
|
|
|
|
|
|
|
|
|
|
unsigned int status; /* COR/UNCOR Error Status */
|
|
|
|
|
unsigned int mask; /* COR/UNCOR Error Mask */
|
|
|
|
|
struct aer_header_log_regs tlp; /* TLP Header */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int aer_get_device_error_info(struct pci_dev *dev, struct aer_err_info *info);
|
|
|
|
|
void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
|
|
|
|
|
#endif /* CONFIG_PCIEAER */
|
|
|
|
|
|
2020-11-21 00:10:24 +00:00
|
|
|
#ifdef CONFIG_PCIEPORTBUS
|
|
|
|
|
/* Cached RCEC Endpoint Association */
|
|
|
|
|
struct rcec_ea {
|
|
|
|
|
u8 nextbusn;
|
|
|
|
|
u8 lastbusn;
|
|
|
|
|
u32 bitmap;
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-09-20 16:27:08 +00:00
|
|
|
#ifdef CONFIG_PCIE_DPC
|
|
|
|
|
void pci_save_dpc_state(struct pci_dev *dev);
|
|
|
|
|
void pci_restore_dpc_state(struct pci_dev *dev);
|
2020-03-24 00:26:04 +00:00
|
|
|
void pci_dpc_init(struct pci_dev *pdev);
|
PCI/DPC: Expose dpc_process_error(), dpc_reset_link() for use by EDR
If firmware controls DPC, it is generally responsible for managing the DPC
capability and events, and the OS should not access the DPC capability.
However, if firmware controls DPC and both the OS and the platform support
Error Disconnect Recover (EDR) notifications, the OS EDR notify handler is
responsible for recovery, and the notify handler may read/write the DPC
capability until it clears the DPC Trigger Status bit. See [1], sec 4.5.1,
table 4-6.
Expose some DPC error handling functions so they can be used by the EDR
notify handler.
[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
Link: https://lore.kernel.org/r/e9000bb15b3a4293e81d98bb29ead7c84a6393c9.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>
2020-03-24 00:26:06 +00:00
|
|
|
void dpc_process_error(struct pci_dev *pdev);
|
|
|
|
|
pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
|
PCI: pciehp: Ignore Link Down/Up caused by DPC
Downstream Port Containment (PCIe r5.0, sec. 6.2.10) disables the link upon
an error and attempts to re-enable it when instructed by the DPC driver.
A slot which is both DPC- and hotplug-capable is currently powered off by
pciehp once DPC is triggered (due to the link change) and powered back up
on successful recovery. That's undesirable, the slot should remain powered
so the hotplugged device remains bound to its driver. DPC notifies the
driver of the error and of successful recovery in pcie_do_recovery() and
the driver may then restore the device to working state.
Moreover, Sinan points out that turning off slot power by pciehp may foil
recovery by DPC: Power off/on is a cold reset concurrently to DPC's warm
reset. Sathyanarayanan reports extended delays or failure in link
retraining by DPC if pciehp brings down the slot.
Fix by detecting whether a Link Down event is caused by DPC and awaiting
recovery if so. On successful recovery, ignore both the Link Down and the
subsequent Link Up event.
Afterwards, check whether the link is down to detect surprise-removal or
another DPC event immediately after DPC recovery. Ensure that the
corresponding DLLSC event is not ignored by synthesizing it and invoking
irq_wake_thread() to trigger a re-run of pciehp_ist().
The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and
dpc_handler(), race against each other. If pciehp is faster than DPC, it
will wait until DPC recovery completes.
Recovery consists of two steps: The first step (waiting for link
disablement) is recognizable by pciehp through a set DPC Trigger Status
bit. The second step (waiting for link retraining) is recognizable through
a newly introduced PCI_DPC_RECOVERING flag.
If DPC is faster than pciehp, neither of the two flags will be set and
pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag.
The flag is zero if DPC didn't occur at all, hence DLLSC events are not
ignored by default.
pciehp waits up to 4 seconds before assuming that DPC recovery failed and
bringing down the slot. This timeout is not taken from the spec (it
doesn't mandate one) but based on a report from Yicong Yang that DPC may
take a bit more than 3 seconds on HiSilicon's Kunpeng platform.
The timeout is necessary because the DPC Trigger Status bit may never
clear: On Root Ports which support RP Extensions for DPC, the DPC driver
polls the DPC RP Busy bit for up to 1 second before giving up on DPC
recovery. Without the timeout, pciehp would then wait indefinitely for DPC
to complete.
This commit draws inspiration from previous attempts to synchronize DPC
with pciehp:
By Sinan Kaya, August 2018:
https://lore.kernel.org/linux-pci/20180818065126.77912-1-okaya@kernel.org/
By Ethan Zhao, October 2020:
https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.zhao@intel.com/
By Kuppuswamy Sathyanarayanan, March 2021:
https://lore.kernel.org/linux-pci/59cb30f5e5ac6d65427ceaadf1012b2ba8dbf66c.1615606143.git.sathyanarayanan.kuppuswamy@linux.intel.com/
Link: https://lore.kernel.org/r/0be565d97438fe2a6d57354b3aa4e8626952a00b.1619857124.git.lukas@wunner.de
Reported-by: Sinan Kaya <okaya@kernel.org>
Reported-by: Ethan Zhao <haifeng.zhao@intel.com>
Reported-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Keith Busch <kbusch@kernel.org>
2021-05-01 08:29:00 +00:00
|
|
|
bool pci_dpc_recovered(struct pci_dev *pdev);
|
2018-09-20 16:27:08 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_save_dpc_state(struct pci_dev *dev) {}
|
|
|
|
|
static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
|
2020-03-24 00:26:04 +00:00
|
|
|
static inline void pci_dpc_init(struct pci_dev *pdev) {}
|
PCI: pciehp: Ignore Link Down/Up caused by DPC
Downstream Port Containment (PCIe r5.0, sec. 6.2.10) disables the link upon
an error and attempts to re-enable it when instructed by the DPC driver.
A slot which is both DPC- and hotplug-capable is currently powered off by
pciehp once DPC is triggered (due to the link change) and powered back up
on successful recovery. That's undesirable, the slot should remain powered
so the hotplugged device remains bound to its driver. DPC notifies the
driver of the error and of successful recovery in pcie_do_recovery() and
the driver may then restore the device to working state.
Moreover, Sinan points out that turning off slot power by pciehp may foil
recovery by DPC: Power off/on is a cold reset concurrently to DPC's warm
reset. Sathyanarayanan reports extended delays or failure in link
retraining by DPC if pciehp brings down the slot.
Fix by detecting whether a Link Down event is caused by DPC and awaiting
recovery if so. On successful recovery, ignore both the Link Down and the
subsequent Link Up event.
Afterwards, check whether the link is down to detect surprise-removal or
another DPC event immediately after DPC recovery. Ensure that the
corresponding DLLSC event is not ignored by synthesizing it and invoking
irq_wake_thread() to trigger a re-run of pciehp_ist().
The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and
dpc_handler(), race against each other. If pciehp is faster than DPC, it
will wait until DPC recovery completes.
Recovery consists of two steps: The first step (waiting for link
disablement) is recognizable by pciehp through a set DPC Trigger Status
bit. The second step (waiting for link retraining) is recognizable through
a newly introduced PCI_DPC_RECOVERING flag.
If DPC is faster than pciehp, neither of the two flags will be set and
pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag.
The flag is zero if DPC didn't occur at all, hence DLLSC events are not
ignored by default.
pciehp waits up to 4 seconds before assuming that DPC recovery failed and
bringing down the slot. This timeout is not taken from the spec (it
doesn't mandate one) but based on a report from Yicong Yang that DPC may
take a bit more than 3 seconds on HiSilicon's Kunpeng platform.
The timeout is necessary because the DPC Trigger Status bit may never
clear: On Root Ports which support RP Extensions for DPC, the DPC driver
polls the DPC RP Busy bit for up to 1 second before giving up on DPC
recovery. Without the timeout, pciehp would then wait indefinitely for DPC
to complete.
This commit draws inspiration from previous attempts to synchronize DPC
with pciehp:
By Sinan Kaya, August 2018:
https://lore.kernel.org/linux-pci/20180818065126.77912-1-okaya@kernel.org/
By Ethan Zhao, October 2020:
https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.zhao@intel.com/
By Kuppuswamy Sathyanarayanan, March 2021:
https://lore.kernel.org/linux-pci/59cb30f5e5ac6d65427ceaadf1012b2ba8dbf66c.1615606143.git.sathyanarayanan.kuppuswamy@linux.intel.com/
Link: https://lore.kernel.org/r/0be565d97438fe2a6d57354b3aa4e8626952a00b.1619857124.git.lukas@wunner.de
Reported-by: Sinan Kaya <okaya@kernel.org>
Reported-by: Ethan Zhao <haifeng.zhao@intel.com>
Reported-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Keith Busch <kbusch@kernel.org>
2021-05-01 08:29:00 +00:00
|
|
|
static inline bool pci_dpc_recovered(struct pci_dev *pdev) { return false; }
|
2018-09-20 16:27:08 +00:00
|
|
|
#endif
|
|
|
|
|
|
2020-11-21 00:10:24 +00:00
|
|
|
#ifdef CONFIG_PCIEPORTBUS
|
|
|
|
|
void pci_rcec_init(struct pci_dev *dev);
|
|
|
|
|
void pci_rcec_exit(struct pci_dev *dev);
|
2020-11-21 00:10:32 +00:00
|
|
|
void pcie_link_rcec(struct pci_dev *rcec);
|
2020-11-21 00:10:34 +00:00
|
|
|
void pcie_walk_rcec(struct pci_dev *rcec,
|
|
|
|
|
int (*cb)(struct pci_dev *, void *),
|
|
|
|
|
void *userdata);
|
2020-11-21 00:10:24 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_rcec_init(struct pci_dev *dev) {}
|
|
|
|
|
static inline void pci_rcec_exit(struct pci_dev *dev) {}
|
2020-11-21 00:10:32 +00:00
|
|
|
static inline void pcie_link_rcec(struct pci_dev *rcec) {}
|
2020-11-21 00:10:34 +00:00
|
|
|
static inline void pcie_walk_rcec(struct pci_dev *rcec,
|
|
|
|
|
int (*cb)(struct pci_dev *, void *),
|
|
|
|
|
void *userdata) {}
|
2020-11-21 00:10:24 +00:00
|
|
|
#endif
|
|
|
|
|
|
2011-12-17 13:24:40 +00:00
|
|
|
#ifdef CONFIG_PCI_ATS
|
2019-07-24 23:38:45 +00:00
|
|
|
/* Address Translation Service */
|
|
|
|
|
void pci_ats_init(struct pci_dev *dev);
|
2013-04-12 18:02:59 +00:00
|
|
|
void pci_restore_ats_state(struct pci_dev *dev);
|
2011-12-17 13:24:40 +00:00
|
|
|
#else
|
2019-07-24 23:38:45 +00:00
|
|
|
static inline void pci_ats_init(struct pci_dev *d) { }
|
|
|
|
|
static inline void pci_restore_ats_state(struct pci_dev *dev) { }
|
2011-12-17 13:24:40 +00:00
|
|
|
#endif /* CONFIG_PCI_ATS */
|
|
|
|
|
|
2019-09-05 19:31:45 +00:00
|
|
|
#ifdef CONFIG_PCI_PRI
|
|
|
|
|
void pci_pri_init(struct pci_dev *dev);
|
2019-10-09 21:47:15 +00:00
|
|
|
void pci_restore_pri_state(struct pci_dev *pdev);
|
2019-09-05 19:31:45 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_pri_init(struct pci_dev *dev) { }
|
2019-10-09 21:47:15 +00:00
|
|
|
static inline void pci_restore_pri_state(struct pci_dev *pdev) { }
|
2019-09-05 19:31:45 +00:00
|
|
|
#endif
|
|
|
|
|
|
2019-09-05 19:31:46 +00:00
|
|
|
#ifdef CONFIG_PCI_PASID
|
|
|
|
|
void pci_pasid_init(struct pci_dev *dev);
|
2019-10-09 21:47:15 +00:00
|
|
|
void pci_restore_pasid_state(struct pci_dev *pdev);
|
2019-09-05 19:31:46 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_pasid_init(struct pci_dev *dev) { }
|
2019-10-09 21:47:15 +00:00
|
|
|
static inline void pci_restore_pasid_state(struct pci_dev *pdev) { }
|
2019-09-05 19:31:46 +00:00
|
|
|
#endif
|
|
|
|
|
|
2009-03-20 03:25:11 +00:00
|
|
|
#ifdef CONFIG_PCI_IOV
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_iov_init(struct pci_dev *dev);
|
|
|
|
|
void pci_iov_release(struct pci_dev *dev);
|
PCI/IOV: Reset total_VFs limit after detaching PF driver
The TotalVFs register in the SR-IOV capability is the hardware limit on the
number of VFs. A PF driver can limit the number of VFs further with
pci_sriov_set_totalvfs(). When the PF driver is removed, reset any VF
limit that was imposed by the driver because that limit may not apply to
other drivers.
Before 8d85a7a4f2c9 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0"),
pci_sriov_set_totalvfs(pdev, 0) meant "we can enable TotalVFs virtual
functions", and the nfp driver used that to remove the VF limit when the
driver unloads.
8d85a7a4f2c9 broke that because instead of removing the VF limit,
pci_sriov_set_totalvfs(pdev, 0) actually sets the limit to zero, and that
limit persists even if another driver is loaded.
We could fix that by making the nfp driver reset the limit when it unloads,
but it seems more robust to do it in the PCI core instead of relying on the
driver.
The regression scenario is:
nfp_pci_probe (driver 1)
...
nfp_pci_remove
pci_sriov_set_totalvfs(pf->pdev, 0) # limits VFs to 0
...
nfp_pci_probe (driver 2)
nfp_rtsym_read_le("nfd_vf_cfg_max_vfs")
# no VF limit from firmware
Now driver 2 is broken because the VF limit is still 0 from driver 1.
Fixes: 8d85a7a4f2c9 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
[bhelgaas: changelog, rename functions]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-29 20:08:52 +00:00
|
|
|
void pci_iov_remove(struct pci_dev *dev);
|
2016-11-28 15:15:52 +00:00
|
|
|
void pci_iov_update_resource(struct pci_dev *dev, int resno);
|
2013-04-12 18:02:59 +00:00
|
|
|
resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno);
|
|
|
|
|
void pci_restore_iov_state(struct pci_dev *dev);
|
|
|
|
|
int pci_iov_bus_range(struct pci_bus *bus);
|
2021-04-04 07:22:18 +00:00
|
|
|
extern const struct attribute_group sriov_pf_dev_attr_group;
|
|
|
|
|
extern const struct attribute_group sriov_vf_dev_attr_group;
|
2009-03-20 03:25:11 +00:00
|
|
|
#else
|
|
|
|
|
static inline int pci_iov_init(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
static inline void pci_iov_release(struct pci_dev *dev)
|
|
|
|
|
|
PCI/IOV: Reset total_VFs limit after detaching PF driver
The TotalVFs register in the SR-IOV capability is the hardware limit on the
number of VFs. A PF driver can limit the number of VFs further with
pci_sriov_set_totalvfs(). When the PF driver is removed, reset any VF
limit that was imposed by the driver because that limit may not apply to
other drivers.
Before 8d85a7a4f2c9 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0"),
pci_sriov_set_totalvfs(pdev, 0) meant "we can enable TotalVFs virtual
functions", and the nfp driver used that to remove the VF limit when the
driver unloads.
8d85a7a4f2c9 broke that because instead of removing the VF limit,
pci_sriov_set_totalvfs(pdev, 0) actually sets the limit to zero, and that
limit persists even if another driver is loaded.
We could fix that by making the nfp driver reset the limit when it unloads,
but it seems more robust to do it in the PCI core instead of relying on the
driver.
The regression scenario is:
nfp_pci_probe (driver 1)
...
nfp_pci_remove
pci_sriov_set_totalvfs(pf->pdev, 0) # limits VFs to 0
...
nfp_pci_probe (driver 2)
nfp_rtsym_read_le("nfd_vf_cfg_max_vfs")
# no VF limit from firmware
Now driver 2 is broken because the VF limit is still 0 from driver 1.
Fixes: 8d85a7a4f2c9 ("PCI/IOV: Allow PF drivers to limit total_VFs to 0")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
[bhelgaas: changelog, rename functions]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-29 20:08:52 +00:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
static inline void pci_iov_remove(struct pci_dev *dev)
|
2009-03-20 03:25:11 +00:00
|
|
|
{
|
|
|
|
|
}
|
2009-03-20 03:25:12 +00:00
|
|
|
static inline void pci_restore_iov_state(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
}
|
2009-03-20 03:25:13 +00:00
|
|
|
static inline int pci_iov_bus_range(struct pci_bus *bus)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-05-18 05:51:32 +00:00
|
|
|
|
2009-03-20 03:25:11 +00:00
|
|
|
#endif /* CONFIG_PCI_IOV */
|
|
|
|
|
|
2020-12-07 22:39:50 +00:00
|
|
|
#ifdef CONFIG_PCIE_PTM
|
|
|
|
|
void pci_save_ptm_state(struct pci_dev *dev);
|
|
|
|
|
void pci_restore_ptm_state(struct pci_dev *dev);
|
2020-12-07 22:39:51 +00:00
|
|
|
void pci_disable_ptm(struct pci_dev *dev);
|
2020-12-07 22:39:50 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_save_ptm_state(struct pci_dev *dev) { }
|
|
|
|
|
static inline void pci_restore_ptm_state(struct pci_dev *dev) { }
|
2020-12-07 22:39:51 +00:00
|
|
|
static inline void pci_disable_ptm(struct pci_dev *dev) { }
|
2020-12-07 22:39:50 +00:00
|
|
|
#endif
|
|
|
|
|
|
2013-04-12 18:02:59 +00:00
|
|
|
unsigned long pci_cardbus_resource_alignment(struct resource *);
|
2011-07-25 20:08:41 +00:00
|
|
|
|
2010-09-08 00:25:20 +00:00
|
|
|
static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
|
2013-04-12 18:02:59 +00:00
|
|
|
struct resource *res)
|
2009-08-28 20:00:06 +00:00
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_PCI_IOV
|
|
|
|
|
int resno = res - dev->resource;
|
|
|
|
|
|
|
|
|
|
if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END)
|
|
|
|
|
return pci_sriov_resource_alignment(dev, resno);
|
|
|
|
|
#endif
|
2017-12-02 19:21:37 +00:00
|
|
|
if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS)
|
2011-07-25 20:08:41 +00:00
|
|
|
return pci_cardbus_resource_alignment(res);
|
2009-08-28 20:00:06 +00:00
|
|
|
return resource_alignment(res);
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-07 22:46:02 +00:00
|
|
|
void pci_acs_init(struct pci_dev *dev);
|
2018-08-09 21:19:52 +00:00
|
|
|
#ifdef CONFIG_PCI_QUIRKS
|
|
|
|
|
int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
|
|
|
|
|
int pci_dev_specific_enable_acs(struct pci_dev *dev);
|
2018-08-09 21:51:43 +00:00
|
|
|
int pci_dev_specific_disable_acs_redir(struct pci_dev *dev);
|
2018-08-09 21:19:52 +00:00
|
|
|
#else
|
|
|
|
|
static inline int pci_dev_specific_acs_enabled(struct pci_dev *dev,
|
|
|
|
|
u16 acs_flags)
|
|
|
|
|
{
|
|
|
|
|
return -ENOTTY;
|
|
|
|
|
}
|
|
|
|
|
static inline int pci_dev_specific_enable_acs(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENOTTY;
|
|
|
|
|
}
|
2018-08-09 21:51:43 +00:00
|
|
|
static inline int pci_dev_specific_disable_acs_redir(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENOTTY;
|
|
|
|
|
}
|
2018-08-09 21:19:52 +00:00
|
|
|
#endif
|
2009-10-07 17:27:17 +00:00
|
|
|
|
2018-05-17 21:44:15 +00:00
|
|
|
/* PCI error reporting and recovery */
|
PCI/ERR: Return status of pcie_do_recovery()
As per the DPC Enhancements ECN [1], sec 4.5.1, table 4-4, if the OS
supports Error Disconnect Recover (EDR), it must invalidate the software
state associated with child devices of the port without attempting to
access the child device hardware. In addition, if the OS supports DPC, it
must attempt to recover the child devices if the port implements the DPC
Capability. If the OS continues operation, the OS must inform the firmware
of the status of the recovery operation via the _OST method.
Return the result of pcie_do_recovery() so we can report it to firmware via
_OST.
[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
Link: https://lore.kernel.org/r/eb60ec89448769349c6722954ffbf2de163155b5.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>
2020-03-24 00:26:03 +00:00
|
|
|
pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
|
2020-11-21 00:10:25 +00:00
|
|
|
pci_channel_state_t state,
|
|
|
|
|
pci_ers_result_t (*reset_subordinates)(struct pci_dev *pdev));
|
2018-05-17 21:44:15 +00:00
|
|
|
|
2018-05-17 21:44:11 +00:00
|
|
|
bool pcie_wait_for_link(struct pci_dev *pdev, bool active);
|
2017-12-15 14:57:28 +00:00
|
|
|
#ifdef CONFIG_PCIEASPM
|
|
|
|
|
void pcie_aspm_init_link_state(struct pci_dev *pdev);
|
|
|
|
|
void pcie_aspm_exit_link_state(struct pci_dev *pdev);
|
|
|
|
|
void pcie_aspm_pm_state_change(struct pci_dev *pdev);
|
|
|
|
|
void pcie_aspm_powersave_config_link(struct pci_dev *pdev);
|
|
|
|
|
#else
|
|
|
|
|
static inline void pcie_aspm_init_link_state(struct pci_dev *pdev) { }
|
|
|
|
|
static inline void pcie_aspm_exit_link_state(struct pci_dev *pdev) { }
|
|
|
|
|
static inline void pcie_aspm_pm_state_change(struct pci_dev *pdev) { }
|
|
|
|
|
static inline void pcie_aspm_powersave_config_link(struct pci_dev *pdev) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-07-24 23:38:46 +00:00
|
|
|
#ifdef CONFIG_PCIE_ECRC
|
|
|
|
|
void pcie_set_ecrc_checking(struct pci_dev *dev);
|
|
|
|
|
void pcie_ecrc_get_policy(char *str);
|
|
|
|
|
#else
|
|
|
|
|
static inline void pcie_set_ecrc_checking(struct pci_dev *dev) { }
|
|
|
|
|
static inline void pcie_ecrc_get_policy(char *str) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-06-11 19:13:38 +00:00
|
|
|
#ifdef CONFIG_PCIE_PTM
|
|
|
|
|
void pci_ptm_init(struct pci_dev *dev);
|
2019-07-24 23:38:47 +00:00
|
|
|
int pci_enable_ptm(struct pci_dev *dev, u8 *granularity);
|
2016-06-11 19:13:38 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_ptm_init(struct pci_dev *dev) { }
|
2019-07-24 23:38:47 +00:00
|
|
|
static inline int pci_enable_ptm(struct pci_dev *dev, u8 *granularity)
|
|
|
|
|
{ return -EINVAL; }
|
2016-06-11 19:13:38 +00:00
|
|
|
#endif
|
|
|
|
|
|
2009-12-07 05:03:21 +00:00
|
|
|
struct pci_dev_reset_methods {
|
|
|
|
|
u16 vendor;
|
|
|
|
|
u16 device;
|
|
|
|
|
int (*reset)(struct pci_dev *dev, int probe);
|
|
|
|
|
};
|
|
|
|
|
|
2021-08-17 18:04:54 +00:00
|
|
|
struct pci_reset_fn_method {
|
|
|
|
|
int (*reset_fn)(struct pci_dev *pdev, int probe);
|
|
|
|
|
char *name;
|
|
|
|
|
};
|
|
|
|
|
|
2010-01-02 21:57:24 +00:00
|
|
|
#ifdef CONFIG_PCI_QUIRKS
|
2013-04-12 18:02:59 +00:00
|
|
|
int pci_dev_specific_reset(struct pci_dev *dev, int probe);
|
2010-01-02 21:57:24 +00:00
|
|
|
#else
|
|
|
|
|
static inline int pci_dev_specific_reset(struct pci_dev *dev, int probe)
|
|
|
|
|
{
|
|
|
|
|
return -ENOTTY;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2009-12-07 05:03:21 +00:00
|
|
|
|
2016-12-01 06:33:42 +00:00
|
|
|
#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
|
|
|
|
|
int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment,
|
|
|
|
|
struct resource *res);
|
2021-03-08 15:24:47 +00:00
|
|
|
#else
|
|
|
|
|
static inline int acpi_get_rc_resources(struct device *dev, const char *hid,
|
|
|
|
|
u16 segment, struct resource *res)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2016-12-01 06:33:42 +00:00
|
|
|
#endif
|
|
|
|
|
|
2017-10-24 19:40:20 +00:00
|
|
|
int pci_rebar_get_current_size(struct pci_dev *pdev, int bar);
|
|
|
|
|
int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size);
|
|
|
|
|
static inline u64 pci_rebar_size_to_bytes(int size)
|
|
|
|
|
{
|
|
|
|
|
return 1ULL << (size + 20);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 17:15:30 +00:00
|
|
|
struct device_node;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_OF
|
|
|
|
|
int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
|
|
|
|
|
int of_get_pci_domain_nr(struct device_node *node);
|
|
|
|
|
int of_pci_get_max_link_speed(struct device_node *node);
|
2019-07-24 23:38:48 +00:00
|
|
|
void pci_set_of_node(struct pci_dev *dev);
|
|
|
|
|
void pci_release_of_node(struct pci_dev *dev);
|
|
|
|
|
void pci_set_bus_of_node(struct pci_bus *bus);
|
|
|
|
|
void pci_release_bus_of_node(struct pci_bus *bus);
|
2018-05-11 17:15:30 +00:00
|
|
|
|
2020-07-22 02:25:13 +00:00
|
|
|
int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge *bridge);
|
|
|
|
|
|
2018-05-11 17:15:30 +00:00
|
|
|
#else
|
|
|
|
|
static inline int
|
|
|
|
|
of_pci_parse_bus_range(struct device_node *node, struct resource *res)
|
|
|
|
|
{
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
of_get_pci_domain_nr(struct device_node *node)
|
|
|
|
|
{
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
of_pci_get_max_link_speed(struct device_node *node)
|
|
|
|
|
{
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2019-07-24 23:38:48 +00:00
|
|
|
|
|
|
|
|
static inline void pci_set_of_node(struct pci_dev *dev) { }
|
|
|
|
|
static inline void pci_release_of_node(struct pci_dev *dev) { }
|
|
|
|
|
static inline void pci_set_bus_of_node(struct pci_bus *bus) { }
|
|
|
|
|
static inline void pci_release_bus_of_node(struct pci_bus *bus) { }
|
2020-07-22 02:25:13 +00:00
|
|
|
|
|
|
|
|
static inline int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge *bridge)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 17:15:30 +00:00
|
|
|
#endif /* CONFIG_OF */
|
|
|
|
|
|
2018-06-21 23:48:26 +00:00
|
|
|
#ifdef CONFIG_PCIEAER
|
|
|
|
|
void pci_no_aer(void);
|
|
|
|
|
void pci_aer_init(struct pci_dev *dev);
|
2018-06-30 20:07:17 +00:00
|
|
|
void pci_aer_exit(struct pci_dev *dev);
|
2018-06-21 23:48:28 +00:00
|
|
|
extern const struct attribute_group aer_stats_attr_group;
|
2018-07-19 22:55:58 +00:00
|
|
|
void pci_aer_clear_fatal_status(struct pci_dev *dev);
|
2020-03-24 00:26:08 +00:00
|
|
|
int pci_aer_clear_status(struct pci_dev *dev);
|
PCI/AER: Add pci_aer_raw_clear_status() to unconditionally clear Error Status
Per the SFI _OSC and DPC Updates ECN [1] implementation note flowchart, the
OS seems to be expected to clear AER status even if it doesn't have
ownership of the AER capability. Unlike the DPC capability, where a DPC
ECN [2] specifies a window when the OS is allowed to access DPC registers
even if it doesn't have ownership, there is no clear model for AER.
Add pci_aer_raw_clear_status() to clear the AER error status registers
unconditionally. This is intended for use only by the EDR path (see [2]).
[1] System Firmware Intermediary (SFI) _OSC and DPC Updates ECN, Feb 24,
2020, affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/14076
[2] 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: changelog]
Link: https://lore.kernel.org/r/c19ad28f3633cce67448609e89a75635da0da07d.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>
2020-03-24 00:26:05 +00:00
|
|
|
int pci_aer_raw_clear_status(struct pci_dev *dev);
|
2018-06-21 23:48:26 +00:00
|
|
|
#else
|
|
|
|
|
static inline void pci_no_aer(void) { }
|
2019-04-12 06:43:06 +00:00
|
|
|
static inline void pci_aer_init(struct pci_dev *d) { }
|
2018-06-30 20:07:17 +00:00
|
|
|
static inline void pci_aer_exit(struct pci_dev *d) { }
|
2018-07-19 22:55:58 +00:00
|
|
|
static inline void pci_aer_clear_fatal_status(struct pci_dev *dev) { }
|
2020-03-24 00:26:08 +00:00
|
|
|
static inline int pci_aer_clear_status(struct pci_dev *dev) { return -EINVAL; }
|
PCI/AER: Add pci_aer_raw_clear_status() to unconditionally clear Error Status
Per the SFI _OSC and DPC Updates ECN [1] implementation note flowchart, the
OS seems to be expected to clear AER status even if it doesn't have
ownership of the AER capability. Unlike the DPC capability, where a DPC
ECN [2] specifies a window when the OS is allowed to access DPC registers
even if it doesn't have ownership, there is no clear model for AER.
Add pci_aer_raw_clear_status() to clear the AER error status registers
unconditionally. This is intended for use only by the EDR path (see [2]).
[1] System Firmware Intermediary (SFI) _OSC and DPC Updates ECN, Feb 24,
2020, affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/14076
[2] 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: changelog]
Link: https://lore.kernel.org/r/c19ad28f3633cce67448609e89a75635da0da07d.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>
2020-03-24 00:26:05 +00:00
|
|
|
static inline int pci_aer_raw_clear_status(struct pci_dev *dev) { return -EINVAL; }
|
2018-06-21 23:48:26 +00:00
|
|
|
#endif
|
|
|
|
|
|
2019-08-27 09:49:50 +00:00
|
|
|
#ifdef CONFIG_ACPI
|
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:51 +00:00
|
|
|
int pci_acpi_program_hp_params(struct pci_dev *dev);
|
PCI/sysfs: Convert "index", "acpi_index", "label" to static attributes
The "label", "index", and "acpi_index" sysfs attributes show firmware label
information about the device. If the ACPI Device Name _DSM is implemented
for the device, we have:
label Device name (optional, may be null)
acpi_index Instance number (unique under \_SB scope)
When there is no ACPI _DSM and SMBIOS provides an Onboard Devices structure
for the device, we have:
label Reference Designation, e.g., a silkscreen label
index Device Type Instance
Previously these attributes were dynamically created either by
pci_bus_add_device() or the pci_sysfs_init() initcall, but since they don't
need to be created or removed dynamically, we can use a static attribute so
the device model takes care of addition and removal automatically.
Convert "label", "index", and "acpi_index" to static attributes.
Presence of the ACPI _DSM (device_has_acpi_name()) determines whether the
ACPI information (label, acpi_index) or the SMBIOS information (label,
index) is visible.
[bhelgaas: commit log, split to separate patch, add "pci_dev_" prefix]
Suggested-by: Oliver O'Halloran <oohall@gmail.com>
Link: https://lore.kernel.org/r/20210416205856.3234481-6-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-04-27 15:49:16 +00:00
|
|
|
extern const struct attribute_group pci_dev_acpi_attr_group;
|
2019-08-27 09:49:50 +00:00
|
|
|
#else
|
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:51 +00:00
|
|
|
static inline int pci_acpi_program_hp_params(struct pci_dev *dev)
|
2019-08-27 09:49:50 +00:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-10-05 12:07:56 +00:00
|
|
|
#ifdef CONFIG_PCIEASPM
|
|
|
|
|
extern const struct attribute_group aspm_ctrl_attr_group;
|
|
|
|
|
#endif
|
|
|
|
|
|
2021-08-17 18:04:56 +00:00
|
|
|
extern const struct attribute_group pci_dev_reset_method_attr_group;
|
|
|
|
|
|
2008-10-13 11:18:07 +00:00
|
|
|
#endif /* DRIVERS_PCI_H */
|
