qiurui
/
Centos-kernel-stream-9
mirror of https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Centos-kernel-stream-9/drivers/pci/pci.h

989 lines
31 KiB
C
Raw Normal View History

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 */
PCI: replace cfg space size (256/4096) by macros. This is a cleanup that changes all PCI configuration space size representations to the macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE). And the macros are also moved from drivers/pci/probe.c to drivers/pci/pci.h. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-10-13 11:18:07 +00:00
#ifndef DRIVERS_PCI_H
#define DRIVERS_PCI_H
PCI: Add missing include to drivers/pci.h This file makes use of definitions provided in <linux/pci.h>. This only compiles when <linux/pci.h> is included beforehand, and creates a nasty include dependency. Instead, just include the correct file. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-11-28 22:28:04 +00:00
#include <linux/pci.h>
PCI: Fix pci_add_dma_alias() bitmask size The number of possible devfns is 256, but pci_add_dma_alias() allocated a bitmap of size 255. Fix this off-by-one error. This fixes commits 338c3149a221 ("PCI: Add support for multiple DMA aliases") and c6635792737b ("PCI: Allocate dma_alias_mask with bitmap_zalloc()"), but I doubt it was possible to see a problem because it takes 4 64-bit longs (or 8 32-bit longs) to hold 255 bits, and bitmap_zalloc() doesn't save the 255-bit size anywhere. [bhelgaas: commit log, move #define to drivers/pci/pci.h, include loop limit fix from Qian Cai: https://lore.kernel.org/r/20191218170004.5297-1-cai@lca.pw] Signed-off-by: James Sewart <jamessewart@arista.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-12-10 21:51:33 +00:00
/* Number of possible devfns: 0.0 to 1f.7 inclusive */
#define MAX_NR_DEVFNS 256
PCI: Move PCI_FIND_CAP_TTL to pci.h and use it in quirks Some quirks search for a HyperTransport capability and use a hard-coded TTL value of 48 to avoid an infinite loop. Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the hard-coded TTL values. [bhelgaas: changelog] Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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 */
PCI: Export PCIe link retrain timeout JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: 33a176abcc4cd4ed3d65512ed96d7b73f2565ed7 commit 33a176abcc4cd4ed3d65512ed96d7b73f2565ed7 Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Sun Jun 11 18:19:19 2023 +0100 PCI: Export PCIe link retrain timeout Convert LINK_RETRAIN_TIMEOUT from jiffies to milliseconds, accordingly rename to PCIE_LINK_RETRAIN_TIMEOUT_MS, and make available via "pci.h" for the PCI core to use. Use in pcie_wait_for_link_delay(). Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310030280.59226@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:19 +00:00
#define PCIE_LINK_RETRAIN_TIMEOUT_MS 1000
PCI: Add T_PERST_CLK_US macro JIRA: https://issues.redhat.com/browse/RHEL-67693 Upstream Status: 6aa9c09f1bcd339749b249830c604871740df268 commit 6aa9c09f1bcd339749b249830c604871740df268 Author: Thomas Richard <thomas.richard@bootlin.com> Date: Wed Jun 19 12:15:13 2024 +0200 PCI: Add T_PERST_CLK_US macro The "Power Sequencing and Reset Signal Timings" table of the PCI Express Card Electromechanical Specification, Revision 5.1, Section 2.9.2, indicates PERST# should be deasserted after minimum of 100us once REFCLK is stable (symbol T_PERST-CLK). Add a macro so that PCIe controller drivers can use it. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-5-a2f9156da6c3@bootlin.com Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> [kwilczynski: commit log, update sleep interval macros code comments] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:44:58 +00:00
/*
* Power stable to PERST# inactive.
*
* See the "Power Sequencing and Reset Signal Timings" table of the PCI Express
* Card Electromechanical Specification, Revision 5.1, Section 2.9.2, Symbol
* "T_PVPERL".
*/
PCI: Add T_PVPERL macro JIRA: https://issues.redhat.com/browse/RHEL-26162 Upstream Status: 164f66be0c2523e65df41b755c41b7c9ff58035a commit 164f66be0c2523e65df41b755c41b7c9ff58035a Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Date: Wed Oct 18 17:56:17 2023 +0900 PCI: Add T_PVPERL macro According to the PCIe CEM r5.0, sec 2.9.2, Power stable to PERST# inactive interval is 100 ms as minimum. Add a macro so that the PCIe controller drivers can make use of it. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-02-22 17:12:33 +00:00
#define PCIE_T_PVPERL_MS 100
PCI: Add T_PERST_CLK_US macro JIRA: https://issues.redhat.com/browse/RHEL-67693 Upstream Status: 6aa9c09f1bcd339749b249830c604871740df268 commit 6aa9c09f1bcd339749b249830c604871740df268 Author: Thomas Richard <thomas.richard@bootlin.com> Date: Wed Jun 19 12:15:13 2024 +0200 PCI: Add T_PERST_CLK_US macro The "Power Sequencing and Reset Signal Timings" table of the PCI Express Card Electromechanical Specification, Revision 5.1, Section 2.9.2, indicates PERST# should be deasserted after minimum of 100us once REFCLK is stable (symbol T_PERST-CLK). Add a macro so that PCIe controller drivers can use it. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-5-a2f9156da6c3@bootlin.com Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> [kwilczynski: commit log, update sleep interval macros code comments] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:44:58 +00:00
/*
* REFCLK stable before PERST# inactive.
*
* See the "Power Sequencing and Reset Signal Timings" table of the PCI Express
* Card Electromechanical Specification, Revision 5.1, Section 2.9.2, Symbol
* "T_PERST-CLK".
*/
#define PCIE_T_PERST_CLK_US 100
PCI: rockchip-host: Wait 100ms after reset before starting configuration JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 70a7bfb1e515b03e54491254a4375cdfb9515227 commit 70a7bfb1e515b03e54491254a4375cdfb9515227 Author: Damien Le Moal <dlemoal@kernel.org> Date: Sat Apr 13 09:41:20 2024 +0900 PCI: rockchip-host: Wait 100ms after reset before starting configuration PCIe r6.0, sec 6.6.1, states that the host should wait for at least 100 msec from the end of a conventional reset (PERST# is de-asserted) before sending a configuration request to ensure that the device is able to respond with a "Request Retry Status" completion. Add the PCIE_T_RRS_READY_MS macro to define this wait time and modify rockchip_pcie_host_init_port() to add this 100ms sleep after deasserting PERST# using the ep_gpio GPIO. Link: https://lore.kernel.org/linux-pci/20240413004120.1099089-3-dlemoal@kernel.org Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-28 01:34:14 +00:00
/*
* End of conventional reset (PERST# de-asserted) to first configuration
* request (device able to respond with a "Request Retry Status" completion),
* from PCIe r6.0, sec 6.6.1.
*/
#define PCIE_T_RRS_READY_MS 100
PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: e78bd50b4078b3b2d9f85d97796b7c271e7860ca commit e78bd50b4078b3b2d9f85d97796b7c271e7860ca Author: Frank Li <Frank.Li@nxp.com> Date: Mon Aug 21 14:48:13 2023 -0400 PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value Add the PCIE_PME_TO_L2_TIMEOUT_US macro to define the L2 ready timeout as described in the PCI specifications. Link: https://lore.kernel.org/r/20230821184815.2167131-2-Frank.Li@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-02 16:43:13 +00:00
/*
* PCIe r6.0, sec 5.3.3.2.1 <PME Synchronization>
* Recommends 1ms to 10ms timeout to check L2 ready.
*/
#define PCIE_PME_TO_L2_TIMEOUT_US 10000
PCI: Add PCIE_MSG_CODE_ASSERT_INTx message macros JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 95cb8ff68851ed0d249fb8a1d9657987cd844e08 commit 95cb8ff68851ed0d249fb8a1d9657987cd844e08 Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Date: Thu Apr 18 12:04:24 2024 -0400 PCI: Add PCIE_MSG_CODE_ASSERT_INTx message macros Add "Message Routing" and "INTx Mechanism Messages" macros to enable a PCIe driver to send messages for INTx Interrupt Signaling. Values from PCIe r6.1, sec 2.2.8 and 2.2.8.1. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-1-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-24 19:10:44 +00:00
/* Message Routing (r[2:0]); PCIe r6.0, sec 2.2.8 */
#define PCIE_MSG_TYPE_R_RC 0
#define PCIE_MSG_TYPE_R_ADDR 1
#define PCIE_MSG_TYPE_R_ID 2
#define PCIE_MSG_TYPE_R_BC 3
#define PCIE_MSG_TYPE_R_LOCAL 4
#define PCIE_MSG_TYPE_R_GATHER 5
PCI: Add PCIE_MSG_CODE_PME_TURN_OFF message macro JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 9972b17712e434f1284bc85d77a2fdbb33db6c51 commit 9972b17712e434f1284bc85d77a2fdbb33db6c51 Author: Frank Li <Frank.Li@nxp.com> Date: Thu Apr 18 12:04:27 2024 -0400 PCI: Add PCIE_MSG_CODE_PME_TURN_OFF message macro Add PCIE_MSG_CODE_PME_TURN_OFF macros to enable a PCIe host driver to send PME_Turn_Off messages. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-4-a54265c39742@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-24 19:12:49 +00:00
/* Power Management Messages; PCIe r6.0, sec 2.2.8.2 */
#define PCIE_MSG_CODE_PME_TURN_OFF 0x19
PCI: Add PCIE_MSG_CODE_ASSERT_INTx message macros JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 95cb8ff68851ed0d249fb8a1d9657987cd844e08 commit 95cb8ff68851ed0d249fb8a1d9657987cd844e08 Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Date: Thu Apr 18 12:04:24 2024 -0400 PCI: Add PCIE_MSG_CODE_ASSERT_INTx message macros Add "Message Routing" and "INTx Mechanism Messages" macros to enable a PCIe driver to send messages for INTx Interrupt Signaling. Values from PCIe r6.1, sec 2.2.8 and 2.2.8.1. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-1-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-24 19:10:44 +00:00
/* INTx Mechanism Messages; PCIe r6.0, sec 2.2.8.1 */
#define PCIE_MSG_CODE_ASSERT_INTA 0x20
#define PCIE_MSG_CODE_ASSERT_INTB 0x21
#define PCIE_MSG_CODE_ASSERT_INTC 0x22
#define PCIE_MSG_CODE_ASSERT_INTD 0x23
#define PCIE_MSG_CODE_DEASSERT_INTA 0x24
#define PCIE_MSG_CODE_DEASSERT_INTB 0x25
#define PCIE_MSG_CODE_DEASSERT_INTC 0x26
#define PCIE_MSG_CODE_DEASSERT_INTD 0x27
PCI: expose pcie_link_speed and pcix_bus_speed arrays pcie_link_speed and pcix_bus_speed are arrays used by probe.c to correctly convert lnksta register values into the pci_bus_speed enum. These static arrays are useful outside probe for this purpose. This patch makes these defines into conist arrays and exposes them with an extern header in drivers/pci/pci.h -v2- * move extern declarations to drivers/pci/pci.h CC: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-07-31 06:53:16 +00:00
extern const unsigned char pcie_link_speed[];
PCI: Make early dump functionality generic Move early dump functionality into common code so that it is available for all architectures. No need to carry arch-specific reads around as the read hooks are already initialized by the time pci_setup_device() is getting called during scan. Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2018-06-05 02:16:09 +00:00
extern bool pci_early_dump;
PCI: expose pcie_link_speed and pcix_bus_speed arrays pcie_link_speed and pcix_bus_speed are arrays used by probe.c to correctly convert lnksta register values into the pci_bus_speed enum. These static arrays are useful outside probe for this purpose. This patch makes these defines into conist arrays and exposes them with an extern header in drivers/pci/pci.h -v2- * move extern declarations to drivers/pci/pci.h CC: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-07-31 06:53:16 +00:00
PCI: Apply _HPX Link Control settings to all devices with a link Previously we applied _HPX type 2 record Link Control register settings only to bridges with a subordinate bus. But it's better to apply them to all devices with a link because if the subordinate bus has not been allocated yet, we won't apply settings to the device. Use pcie_cap_has_lnkctl() to determine whether the device has a Link Control register instead of looking at dev->subordinate. [bhelgaas: changelog] Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-11-11 20:09:46 +00:00
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
PCI: Access Link 2 registers only for devices with Links Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166398 Upstream Status: 503fa23614dc95f96af883a8e2e873d5c6cd53d8 commit 503fa23614dc95f96af883a8e2e873d5c6cd53d8 Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Sat Sep 17 13:03:09 2022 +0100 PCI: Access Link 2 registers only for devices with Links PCIe r2.0, sec 7.8 added Link Capabilities/Status/Control 2 registers to the PCIe Capability with Capability Version 2. Previously we assumed these registers were implemented for all PCIe Capabilities of version 2 or greater, but in fact they are only implemented for devices with Links. Update pcie_capability_reg_implemented() to check whether the device has a Link. [bhelgaas: commit log, squash export] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057070.2275@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057300.2275@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-02-02 02:25:36 +00:00
bool pcie_cap_has_lnkctl2(const struct pci_dev *dev);
PCI/AER: Save AER Capability for suspend/resume Previously we did not save and restore the AER configuration on suspend/resume, so the configuration may be lost after resume. Save the AER configuration during suspend and restore it during resume. [bhelgaas: commit log] Link: https://lore.kernel.org/r/92EBB4272BF81E4089A7126EC1E7B28492C3B007@IRSMSX101.ger.corp.intel.com Signed-off-by: Mayurkumar Patel <mayurkumar.patel@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-10-18 16:52:21 +00:00
bool pcie_cap_has_rtctl(const struct pci_dev *dev);
PCI: Apply _HPX Link Control settings to all devices with a link Previously we applied _HPX type 2 record Link Control register settings only to bridges with a subordinate bus. But it's better to apply them to all devices with a link because if the subordinate bus has not been allocated yet, we won't apply settings to the device. Use pcie_cap_has_lnkctl() to determine whether the device has a Link Control register instead of looking at dev->subordinate. [bhelgaas: changelog] Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-11-11 20:09:46 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/* Functions internal to the PCI core code */
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
PCI: Add pci_mmap_resource_range() and use it for ARM64 Starting to leave behind the legacy of the pci_mmap_page_range() interface which takes "user-visible" BAR addresses. This takes just the resource and offset. For now, both APIs coexist and depending on the platform, one is implemented as a wrapper around the other. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-12 12:25:59 +00:00
PCI: fix size checks for mmap() on /proc/bus/pci files The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. This patch addresses all 3 issues. Updated with an enum type for the additional parameter for pci_mmap_fits(). Cc: stable@kernel.org Signed-off-by: Martin Wilck <martin.wilck@ts.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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> */
};
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Add pci_mmap_resource_range() and use it for ARM64 Starting to leave behind the legacy of the pci_mmap_page_range() interface which takes "user-visible" BAR addresses. This takes just the resource and offset. For now, both APIs coexist and depending on the platform, one is implemented as a wrapper around the other. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-12 12:25:59 +00:00
PCI: Add array to track reset method ordering Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 commit e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:34:54 2021 +0530 PCI: Add array to track reset method ordering Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.c om Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:06:23 +00:00
bool pci_reset_supported(struct pci_dev *dev);
void pci_init_reset_methods(struct pci_dev *dev);
PCI: Hide pci_reset_bridge_secondary_bus() from drivers Rename pci_reset_bridge_secondary_bus() to pci_bridge_secondary_bus_reset() and move the declaration from linux/pci.h to drivers/pci.h to be used internally in PCI directory only. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-19 23:04:11 +00:00
int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
PCI/ERR: Use slot reset if available The secondary bus reset may have link side effects that a hotplug capable port may incorrectly react to. Use the slot specific reset for hotplug ports, fixing the undesirable link down-up handling during error recovering. Signed-off-by: Keith Busch <keith.busch@intel.com> [bhelgaas: fold in https://lore.kernel.org/linux-pci/20180926152326.14821-1-keith.busch@intel.com for issue reported by Stephen Rothwell <sfr@canb.auug.org.au>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:11 +00:00
int pci_bus_error_reset(struct pci_dev *dev);
PCI: Move prototypes for pci_bus_find_capability to include/linux/pci.h We need pci_bus_find_capability() in some arch/powerpc code so move the prototype into a header accessible to it. Also kill the duplicate prototype for pci_bus_alloc_resource(). Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-17 04:27:10 +00:00
PCI: Make saved capability state private to core Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: f0ab00174eb7574732737fc0734d4b406aed6231 commit f0ab00174eb7574732737fc0734d4b406aed6231 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Mon Aug 2 17:17:28 2021 -0500 PCI: Make saved capability state private to core Interfaces and structs for saving and restoring PCI Capability state were declared in include/linux/pci.h, but aren't needed outside drivers/pci/. Move these to drivers/pci/pci.h: struct pci_cap_saved_data struct pci_cap_saved_state void pci_allocate_cap_save_buffers() void pci_free_cap_save_buffers() int pci_add_cap_save_buffer() int pci_add_ext_cap_save_buffer() struct pci_cap_saved_state *pci_find_saved_cap() struct pci_cap_saved_state *pci_find_saved_ext_cap() Link: https://lore.kernel.org/r/20210802221728.1469304-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 20:53:45 +00:00
struct pci_cap_saved_data {
u16 cap_nr;
bool cap_extended;
unsigned int size;
u32 data[];
};
struct pci_cap_saved_state {
struct hlist_node next;
struct pci_cap_saved_data cap;
};
void pci_allocate_cap_save_buffers(struct pci_dev *dev);
void pci_free_cap_save_buffers(struct pci_dev *dev);
int pci_add_cap_save_buffer(struct pci_dev *dev, char cap, unsigned int size);
int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
u16 cap, unsigned int size);
struct pci_cap_saved_state *pci_find_saved_cap(struct pci_dev *dev, char cap);
struct pci_cap_saved_state *pci_find_saved_ext_cap(struct pci_dev *dev,
u16 cap);
PCI/PM: Revert "PCI/PM: Apply D2 delay as milliseconds, not microseconds" This reverts commit 7e24bc347e57992d532bc2ed700209b0fc0a4bf5. 7e24bc347e57 was based on PCIe r5.0, sec 5.9, which claims we need a 200 ms delay when transitioning to or from D2. However, sec 5.3.1.3 states the delay as 200 μs (microseconds), as does the table in PCIe r4.0, sec 5.9.1. This looks like a typo in the r5.0 spec, so revert back to a 200 μs delay instead of a 200 ms delay. Fixes: 7e24bc347e57 ("PCI/PM: Apply D2 delay as milliseconds, not microseconds") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 */
PCI: Make PCI_PM_* delay times private These delay time definitions: #define PCI_PM_D2_DELAY 200 #define PCI_PM_D3_WAIT 10 #define PCI_PM_D3COLD_WAIT 100 #define PCI_PM_BUS_WAIT 50 are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-2-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:38 +00:00
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
PCI: PM/ACPI: Refresh all stale power state data in pci_pm_complete() In pci_pm_complete() there are checks to decide whether or not to resume devices that were left in runtime-suspend during the preceding system-wide transition into a sleep state. They involve checking the current power state of the device and comparing it with the power state of it set before the preceding system-wide transition, but the platform component of the device's power state is not handled correctly in there. Namely, on platforms with ACPI, the device power state information needs to be updated with care, so that the reference counters of power resources used by the device (if any) are set to ensure that the refreshed power state of it will be maintained going forward. To that end, introduce a new ->refresh_state() platform PM callback for PCI devices, for asking the platform to refresh the device power state data and ensure that the corresponding power state will be maintained going forward, make it invoke acpi_device_update_power() (for devices with ACPI PM) on platforms with ACPI and make pci_pm_complete() use it, through a new pci_refresh_power_state() wrapper function. Fixes: a0d2a959d3da (PCI: Avoid unnecessary resume after direct-complete) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-25 12:09:12 +00:00
void pci_refresh_power_state(struct pci_dev *dev);
PCI/PM: Use pci_power_up() in pci_set_power_state() Make it explicitly clear that the code to put devices into D0 in pci_set_power_state() and in pci_pm_default_resume_early() is the same by making the latter use pci_power_up() for transitions into D0. Code rearrangement, no intentional functional impact. Link: https://lore.kernel.org/r/2520019.OZ1nXS5aSj@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-11-05 10:27:49 +00:00
int pci_power_up(struct pci_dev *dev);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI/ERR: Rename pci_aer_clear_device_status() to pcie_clear_device_status() pci_aer_clear_device_status() clears the error bits in the PCIe Device Status Register (PCI_EXP_DEVSTA). Every PCIe device has this register, regardless of whether it supports AER. Rename pci_aer_clear_device_status() to pcie_clear_device_status() to make clear that it is PCIe-specific but not AER-specific. Move it to drivers/pci/pci.c, again since it's not AER-specific. No functional change intended. Link: https://lore.kernel.org/r/20200717195619.766662-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-07-16 22:34:30 +00:00
void pcie_clear_device_status(struct pci_dev *dev);
PCI/PM: Move pcie_clear_root_pme_status() to core Move pcie_clear_root_pme_status() from the port driver to the PCI core so it will be available even when the port driver isn't present. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2018-03-09 17:06:53 +00:00
void pcie_clear_root_pme_status(struct pci_dev *dev);
PCI: Make pci_check_pme_status(), pci_pme_wakeup_bus() private These interfaces: bool pci_check_pme_status(struct pci_dev *dev); void pci_pme_wakeup_bus(struct pci_bus *bus); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-3-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI / PM: Restore PME Enable after config space restoration Commit dc15e71eefc7 (PCI / PM: Restore PME Enable if skipping wakeup setup) introduced a mechanism by which the PME Enable bit can be restored by pci_enable_wake() if dev->wakeup_prepared is set in case it has been overwritten by PCI config space restoration. However, that commit overlooked the fact that on some systems (Dell XPS13 9360 in particular) the AML handling wakeup events checks PME Status and PME Enable and it won't trigger a Notify() for devices where those bits are not set while it is running. That happens during resume from suspend-to-idle when pci_restore_state() invoked by pci_pm_default_resume_early() clears PME Enable before the wakeup events are processed by AML, effectively causing those wakeup events to be ignored. Fix this issue by restoring the PME Enable configuration right after pci_restore_state() has been called instead of doing that in pci_enable_wake(). Fixes: dc15e71eefc7 (PCI / PM: Restore PME Enable if skipping wakeup setup) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2017-07-12 01:05:39 +00:00
void pci_pme_restore(struct pci_dev *dev);
PCI: PM: Replace pci_dev_keep_suspended() with two functions The code in pci_dev_keep_suspended() is relatively hard to follow due to the negative checks in it and in its callers and the function has a possible side-effect (disabling the PME) which doesn't really match its role. For this reason, move the PME disabling from pci_dev_keep_suspended() to a separate function and change the semantics (and name) of the rest of it, so that 'true' is returned when the device needs to be resumed (and not the other way around). Change the callers of pci_dev_keep_suspended() accordingly. While at it, make the code flow in pci_pm_poweroff() reflect the pci_pm_suspend() more closely to avoid arbitrary differences between them. This is a cosmetic change with no intention to alter behavior. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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);
PCI / PM: Avoid resuming more devices during system suspend Commit bac2a909a096 (PCI / PM: Avoid resuming PCI devices during system suspend) introduced a mechanism by which some PCI devices that were runtime-suspended at the system suspend time might be left in that state for the duration of the system suspend-resume cycle. However, it overlooked devices that were marked as capable of waking up the system just because PME support was detected in their PCI config space. Namely, in that case, device_can_wakeup(dev) returns 'true' for the device and if the device is not configured for system wakeup, device_may_wakeup(dev) returns 'false' and it will be resumed during system suspend even though configuring it for system wakeup may not really make sense at all. To avoid this problem, simply disable PME for PCI devices that have not been configured for system wakeup and are runtime-suspended at the system suspend time for the duration of the suspend-resume cycle. If the device is in D3cold, its config space is not available and it shouldn't be written to, but that's only possible if the device has platform PM support and the platform code is responsible for checking whether or not the device's configuration is suitable for system suspend in that case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-29 23:10:24 +00:00
void pci_dev_complete_resume(struct pci_dev *pci_dev);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Add support for Enhanced Allocation devices Add support for devices using Enhanced Allocation entries instead of BARs. This allows the kernel to parse the EA Extended Capability structure in PCI config space and claim the BAR-equivalent resources. See https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf [bhelgaas: add spec URL, s/pci_ea_set_flags/pci_ea_flags/, consolidate declarations, print unknown property in hex to match spec] Signed-off-by: Sean O. Stalley <sean.stalley@intel.com> [david.daney@cavium.com: Add more support/checking for Entry Properties, allow EA behind bridges, rewrite some error messages.] Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-10-29 22:35:39 +00:00
void pci_ea_init(struct pci_dev *dev);
PCI/MSI: Move MSI/MSI-X init to msi.c Move pci_msi_setup_pci_dev(), which disables MSI and MSI-X interrupts, from probe.c to msi.c so it's with all the other MSI code and more consistent with other capability initialization. This means we must compile msi.c always, even without CONFIG_PCI_MSI, so wrap the rest of msi.c in an #ifdef and adjust the Makefile accordingly. No functional change intended. Link: https://lore.kernel.org/r/20201203185110.1583077-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thierry Reding <treding@nvidia.com>
2020-12-03 18:51:08 +00:00
void pci_msi_init(struct pci_dev *dev);
void pci_msix_init(struct pci_dev *dev);
PCI: Activate runtime PM on a PCIe port only if it can suspend Currently pcie_portdrv_probe() activates runtime PM on a PCIe port even if it will never actually suspend because the BIOS is too old or the "pcie_port_pm=off" option was specified on the kernel command line. A few CPU cycles can be saved by not activating runtime PM at all in these cases, because rpm_idle() and rpm_suspend() will bail out right at the beginning when calling rpm_check_suspend_allowed(), instead of carrying out various locking and assignments, invoking rpm_callback(), getting back -EBUSY and rolling everything back. The conditions checked in pci_bridge_d3_possible() are all static, they never change during uptime of the system, hence it's safe to call this to determine if runtime PM should be activated. No functional change intended. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-10-28 08:52:06 +00:00
bool pci_bridge_d3_possible(struct pci_dev *dev);
PCI: Autosense device removal in pci_bridge_d3_update() The algorithm to update the flag indicating whether a bridge may go to D3 makes a few optimizations based on whether the update was caused by the removal of a device on the one hand, versus the addition of a device or the change of its D3cold flags on the other hand. The information whether the update pertains to a removal is currently passed in by the caller, but the function may as well determine that itself by examining the device in question, thereby allowing for a considerable simplification and reduction of the code. Out of several options to determine removal, I've chosen the function device_is_registered() because it's cheap: It merely returns the dev->kobj.state_in_sysfs flag. That flag is set through device_add() when the root bus is scanned and cleared through device_remove(). The call to pci_bridge_d3_update() happens after each of these calls, respectively, so the ordering is correct. No functional change intended. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-10-28 08:52:06 +00:00
void pci_bridge_d3_update(struct pci_dev *dev);
PCI/PM: Drop pci_bridge_wait_for_secondary_bus() timeout parameter Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2228915 Upstream Status: e74b2b58ff715ca17bb49c3ad89f665a7150e14b commit e74b2b58ff715ca17bb49c3ad89f665a7150e14b Author: Mika Westerberg <mika.westerberg@linux.intel.com> Date: Tue Apr 4 15:32:55 2023 -0500 PCI/PM: Drop pci_bridge_wait_for_secondary_bus() timeout parameter All callers of pci_bridge_wait_for_secondary_bus() supply a timeout of PCIE_RESET_READY_POLL_MS, so drop the parameter. Move the definition of PCIE_RESET_READY_POLL_MS into pci.c, the only user. [bhelgaas: extracted from https://lore.kernel.org/r/20230404052714.51315-3-mika.westerberg@linux.intel.com] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-05-10 16:58:18 +00:00
int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type);
PCI PM: Restore standard config registers of all devices early There is a problem in our handling of suspend-resume of PCI devices that many of them have their standard config registers restored with interrupts enabled and they are put into the full power state with interrupts enabled as well. This may lead to the following scenario: * an interrupt vector is shared between two or more devices * one device is resumed earlier and generates an interrupt * the interrupt handler of another device tries to handle it and attempts to access the device the config space of which hasn't been restored yet and/or which still is in a low power state * the system crashes as a result To prevent this from happening we should restore the standard configuration registers of all devices with interrupts disabled and we should put them into the D0 power state right after that. Unfortunately, this cannot be done using the existing pci_set_power_state(), because it can sleep. Also, to do it we have to make sure that the config spaces of all devices were actually saved during suspend. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-16 20:54:43 +00:00
PCI: Rename CRS Completion Status to RRS JIRA: https://issues.redhat.com/browse/RHEL-67693 Upstream Status: 87f10faf166a9114aa0d4132298cad379de16fdd commit 87f10faf166a9114aa0d4132298cad379de16fdd Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Aug 27 18:48:48 2024 -0500 PCI: Rename CRS Completion Status to RRS PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status" Completion Status from "CRS" to "RRS" and uses the terminology of "Configuration RRS Software Visibility" instead of "CRS Software Visibility". Align the Linux usage with the r6.0 spec language. No functional change intended. It's confusing to make this change, but I think "RRS" *is* a better abbreviation because it was easy to interpret "CRS" as "Completion Retry Status", which really didn't make any sense. Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:00:31 +00:00
static inline bool pci_bus_rrs_vendor_id(u32 l)
PCI: Wait for device readiness with Configuration RRS JIRA: https://issues.redhat.com/browse/RHEL-71363 Upstream Status: d591f6804e7e1310881c9224d72247a2b65039af commit d591f6804e7e1310881c9224d72247a2b65039af Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Aug 27 18:48:46 2024 -0500 PCI: Wait for device readiness with Configuration RRS After a device reset, delays are required before the device can successfully complete config accesses. PCIe r6.0, sec 6.6, specifies some delays required before software can perform config accesses. Devices that require more time after those delays may respond to config accesses with Configuration Request Retry Status (RRS) completions. Callers of pci_dev_wait() are responsible for delays until the device can respond to config accesses. pci_dev_wait() waits any additional time until the device can successfully complete config accesses. Reading config space of devices that are not present or not ready typically returns ~0 (PCI_ERROR_RESPONSE). Previously we polled the Command register until we got a value other than ~0. This is sometimes a problem because Root Complex handling of RRS completions may include several retries and implementation-specific behavior that is invisible to software (see sec 2.3.2), so the exponential backoff in pci_dev_wait() may not work as intended. Linux enables Configuration RRS Software Visibility on all Root Ports that support it. If it is enabled, read the Vendor ID instead of the Command register. RRS completions cause immediate return of the 0x0001 reserved Vendor ID value, so the pci_dev_wait() backoff works correctly. When a read of Vendor ID eventually completes successfully by returning a non-0x0001 value (the Vendor ID or 0xffff for VFs), the device should be initialized and ready to respond to config requests. For conventional PCI devices or devices below Root Ports that don't support Configuration RRS Software Visibility, poll the Command register as before. This was developed independently, but is very similar to Stanislav Spassov's previous work at https://lore.kernel.org/linux-pci/20200223122057.6504-1-stanspas@amazon.com Link: https://lore.kernel.org/r/20240827234848.4429-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Duc Dang <ducdang@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-12-16 16:42:52 +00:00
{
return (l & 0xffff) == PCI_VENDOR_ID_PCI_SIG;
}
PCI/PM: Use pm_wakeup_event() directly for reporting wakeup events After recent changes related to wakeup events pm_wakeup_event() automatically checks if the given device is configured to signal wakeup, so pci_wakeup_event() may be a static inline function calling pm_wakeup_event() directly. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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);
}
PCI: Rename pci_is_bridge() to pci_has_subordinate() Previously, pci_is_bridge() returned true only when a subordinate bus existed. Rename pci_is_bridge() to pci_has_subordinate() to better indicate what we're checking. No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-04 04:23:36 +00:00
static inline bool pci_has_subordinate(struct pci_dev *pci_dev)
PCI PM: Restore standard config registers of all devices early There is a problem in our handling of suspend-resume of PCI devices that many of them have their standard config registers restored with interrupts enabled and they are put into the full power state with interrupts enabled as well. This may lead to the following scenario: * an interrupt vector is shared between two or more devices * one device is resumed earlier and generates an interrupt * the interrupt handler of another device tries to handle it and attempts to access the device the config space of which hasn't been restored yet and/or which still is in a low power state * the system crashes as a result To prevent this from happening we should restore the standard configuration registers of all devices with interrupts disabled and we should put them into the D0 power state right after that. Unfortunately, this cannot be done using the existing pci_set_power_state(), because it can sleep. Also, to do it we have to make sure that the config spaces of all devices were actually saved during suspend. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-16 20:54:43 +00:00
{
return !!(pci_dev->subordinate);
}
[ACPI] PCI can now get suspend state from firmware pci_choose_state() can now call platform_pci_choose_state() and ACPI can answer http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-03-19 05:15:48 +00:00
PCI: Put PCIe ports into D3 during suspend Currently the Linux PCI core does not touch power state of PCI bridges and PCIe ports when system suspend is entered. Leaving them in D0 consumes power unnecessarily and may prevent the CPU from entering deeper C-states. With recent PCIe hardware we can power down the ports to save power given that we take into account few restrictions: - The PCIe port hardware is recent enough, starting from 2015. - Devices connected to PCIe ports are effectively in D3cold once the port is transitioned to D3 (the config space is not accessible anymore and the link may be powered down). - Devices behind the PCIe port need to be allowed to transition to D3cold and back. There is a way both drivers and userspace can forbid this. - If the device behind the PCIe port is capable of waking the system it needs to be able to do so from D3cold. This patch adds a new flag to struct pci_device called 'bridge_d3'. This flag is set and cleared by the PCI core whenever there is a change in power management state of any of the devices behind the PCIe port. When system later on is suspended we only need to check this flag and if it is true transition the port to D3 otherwise we leave it in D0. Also provide override mechanism via command line parameter "pcie_port_pm=[off|force]" that can be used to disable or enable the feature regardless of the BIOS manufacturing date. Tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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;
}
PCI: Make pcie_downstream_port() available outside of access.c pcie_downstream_port() is useful in other places where code needs to determine whether the PCIe port is downstream so make it available outside of access.c. Link: https://lore.kernel.org/r/20190822085553.62697-1-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
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;
}
PCI/VPD: Change pci_vpd_init() return type to void pci_init_capabilities() is the only caller and doesn't use the return value. So let's change the return type to void. Link: https://lore.kernel.org/r/663ec440-8375-1459-ddb4-98ea76e75917@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-04-01 16:37:47 +00:00
void pci_vpd_init(struct pci_dev *dev);
PCI/sysfs: Convert "vpd" to static attribute The "vpd" sysfs attribute allows access to Vital Product Data (VPD). Previously it was dynamically created either by pci_bus_add_device() or the pci_sysfs_init() initcall, but since it doesn'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 "vpd" to a static attribute and use the .is_bin_visible() callback to check whether the device supports VPD. Remove pcie_vpd_create_sysfs_dev_files(), pcie_vpd_remove_sysfs_dev_files(), pci_create_capabilities_sysfs(), and pci_create_capabilities_sysfs(), which are no longer needed. [bhelgaas: This is substantially the same as the earlier patch from Heiner Kallweit <hkallweit1@gmail.com>. I included Krzysztof's change here so all the "convert to static attribute" changes are together.] [bhelgaas: rename to vpd_read()/vpd_write() and pci_dev_vpd_attr_group] Suggested-by: Oliver O'Halloran <oohall@gmail.com> Based-on: https://lore.kernel.org/r/7703024f-8882-9eec-a122-599871728a89@gmail.com Based-on-patch-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20210416205856.3234481-5-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-04-16 20:58:40 +00:00
extern const struct attribute_group pci_dev_vpd_attr_group;
PCI: Expose PCI VPD through sysfs Vital Product Data (VPD) may be exposed by PCI devices in several ways. It is generally unsafe to read this information through the existing interfaces to user-land because of stateful interfaces. This adds: - abstract operations for VPD access (struct pci_vpd_ops) - VPD state information in struct pci_dev (struct pci_vpd) - an implementation of the VPD access method specified in PCI 2.2 (in access.c) - a 'vpd' binary file in sysfs directories for PCI devices with VPD operations defined It adds a probe for PCI 2.2 VPD in pci_scan_device() and release of VPD state in pci_release_dev(). Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-05 16:52:39 +00:00
PCI: Make pci_save_vc_state(), pci_restore_vc_state(), etc private These Virtual Channel interfaces: 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); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-5-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/* PCI /proc functions */
#ifdef CONFIG_PROC_FS
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
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 */
PCI: add generic pci_hp_add_bridge() This creates a generic pci_hp_add_bridge() that can be used by several hotplug drivers. [bhelgaas: split out from pciehp patch] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-05-18 19:46:34 +00:00
int pci_hp_add_bridge(struct pci_dev *dev);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Conflict(s): Patching file drivers/pci/Makefile: Hunk #1 FAILED at 4. Post context conflict due to originating patch not taking into account upstream commit 1e8cc8e6bd85 "PCI: Place interrupt related code into irq.c" (see merge commit b8de187056f "Merge branch 'pci/sysfs'"). commit be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Author: Lukas Wunner <lukas@wunner.de> Date: Mon Oct 30 13:32:12 2023 +0100 PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actually make sense. However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled, unnecessarily increasing the kernel's size. To rectify that: * Move pci_mmap_fits() to mmap.c. It is not only needed by pci-sysfs.c, but also proc.c. * Move pci_dev_type to probe.c and make it private. It references pci_dev_attr_groups in pci-sysfs.c. Make that public instead for consistency with pci_dev_groups, pcibus_groups and pci_bus_groups, which are likewise public and referenced by struct definitions in pci-driver.c and probe.c. * Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty static inlines for pci_{create,remove}_legacy_files() and pci_{create,remove}_sysfs_dev_files(). Result: vmlinux size is reduced by 122996 bytes in my arm 32-bit test build. Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-05-03 01:04:49 +00:00
#if defined(CONFIG_SYSFS) && defined(HAVE_PCI_LEGACY)
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Add ability to mmap legacy_io on some platforms This adds the ability to mmap legacy IO space to the legacy_io files in sysfs on platforms that support it. This will allow to clean up X to use this instead of /dev/mem for legacy IO accesses such as those performed by Int10. While at it I moved pci_create/remove_legacy_files() to pci-sysfs.c where I think they belong, thus making more things statis in there and cleaned up some spurrious prototypes in the ia64 pci.h file Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-10-03 09:49:32 +00:00
#else
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void pci_create_legacy_files(struct pci_bus *bus) { }
static inline void pci_remove_legacy_files(struct pci_bus *bus) { }
PCI: Add ability to mmap legacy_io on some platforms This adds the ability to mmap legacy IO space to the legacy_io files in sysfs on platforms that support it. This will allow to clean up X to use this instead of /dev/mem for legacy IO accesses such as those performed by Int10. While at it I moved pci_create/remove_legacy_files() to pci-sysfs.c where I think they belong, thus making more things statis in there and cleaned up some spurrious prototypes in the ia64 pci.h file Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-10-03 09:49:32 +00:00
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/* Lock for read/write access to pci device and bus lists */
[PATCH] PCI: fix race with pci_walk_bus and pci_destroy_dev pci_walk_bus has a race with pci_destroy_dev. When cb is called in pci_walk_bus, pci_destroy_dev might unlink the dev pointed by next. Later on in the next loop, pointer next becomes NULL and cause kernel panic. Below patch against 2.6.17-rc4 fixes it by changing pci_bus_lock (spin_lock) to pci_bus_sem (rw_semaphore). Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-02 04:35:43 +00:00
extern struct rw_semaphore pci_bus_sem;
PCI/ERR: Use slot reset if available The secondary bus reset may have link side effects that a hotplug capable port may incorrectly react to. Use the slot specific reset for hotplug ports, fixing the undesirable link down-up handling during error recovering. Signed-off-by: Keith Busch <keith.busch@intel.com> [bhelgaas: fold in https://lore.kernel.org/linux-pci/20180926152326.14821-1-keith.busch@intel.com for issue reported by Stephen Rothwell <sfr@canb.auug.org.au>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:11 +00:00
extern struct mutex pci_slot_mutex;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
PCI: Introduce INTx check & mask API These new PCI services allow to probe for 2.3-compliant INTx masking support and then use the feature from PCI interrupt handlers. The services are properly synchronized with concurrent config space access via sysfs or on device reset. This enables generic PCI device drivers like uio_pci_generic or KVM's device assignment to implement the necessary kernel-side IRQ handling without any knowledge about device-specific interrupt status and control registers. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-11-04 08:46:00 +00:00
extern raw_spinlock_t pci_lock;
PCI/PM: Rename pci_dev.d3_delay to d3hot_delay PCI devices support two variants of the D3 power state: D3hot (main power present) D3cold (main power removed). Previously struct pci_dev contained: unsigned int d3_delay; /* D3->D0 transition time in ms */ unsigned int d3cold_delay; /* D3cold->D0 transition time in ms */ "d3_delay" refers specifically to the D3hot state. Rename it to "d3hot_delay" to avoid ambiguity and align with the ACPI "_DSM for Specifying Device Readiness Durations" in the PCI Firmware spec r3.2, sec 4.6.9. There is no change to the functionality. Link: https://lore.kernel.org/r/20200730210848.1578826-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-07-30 21:08:48 +00:00
extern unsigned int pci_pm_d3hot_delay;
MSI: Replace pci_msi_quirk with calls to pci_no_msi() I don't see any reason why we need pci_msi_quirk, quirk code can just call pci_no_msi() instead. Remove the check of pci_msi_quirk in msi_init(). This is safe as all calls to msi_init() are protected by calls to pci_msi_supported(), which checks pci_msi_enable, which is disabled by pci_no_msi(). The pci_disable_msi routines didn't check pci_msi_quirk, only pci_msi_enable, but as far as I can see that was a bug not a feature. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-01-25 08:34:07 +00:00
[PATCH] PCI: fix quirk-6700-fix.patch drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh': /usr/src/25/drivers/pci/quirks.c:1312: undefined reference to `disable_msi_mode' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-16 22:16:05 +00:00
#ifdef CONFIG_PCI_MSI
[PATCH] PCI: Provide a boot parameter to disable MSI Several drivers are starting to grow options to disable MSI. However, it's often a host chipset issue, not something which individual drivers should handle. So we add the pci=nomsi kernel parameter to allow the user to disable MSI modes for systems we haven't added to the quirk list yet. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-06 05:33:34 +00:00
void pci_no_msi(void);
[PATCH] PCI: fix quirk-6700-fix.patch drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh': /usr/src/25/drivers/pci/quirks.c:1312: undefined reference to `disable_msi_mode' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-16 22:16:05 +00:00
#else
[PATCH] PCI: Provide a boot parameter to disable MSI Several drivers are starting to grow options to disable MSI. However, it's often a host chipset issue, not something which individual drivers should handle. So we add the pci=nomsi kernel parameter to allow the user to disable MSI modes for systems we haven't added to the quirk list yet. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-06 05:33:34 +00:00
static inline void pci_no_msi(void) { }
[PATCH] PCI: fix quirk-6700-fix.patch drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh': /usr/src/25/drivers/pci/quirks.c:1312: undefined reference to `disable_msi_mode' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-16 22:16:05 +00:00
#endif
MSI: Combine pci_(save|restore)_msi/msix_state The PCI save/restore code doesn't need to care about MSI vs MSI-X, all it really wants is to say "save/restore all MSI(-X) info for this device". This is borne out in the code, we call the MSI and MSI-X save routines side by side, and similarly with the restore routines. So combine the MSI/MSI-X routines into pci_save_msi_state() and pci_restore_msi_state(). It is up to those routines to decide what state needs to be saved. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-01-25 08:34:08 +00:00
PCI: prepare pci=realloc for multiple options Let the user could enable and disable with pci=realloc=on or pci=realloc=off Also 1. move variable and functions near the place they are used. 2. change macro to function 3. change related functions and variable to static and _init 4. update parameter description accordingly. This will let us add a config option to control default behavior, and still allow the user to turn off automatic reallocation if it fails on their platform until a permanent solution is found. -v2: still honor pci=realloc, and treat it as pci=realloc=on also use enum instead of ... -v3: update kernel-paramenters.txt according to Jesse. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-24 03:23:30 +00:00
void pci_realloc_get_opt(char *);
PCI: conditional resource-reallocation through kernel parameter pci=realloc Multiple attempts to dynamically reallocate pci resources have unfortunately lead to regressions. Though we continue to fix the regressions and fine tune the dynamic-reallocation behavior, we have not reached a acceptable state yet. This patch provides a interim solution. It disables dynamic reallocation by default, but adds the ability to enable it through pci=realloc kernel command line parameter. Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-07 18:19:10 +00:00
[PATCH] PCI: PCIE power management quirk When changing power states from D0->DX and then from DX->D0, some Intel PCIE chipsets will cause a device reset to occur. This will cause problems for any D State other than D3, since any state information that the driver will expect to be present coming from a D1 or D2 state will have been cleared. This patch addes a flag to the pci_dev structure to indicate that devices should not use states D1 or D2, and will set that flag for the affected chipsets. This patch also modifies pci_set_power_state() so that when a device driver tries to set the power state on a device that is downstream from an affected chipset, or on one of the affected devices it only allows state changes to or from D0 & D3. In addition, this patch allows the delay time between D3->D0 to be changed via a quirk. These chipsets also need additional time to change states beyond the normal 10ms. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-12 15:59:00 +00:00
static inline int pci_no_d1d2(struct pci_dev *dev)
{
unsigned int parent_dstates = 0;
[PATCH] PCI: fix quirk-6700-fix.patch drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh': /usr/src/25/drivers/pci/quirks.c:1312: undefined reference to `disable_msi_mode' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-16 22:16:05 +00:00
[PATCH] PCI: PCIE power management quirk When changing power states from D0->DX and then from DX->D0, some Intel PCIE chipsets will cause a device reset to occur. This will cause problems for any D State other than D3, since any state information that the driver will expect to be present coming from a D1 or D2 state will have been cleared. This patch addes a flag to the pci_dev structure to indicate that devices should not use states D1 or D2, and will set that flag for the affected chipsets. This patch also modifies pci_set_power_state() so that when a device driver tries to set the power state on a device that is downstream from an affected chipset, or on one of the affected devices it only allows state changes to or from D0 & D3. In addition, this patch allows the delay time between D3->D0 to be changed via a quirk. These chipsets also need additional time to change states beyond the normal 10ms. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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);
}
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Conflict(s): Patching file drivers/pci/Makefile: Hunk #1 FAILED at 4. Post context conflict due to originating patch not taking into account upstream commit 1e8cc8e6bd85 "PCI: Place interrupt related code into irq.c" (see merge commit b8de187056f "Merge branch 'pci/sysfs'"). commit be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Author: Lukas Wunner <lukas@wunner.de> Date: Mon Oct 30 13:32:12 2023 +0100 PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actually make sense. However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled, unnecessarily increasing the kernel's size. To rectify that: * Move pci_mmap_fits() to mmap.c. It is not only needed by pci-sysfs.c, but also proc.c. * Move pci_dev_type to probe.c and make it private. It references pci_dev_attr_groups in pci-sysfs.c. Make that public instead for consistency with pci_dev_groups, pcibus_groups and pci_bus_groups, which are likewise public and referenced by struct definitions in pci-driver.c and probe.c. * Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty static inlines for pci_{create,remove}_legacy_files() and pci_{create,remove}_sysfs_dev_files(). Result: vmlinux size is reduced by 122996 bytes in my arm 32-bit test build. Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-05-03 01:04:49 +00:00
#ifdef CONFIG_SYSFS
int pci_create_sysfs_dev_files(struct pci_dev *pdev);
void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
PCI: convert bus code to use dev_groups The dev_attrs field of struct bus_type is going away soon, dev_groups should be used instead. This converts the PCI bus code to use the correct field. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-10-07 06:55:40 +00:00
extern const struct attribute_group *pci_dev_groups[];
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Conflict(s): Patching file drivers/pci/Makefile: Hunk #1 FAILED at 4. Post context conflict due to originating patch not taking into account upstream commit 1e8cc8e6bd85 "PCI: Place interrupt related code into irq.c" (see merge commit b8de187056f "Merge branch 'pci/sysfs'"). commit be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Author: Lukas Wunner <lukas@wunner.de> Date: Mon Oct 30 13:32:12 2023 +0100 PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actually make sense. However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled, unnecessarily increasing the kernel's size. To rectify that: * Move pci_mmap_fits() to mmap.c. It is not only needed by pci-sysfs.c, but also proc.c. * Move pci_dev_type to probe.c and make it private. It references pci_dev_attr_groups in pci-sysfs.c. Make that public instead for consistency with pci_dev_groups, pcibus_groups and pci_bus_groups, which are likewise public and referenced by struct definitions in pci-driver.c and probe.c. * Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty static inlines for pci_{create,remove}_legacy_files() and pci_{create,remove}_sysfs_dev_files(). Result: vmlinux size is reduced by 122996 bytes in my arm 32-bit test build. Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-05-03 01:04:49 +00:00
extern const struct attribute_group *pci_dev_attr_groups[];
PCI: Convert class code to use dev_groups The dev_attrs field of struct class is going away soon, dev_groups should be used instead. This converts the PCI class code to use the correct field. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-07-24 22:05:17 +00:00
extern const struct attribute_group *pcibus_groups[];
PCI: convert bus code to use bus_groups The bus_attrs field of struct bus_type is going away soon, dev_groups should be used instead. This converts the PCI bus code to use the correct field. Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-07 20:51:02 +00:00
extern const struct attribute_group *pci_bus_groups[];
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Conflict(s): Patching file drivers/pci/Makefile: Hunk #1 FAILED at 4. Post context conflict due to originating patch not taking into account upstream commit 1e8cc8e6bd85 "PCI: Place interrupt related code into irq.c" (see merge commit b8de187056f "Merge branch 'pci/sysfs'"). commit be9c3a4c8be13326e434d8817d6dda6c5d2835f5 Author: Lukas Wunner <lukas@wunner.de> Date: Mon Oct 30 13:32:12 2023 +0100 PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actually make sense. However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled, unnecessarily increasing the kernel's size. To rectify that: * Move pci_mmap_fits() to mmap.c. It is not only needed by pci-sysfs.c, but also proc.c. * Move pci_dev_type to probe.c and make it private. It references pci_dev_attr_groups in pci-sysfs.c. Make that public instead for consistency with pci_dev_groups, pcibus_groups and pci_bus_groups, which are likewise public and referenced by struct definitions in pci-driver.c and probe.c. * Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty static inlines for pci_{create,remove}_legacy_files() and pci_{create,remove}_sysfs_dev_files(). Result: vmlinux size is reduced by 122996 bytes in my arm 32-bit test build. Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-05-03 01:04:49 +00:00
#else
static inline int pci_create_sysfs_dev_files(struct pci_dev *pdev) { return 0; }
static inline void pci_remove_sysfs_dev_files(struct pci_dev *pdev) { }
#define pci_dev_groups NULL
#define pci_dev_attr_groups NULL
#define pcibus_groups NULL
#define pci_bus_groups NULL
#endif
PCI: Introduce /sys/bus/pci/rescan This interface allows the user to force a rescan of all PCI buses in system, and rediscover devices that have been removed earlier. pci_bus_attrs implementation from Trent Piepho. Thanks to Vegard Nossum for discovering locking issues with the sysfs interface. Cc: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 20:56:31 +00:00
PCI: Make pci_hotplug_io_size, mem_size, and bus_size private These symbols: extern unsigned long pci_hotplug_io_size; extern unsigned long pci_hotplug_mem_size; extern unsigned long pci_hotplug_bus_size; are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-6-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:42 +00:00
extern unsigned long pci_hotplug_io_size;
PCI: Add "pci=hpmmiosize" and "pci=hpmmioprefsize" parameters The existing "pci=hpmemsize=nn[KMG]" kernel parameter overrides the default size of both the non-prefetchable and the prefetchable MMIO windows for hotplug bridges. Add "pci=hpmmiosize=nn[KMG]" to override the default size of only the non-prefetchable MMIO window. Add "pci=hpmmioprefsize=nn[KMG]" to override the default size of only the prefetchable MMIO window. Link: https://lore.kernel.org/r/SL2P216MB0187E4D0055791957B7E2660806B0@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-10-23 12:12:29 +00:00
extern unsigned long pci_hotplug_mmio_size;
extern unsigned long pci_hotplug_mmio_pref_size;
PCI: Make pci_hotplug_io_size, mem_size, and bus_size private These symbols: extern unsigned long pci_hotplug_io_size; extern unsigned long pci_hotplug_mem_size; extern unsigned long pci_hotplug_bus_size; are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-6-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:42 +00:00
extern unsigned long pci_hotplug_bus_size;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/**
* pci_match_one_device - Tell if a PCI device structure has a matching
PCI: Clean up whitespace in linux/pci.h, pci/pci.h Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-02 19:21:37 +00:00
* PCI device id structure
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
* @id: single PCI device id structure to match
* @dev: the PCI device structure to match against
PCI: fix codingstyle issues in drivers/pci/pci.h Fixes a few coding style issues in the internal pci.h file Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-30 23:21:33 +00:00
*
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
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;
}
PCI: introduce pci_slot Currently, /sys/bus/pci/slots/ only exposes hotplug attributes when a hotplug driver is loaded, but PCI slots have attributes such as address, speed, width, etc. that are not related to hotplug at all. Introduce pci_slot as the primary data structure and kobject model. Hotplug attributes described in hotplug_slot become a secondary structure associated with the pci_slot. This patch only creates the infrastructure that allows the separation of PCI slot attributes and hotplug attributes. In this patch, the PCI hotplug core remains the only user of this infrastructure, and thus, /sys/bus/pci/slots/ will still only become populated when a hotplug driver is loaded. A later patch in this series will add a second user of this new infrastructure and demonstrate splitting the task of exposing pci_slot attributes from hotplug_slot attributes. - Make pci_slot the primary sysfs entity. hotplug_slot becomes a subsidiary structure. o pci_create_slot() creates and registers a slot with the PCI core o pci_slot_add_hotplug() gives it hotplug capability - Change the prototype of pci_hp_register() to take the bus and slot number (on parent bus) as parameters. - Remove all the ->get_address methods since this functionality is now handled by pci_slot directly. [achiang@hp.com: rpaphp-correctly-pci_hp_register-for-empty-pci-slots] Tested-by: Badari Pulavarty <pbadari@us.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: make headers_check happy] [akpm@linux-foundation.org: nuther build fix] [akpm@linux-foundation.org: fix typo in #include] Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Matthew Wilcox <matthew@wil.cx> Cc: Greg KH <greg@kroah.com> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Cc: Len Brown <lenb@kernel.org> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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)
PCI: export __pci_read_base() Export __pci_read_base() so it can be used by whole PCI subsystem. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-11-21 18:40:40 +00:00
enum pci_bar_type {
pci_bar_unknown, /* Standard PCI BAR probe */
PCI: Clean up whitespace in linux/pci.h, pci/pci.h Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-02 19:21:37 +00:00
pci_bar_io, /* An I/O port BAR */
PCI: export __pci_read_base() Export __pci_read_base() so it can be used by whole PCI subsystem. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-11-21 18:40:40 +00:00
pci_bar_mem32, /* A 32-bit memory BAR */
pci_bar_mem64, /* A 64-bit memory BAR */
};
PCI: Make pci_get_host_bridge_device(), pci_put_host_bridge_device() private These interfaces: struct device *pci_get_host_bridge_device(struct pci_dev *dev); void pci_put_host_bridge_device(struct device *dev); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-4-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken Per PCIe r3.1, sec 2.2.6.2 and 7.8.4, a Requester may not use 8-bit Tags unless its Extended Tag Field Enable is set, but all Receivers/Completers must handle 8-bit Tags correctly regardless of their Extended Tag Field Enable. Some devices do not handle 8-bit Tags as Completers, so add a quirk for them. If we find such a device, we disable Extended Tags for the entire hierarchy to make peer-to-peer DMA possible. The Broadcom HT2100 seems to have issues with handling 8-bit tags. Mark it as broken. The pci_walk_bus() in the quirk handles devices we've enumerated in the past, and pci_configure_device() handles devices we enumerate in the future. Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Link: https://bugzilla.redhat.com/show_bug.cgi?id=1467674 Reported-and-tested-by: Wim ten Have <wim.ten.have@oracle.com> Signed-off-by: Sinan Kaya <okaya@codeaurora.org> [bhelgaas: changelog, tweak messages, rename bit and quirk] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-07-12 04:04:14 +00:00
int pci_configure_extended_tags(struct pci_dev *dev, void *ign);
PCI: Separate pci_bus_read_dev_vendor_id from pci_scan_device We can reuse it for pciehp probing. -v2: according to Kenji, fix crs timeout checking, and export the function for later use when pciehp is compiled as a module. Suggested-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-27 18:55:10 +00:00
bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
PCI: Rename CRS Completion Status to RRS JIRA: https://issues.redhat.com/browse/RHEL-67693 Upstream Status: 87f10faf166a9114aa0d4132298cad379de16fdd commit 87f10faf166a9114aa0d4132298cad379de16fdd Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Aug 27 18:48:48 2024 -0500 PCI: Rename CRS Completion Status to RRS PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status" Completion Status from "CRS" to "RRS" and uses the terminology of "Configuration RRS Software Visibility" instead of "CRS Software Visibility". Align the Linux usage with the r6.0 spec language. No functional change intended. It's confusing to make this change, but I think "RRS" *is* a better abbreviation because it was easy to interpret "CRS" as "Completion Retry Status", which really didn't make any sense. Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:00:31 +00:00
int rrs_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,
PCI: Rename CRS Completion Status to RRS JIRA: https://issues.redhat.com/browse/RHEL-67693 Upstream Status: 87f10faf166a9114aa0d4132298cad379de16fdd commit 87f10faf166a9114aa0d4132298cad379de16fdd Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Aug 27 18:48:48 2024 -0500 PCI: Rename CRS Completion Status to RRS PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status" Completion Status from "CRS" to "RRS" and uses the terminology of "Configuration RRS Software Visibility" instead of "CRS Software Visibility". Align the Linux usage with the r6.0 spec language. No functional change intended. It's confusing to make this change, but I think "RRS" *is* a better abbreviation because it was easy to interpret "CRS" as "Completion Retry Status", which really didn't make any sense. Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:00:31 +00:00
int rrs_timeout);
int pci_idt_bus_quirk(struct pci_bus *bus, int devfn, u32 *pl, int rrs_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
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
int pci_setup_device(struct pci_dev *dev);
PCI: Batch BAR sizing operations JIRA: https://issues.redhat.com/browse/RHEL-76025 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=enumeration&id=4453f360862e5d9f0807941d613162c3f7a36559 In maintainer's PCI 'enumeration' branch, slated for v6.14. https://lore.kernel.org/all/20250120224418.GA906057@bhelgaas/ commit 4453f360862e5d9f0807941d613162c3f7a36559 (pci/enumeration) Author: Alex Williamson <alex.williamson@redhat.com> Date: Mon Jan 20 11:21:59 2025 -0700 PCI: Batch BAR sizing operations Toggling memory enable is free on bare metal, but potentially expensive in virtualized environments as the device MMIO spaces are added and removed from the VM address space, including DMA mapping of those spaces through the IOMMU where peer-to-peer is supported. Currently memory decode is disabled around sizing each individual BAR, even for SR-IOV BARs while VF Enable is cleared. This can be better optimized for virtual environments by sizing a set of BARs at once, stashing the resulting mask into an array, while only toggling memory enable once. This also naturally improves the SR-IOV path as the caller becomes responsible for any necessary decode disables while sizing BARs, therefore SR-IOV BARs are sized relying only on the VF Enable rather than toggling the PF memory enable in the command register. Link: https://lore.kernel.org/r/20250120182202.1878581-1-alex.williamson@redhat.com Reported-by: Mitchell Augustin <mitchell.augustin@canonical.com> Link: https://lore.kernel.org/r/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Mitchell Augustin <mitchell.augustin@canonical.com> Reviewed-by: Mitchell Augustin <mitchell.augustin@canonical.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-01-24 16:12:41 +00:00
void __pci_size_stdbars(struct pci_dev *dev, int count,
unsigned int pos, u32 *sizes);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
PCI: Batch BAR sizing operations JIRA: https://issues.redhat.com/browse/RHEL-76025 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=enumeration&id=4453f360862e5d9f0807941d613162c3f7a36559 In maintainer's PCI 'enumeration' branch, slated for v6.14. https://lore.kernel.org/all/20250120224418.GA906057@bhelgaas/ commit 4453f360862e5d9f0807941d613162c3f7a36559 (pci/enumeration) Author: Alex Williamson <alex.williamson@redhat.com> Date: Mon Jan 20 11:21:59 2025 -0700 PCI: Batch BAR sizing operations Toggling memory enable is free on bare metal, but potentially expensive in virtualized environments as the device MMIO spaces are added and removed from the VM address space, including DMA mapping of those spaces through the IOMMU where peer-to-peer is supported. Currently memory decode is disabled around sizing each individual BAR, even for SR-IOV BARs while VF Enable is cleared. This can be better optimized for virtual environments by sizing a set of BARs at once, stashing the resulting mask into an array, while only toggling memory enable once. This also naturally improves the SR-IOV path as the caller becomes responsible for any necessary decode disables while sizing BARs, therefore SR-IOV BARs are sized relying only on the VF Enable rather than toggling the PF memory enable in the command register. Link: https://lore.kernel.org/r/20250120182202.1878581-1-alex.williamson@redhat.com Reported-by: Mitchell Augustin <mitchell.augustin@canonical.com> Link: https://lore.kernel.org/r/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Mitchell Augustin <mitchell.augustin@canonical.com> Reviewed-by: Mitchell Augustin <mitchell.augustin@canonical.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-01-24 16:12:41 +00:00
struct resource *res, unsigned int reg, u32 *sizes);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
void pci_configure_ari(struct pci_dev *dev);
PCI: Remove unnecessary __ref annotations Some PCI functions used to be marked __devinit. When CONFIG_HOTPLUG was not set, these functions were discarded after boot. A few callers of these __devinit functions were marked __ref to indicate that they could safely call the __devinit functions even though the callers were not __devinit. But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref annotations is also gone, so remove them. Relevant historical commits: 54b956b90360 Remove __dev* markings from init.h a8e4b9c101ae PCI: add generic pci_hp_add_bridge() 0ab2b57f8db8 PCI: fix section mismatch warning in pci_scan_child_bus 451124a7cc6c PCI: fix 4x section mismatch warnings Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Remove unnecessary __ref annotations Some PCI functions used to be marked __devinit. When CONFIG_HOTPLUG was not set, these functions were discarded after boot. A few callers of these __devinit functions were marked __ref to indicate that they could safely call the __devinit functions even though the callers were not __devinit. But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref annotations is also gone, so remove them. Relevant historical commits: 54b956b90360 Remove __dev* markings from init.h a8e4b9c101ae PCI: add generic pci_hp_add_bridge() 0ab2b57f8db8 PCI: fix section mismatch warning in pci_scan_child_bus 451124a7cc6c PCI: fix 4x section mismatch warnings Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Add pci_bus_clip_resource() to clip to fit upstream window Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an upstream bridge window but is not completely contained by it, this clips the downstream window so it fits inside the upstream one. No functional change (this adds the function but no callers). [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+
2015-01-15 22:21:49 +00:00
bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
Merge branch 'pci/yinghai-root-bus-hotplug' into next * pci/yinghai-root-bus-hotplug: PCI: Put pci_dev in device tree as early as possible PCI: Skip attaching driver in device_add() PCI: acpiphp: Keep driver loaded even if no slots found PCI/ACPI: Print info if host bridge notify handler installation fails PCI: acpiphp: Move host bridge hotplug to pci_root.c PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work() PCI: Make device create/destroy logic symmetric PCI: Fix reference count leak in pci_dev_present() PCI: Set pci_dev dev_node early so IOAPIC irq_descs are allocated locally PCI: Add root bus children dev's res to fail list PCI: acpiphp: Add is_hotplug_bridge detection Conflicts: drivers/pci/pci.h
2013-01-27 00:35:58 +00:00
PCI: Update BAR # and window messages JIRA: https://issues.redhat.com/browse/RHEL-28627 Upstream Status: 65f8e0beac5a495b8f3b387add1f9f4470678cb5 commit 65f8e0beac5a495b8f3b387add1f9f4470678cb5 Author: Puranjay Mohan <puranjay12@gmail.com> Date: Sat Nov 6 16:56:05 2021 +0530 PCI: Update BAR # and window messages The PCI log messages print the register offsets at some places and BAR numbers at other places. There is no uniformity in this logging mechanism. It would be better to print names than register offsets. Add a helper function that aids in printing more meaningful information about the BAR numbers like "VF BAR", "ROM", "bridge window", etc. This function can be called while printing PCI log messages. [bhelgaas: fold in Lukas' static array suggestion from https://lore.kernel.org/all/20211106115831.GA7452@wunner.de/] Link: https://lore.kernel.org/r/20211106112606.192563-2-puranjay12@gmail.com Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-11 22:57:28 +00:00
const char *pci_resource_name(struct pci_dev *dev, unsigned int i);
PCI: Move "pci reassigndev resource alignment" out of quirks.c This isn't really a quirk; calling it directly from pci_add_device makes more sense. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-16 05:40:31 +00:00
void pci_reassigndev_resource_alignment(struct pci_dev *dev);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
void pci_disable_bridge_window(struct pci_dev *dev);
PCI: Make pci_bus_get(), pci_bus_put() private These interfaces: struct pci_bus *pci_bus_get(struct pci_bus *bus); void pci_bus_put(struct pci_bus *bus); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-7-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: allow assignment of memory resources with a specified alignment This patch allows memory resources to be assigned with a specified alignment at boot-time or run-time. The patch is useful when we use PCI pass-through, because page-aligned memory resources are required to securely share PCI resources with guest drivers. If you want to assign the resource at boot time, please set "pci=resource_alignment=" boot parameter. This is format of "pci=resource_alignment=" boot parameter: [<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...] Specifies alignment and device to reassign aligned memory resources. If <order of align> is not specified, PAGE_SIZE is used as alignment. PCI-PCI bridge can be specified, if resource windows need to be expanded. This is example: pci=resource_alignment=20@07:00.0;18@0f:00.0;00:1d.7 If you want to assign the resource at run-time, please set "/sys/bus/pci/resource_alignment" file, and hot-remove the device and hot-add the device. For this purpose, fakephp or PCI hotplug interfaces can be used. The format of "/sys/bus/pci/resource_alignment" file is the same with boot parameter. You can use "," instead of ";". For example: # cd /sys/bus/pci # echo -n 20@12:00.0 > resource_alignment # echo 1 > devices/0000:12:00.0/remove # echo 1 > rescan Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-16 08:13:39 +00:00
PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 commit de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:53 2024 +0300 PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed Currently, PCIe Link Speeds are adjusted by custom code rather than in a common function provided in PCI core. The PCIe bandwidth controller (bwctrl) introduces an in-kernel API, pcie_set_target_speed(), to set PCIe Link Speed. Convert Target Speed quirk to use the new API. The Target Speed quirk runs very early when bwctrl is not yet probed for a Port and can also run later when bwctrl is already setup for the Port, which requires the per port mutex (set_speed_mutex) to be only taken if the bwctrl setup is already complete. The new API is also intended to be used in an upcoming commit that adds a thermal cooling device to throttle PCIe bandwidth when thermal thresholds are reached. The PCIe bandwidth control procedure is as follows. The highest speed supported by the Port and the PCIe device which is not higher than the requested speed is selected and written into the Target Link Speed in the Link Control 2 Register. Then bandwidth controller retrains the PCIe Link. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. While Bandwidth Notifications should also be generated when bandwidth controller alters the PCIe Link Speed, a few platforms do not deliver LMBS interrupt after Link Training as expected. Thus, after changing the Link Speed, bandwidth controller makes additional read for the Link Status Register to ensure cur_bus_speed is consistent with the new PCIe Link Speed. Link: https://lore.kernel.org/r/20241018144755.7875-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash devm_mutex_init() error checking from https://lore.kernel.org/r/20241030163139.2111689-1-andriy.shevchenko@linux.intel.com, drop export of pcie_set_target_speed()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-03-20 16:33:57 +00:00
#define PCIE_LNKCAP_SLS2SPEED(lnkcap) \
({ \
((lnkcap) == PCI_EXP_LNKCAP_SLS_64_0GB ? PCIE_SPEED_64_0GT : \
(lnkcap) == PCI_EXP_LNKCAP_SLS_32_0GB ? PCIE_SPEED_32_0GT : \
(lnkcap) == PCI_EXP_LNKCAP_SLS_16_0GB ? PCIE_SPEED_16_0GT : \
(lnkcap) == PCI_EXP_LNKCAP_SLS_8_0GB ? PCIE_SPEED_8_0GT : \
(lnkcap) == PCI_EXP_LNKCAP_SLS_5_0GB ? PCIE_SPEED_5_0GT : \
(lnkcap) == PCI_EXP_LNKCAP_SLS_2_5GB ? PCIE_SPEED_2_5GT : \
PCI_SPEED_UNKNOWN); \
})
PCI: Add PCIE_LNKCAP2_SLS2SPEED() macro Add PCIE_LNKCAP2_SLS2SPEED macro for transforming raw Link Capabilities 2 values to the pci_bus_speed. This is next to PCIE_SPEED2MBS_ENC() to make it easier to update both places when adding support for new speeds. Link: https://lore.kernel.org/r/1581937984-40353-10-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-02-17 11:13:03 +00:00
/* PCIe link information from Link Capabilities 2 */
#define PCIE_LNKCAP2_SLS2SPEED(lnkcap2) \
PCI: Decode PCIe 64 GT/s link speed PCIe r6.0, sec 7.5.3.18, defines a new 64.0 GT/s bit in the Supported Link Speeds Vector of Link Capabilities 2. This patch does not affect the speed of the link, which should be negotiated automatically by the hardware; it only adds decoding when showing the speed to the user. Decode this new speed. Previously, reading the speed of a link operating at this speed showed "Unknown speed" instead of "64.0 GT/s". Link: https://lore.kernel.org/r/aaaab33fe18975e123a84aebce2adb85f44e2bbe.1605739760.git.gustavo.pimentel@synopsys.com Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
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 : \
PCI: Add PCIE_LNKCAP2_SLS2SPEED() macro Add PCIE_LNKCAP2_SLS2SPEED macro for transforming raw Link Capabilities 2 values to the pci_bus_speed. This is next to PCIE_SPEED2MBS_ENC() to make it easier to update both places when adding support for new speeds. Link: https://lore.kernel.org/r/1581937984-40353-10-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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)
PCI: Add pcie_get_speed_cap() to find max supported link speed Add pcie_get_speed_cap() to find the max link speed supported by a device. Change max_link_speed_show() to use pcie_get_speed_cap(). Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: return speed directly instead of error and *speed, don't export outside drivers/pci] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
2018-03-30 12:44:05 +00:00
PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 commit de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:53 2024 +0300 PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed Currently, PCIe Link Speeds are adjusted by custom code rather than in a common function provided in PCI core. The PCIe bandwidth controller (bwctrl) introduces an in-kernel API, pcie_set_target_speed(), to set PCIe Link Speed. Convert Target Speed quirk to use the new API. The Target Speed quirk runs very early when bwctrl is not yet probed for a Port and can also run later when bwctrl is already setup for the Port, which requires the per port mutex (set_speed_mutex) to be only taken if the bwctrl setup is already complete. The new API is also intended to be used in an upcoming commit that adds a thermal cooling device to throttle PCIe bandwidth when thermal thresholds are reached. The PCIe bandwidth control procedure is as follows. The highest speed supported by the Port and the PCIe device which is not higher than the requested speed is selected and written into the Target Link Speed in the Link Control 2 Register. Then bandwidth controller retrains the PCIe Link. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. While Bandwidth Notifications should also be generated when bandwidth controller alters the PCIe Link Speed, a few platforms do not deliver LMBS interrupt after Link Training as expected. Thus, after changing the Link Speed, bandwidth controller makes additional read for the Link Status Register to ensure cur_bus_speed is consistent with the new PCIe Link Speed. Link: https://lore.kernel.org/r/20241018144755.7875-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash devm_mutex_init() error checking from https://lore.kernel.org/r/20241030163139.2111689-1-andriy.shevchenko@linux.intel.com, drop export of pcie_set_target_speed()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-03-20 16:33:57 +00:00
#define PCIE_LNKCTL2_TLS2SPEED(lnkctl2) \
((lnkctl2) == PCI_EXP_LNKCTL2_TLS_64_0GT ? PCIE_SPEED_64_0GT : \
(lnkctl2) == PCI_EXP_LNKCTL2_TLS_32_0GT ? PCIE_SPEED_32_0GT : \
(lnkctl2) == PCI_EXP_LNKCTL2_TLS_16_0GT ? PCIE_SPEED_16_0GT : \
(lnkctl2) == PCI_EXP_LNKCTL2_TLS_8_0GT ? PCIE_SPEED_8_0GT : \
(lnkctl2) == PCI_EXP_LNKCTL2_TLS_5_0GT ? PCIE_SPEED_5_0GT : \
(lnkctl2) == PCI_EXP_LNKCTL2_TLS_2_5GT ? PCIE_SPEED_2_5GT : \
PCI_SPEED_UNKNOWN)
PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth Add pcie_bandwidth_capable() to compute the max link bandwidth supported by a device, based on the max link speed and width, adjusted by the encoding overhead. The maximum bandwidth of the link is computed as: max_link_width * max_link_speed * (1 - encoding_overhead) 2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which reduces it by about 1.5%. The result is in Mb/s, i.e., megabits/second, of raw bandwidth. Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: add 16 GT/s, adjust for pcie_get_speed_cap() and pcie_get_width_cap() signatures, don't export outside drivers/pci] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-03-30 13:32:03 +00:00
/* PCIe speed to Mb/s reduced by encoding overhead */
#define PCIE_SPEED2MBS_ENC(speed) \
PCI: Fix 64GT/s effective data rate calculation JIRA: https://issues.redhat.com/browse/RHEL-28627 Upstream Status: ac4f1897fa5433a1b07a625503a91b6aa9d7e643 commit ac4f1897fa5433a1b07a625503a91b6aa9d7e643 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Tue Jan 2 19:27:00 2024 +0200 PCI: Fix 64GT/s effective data rate calculation Unlike the lower rates, the PCIe 64GT/s Data Rate uses 1b/1b encoding, not 128b/130b (PCIe r6.1 sec 1.2, Table 1-1). Correct the PCIE_SPEED2MBS_ENC() calculation to reflect that. Link: https://lore.kernel.org/r/20240102172701.65501-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-11 19:15:51 +00:00
((speed) == PCIE_SPEED_64_0GT ? 64000*1/1 : \
PCI: Decode PCIe 64 GT/s link speed PCIe r6.0, sec 7.5.3.18, defines a new 64.0 GT/s bit in the Supported Link Speeds Vector of Link Capabilities 2. This patch does not affect the speed of the link, which should be negotiated automatically by the hardware; it only adds decoding when showing the speed to the user. Decode this new speed. Previously, reading the speed of a link operating at this speed showed "Unknown speed" instead of "64.0 GT/s". Link: https://lore.kernel.org/r/aaaab33fe18975e123a84aebce2adb85f44e2bbe.1605739760.git.gustavo.pimentel@synopsys.com Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2020-11-18 22:49:20 +00:00
(speed) == PCIE_SPEED_32_0GT ? 32000*128/130 : \
PCI: Add 32 GT/s decoding in some macros Link speed 32.0 GT/s is supported in PCIe r5.0. Add this speed to PCIE_SPEED2STR() and PCIE_SPEED2MBS_ENC() to correctly decode it. This is complementary to de76cda215d5 ("PCI: Decode PCIe 32 GT/s link speed"). Link: https://lore.kernel.org/r/1581937984-40353-2-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-02-17 11:12:55 +00:00
(speed) == PCIE_SPEED_16_0GT ? 16000*128/130 : \
PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth Add pcie_bandwidth_capable() to compute the max link bandwidth supported by a device, based on the max link speed and width, adjusted by the encoding overhead. The maximum bandwidth of the link is computed as: max_link_width * max_link_speed * (1 - encoding_overhead) 2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which reduces it by about 1.5%. The result is in Mb/s, i.e., megabits/second, of raw bandwidth. Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: add 16 GT/s, adjust for pcie_get_speed_cap() and pcie_get_width_cap() signatures, don't export outside drivers/pci] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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)
PCI: Bring the PCIe speed to MBps logic to new pcie_dev_speed_mbps() JIRA: https://issues.redhat.com/browse/RHEL-65598 Upstream Status: 100ae5d77f07f9f046106e228778c7aa1c6d3af3 commit 100ae5d77f07f9f046106e228778c7aa1c6d3af3 Author: Krishna chaitanya chundru <quic_krichai@quicinc.com> Date: Wed Jun 19 20:41:12 2024 +0530 PCI: Bring the PCIe speed to MBps logic to new pcie_dev_speed_mbps() Bring the switch case in pcie_link_speed_mbps() to new function to the header file so that it can be used in other places like in controller driver. Link: https://lore.kernel.org/linux-pci/20240619-opp_support-v15-3-aa769a2173a3@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-10-06 16:44:21 +00:00
static inline int pcie_dev_speed_mbps(enum pci_bus_speed speed)
{
switch (speed) {
case PCIE_SPEED_2_5GT:
return 2500;
case PCIE_SPEED_5_0GT:
return 5000;
case PCIE_SPEED_8_0GT:
return 8000;
case PCIE_SPEED_16_0GT:
return 16000;
case PCIE_SPEED_32_0GT:
return 32000;
case PCIE_SPEED_64_0GT:
return 64000;
default:
break;
}
return -EINVAL;
}
PCI: Store all PCIe Supported Link Speeds JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: d2bd39c0456b75be9dfc7d774b8d021355c26ae3 commit d2bd39c0456b75be9dfc7d774b8d021355c26ae3 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:49 2024 +0300 PCI: Store all PCIe Supported Link Speeds The PCIe bandwidth controller added by a subsequent commit will require selecting PCIe Link Speeds that are lower than the Maximum Link Speed. The struct pci_bus only stores max_bus_speed. Even if PCIe r6.1 sec 8.2.1 currently disallows gaps in supported Link Speeds, the Implementation Note in PCIe r6.1 sec 7.5.3.18, recommends determining supported Link Speeds using the Supported Link Speeds Vector in the Link Capabilities 2 Register (when available) to "avoid software being confused if a future specification defines Links that do not require support for all slower speeds." Reuse code in pcie_get_speed_cap() to add pcie_get_supported_speeds() to query the Supported Link Speeds Vector of a PCIe device. The value is taken directly from the Supported Link Speeds Vector or synthesized from the Max Link Speed in the Link Capabilities Register when the Link Capabilities 2 Register is not available. The Supported Link Speeds Vector in the Link Capabilities Register 2 corresponds to the bus below on Root Ports and Downstream Ports, whereas it corresponds to the bus above on Upstream Ports and Endpoints (PCIe r6.1 sec 7.5.3.18): Supported Link Speeds Vector - This field indicates the supported Link speed(s) of the associated Port. Add supported_speeds into the struct pci_dev that caches the Supported Link Speeds Vector. supported_speeds contains a set of Link Speeds only in the case where PCIe Link Speed can be determined. Root Complex Integrated Endpoints do not have a well-defined Link Speed because they do not implement either of the Link Capabilities Registers, which is allowed by PCIe r6.1 sec 7.5.3 (the same limitation applies to determining cur_bus_speed and max_bus_speed that are PCI_SPEED_UNKNOWN in such case). This is of no concern from PCIe bandwidth controller point of view because such devices are not attached into a PCIe Root Port that could be controlled. The supported_speeds field keeps the extra reserved zero at the least significant bit to match the Link Capabilities 2 Register layout. An attempt was made to store supported_speeds field into the struct pci_bus as an intersection of both ends of the Link, however, the subordinate struct pci_bus is not available early enough. The Target Speed quirk (in pcie_failed_link_retrain()) can run either during initial scan or later, requiring it to use the API provided by the PCIe bandwidth controller to set the Target Link Speed in order to co-exist with the bandwidth controller. When the Target Speed quirk is calling the bandwidth controller during initial scan, the struct pci_bus is not yet initialized. As such, storing supported_speeds into the struct pci_bus is not viable. Suggested-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20241018144755.7875-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: move pcie_get_supported_speeds() decl to drivers/pci/pci.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-03-20 16:33:56 +00:00
u8 pcie_get_supported_speeds(struct pci_dev *dev);
PCI: Add pci_speed_string() Add pci_speed_string() to return a text description of the supplied bus or link speed. The slot code previously used the private pci_bus_speed_strings[] array for this purpose, but adding this interface will enable us to consolidate similar code elsewhere. Export pcie_link_speed[] and pci_speed_string() so they can be used by modules. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-02-28 21:02:03 +00:00
const char *pci_speed_string(enum pci_bus_speed speed);
PCI: Check for PCIe Link downtraining When both ends of a PCIe Link are capable of a higher bandwidth than is currently in use, the Link is said to be "downtrained". A downtrained Link may indicate hardware or configuration problems in the system, but it's hard to identify such Links from userspace. Refactor pcie_print_link_status() so it continues to always print PCIe bandwidth information, as several NIC drivers desire. Add a new internal __pcie_print_link_status() to emit a message only when a device's bandwidth is constrained by the fabric and call it from the PCI core for all devices, which identifies all downtrained Links. It also emits messages for a few cases that are technically not downtrained, such as a x4 device in an open-ended x1 slot. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> [bhelgaas: changelog, move __pcie_print_link_status() declaration to drivers/pci/, rename pcie_check_upstream_link() to pcie_report_downtraining()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-08-06 23:25:35 +00:00
void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
PCI/LINK: Deduplicate bandwidth reports for multi-function devices If a multi-function device's bandwidth is already limited when it is enumerated, a message is logged only for function 0. By contrast, when downtraining occurs after enumeration, a message is logged for all functions. That's because the former uses pcie_report_downtraining(), whereas the latter uses __pcie_print_link_status() (which doesn't filter functions != 0). I am seeing this happen on a MacBookPro9,1 with a GPU (function 0) and an integrated HDA controller (function 1). Avoid this incongruence by calling pcie_report_downtraining() in both cases. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alexandru Gagniuc <alex.gagniuc@dellteam.com>
2019-03-20 11:05:30 +00:00
void pcie_report_downtraining(struct pci_dev *dev);
PCI: Refactor pcie_update_link_speed() JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: e93d9fcfd7dc643eb5fce43053774d27bea2b263 commit e93d9fcfd7dc643eb5fce43053774d27bea2b263 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:50 2024 +0300 PCI: Refactor pcie_update_link_speed() pcie_update_link_speed() is passed the Link Status register but not all callers have that value at hand nor need the value. Refactor pcie_update_link_speed() to include reading the Link Status register and create __pcie_update_link_speed() which can be used by the hotplug code that has the register value at hand beforehand (and needs the value for other purposes). Link: https://lore.kernel.org/r/20241018144755.7875-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-03-20 16:33:56 +00:00
static inline void __pcie_update_link_speed(struct pci_bus *bus, u16 linksta)
{
bus->cur_bus_speed = pcie_link_speed[linksta & PCI_EXP_LNKSTA_CLS];
}
void pcie_update_link_speed(struct pci_bus *bus);
PCI: Add pcie_get_speed_cap() to find max supported link speed Add pcie_get_speed_cap() to find the max link speed supported by a device. Change max_link_speed_show() to use pcie_get_speed_cap(). Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: return speed directly instead of error and *speed, don't export outside drivers/pci] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
2018-03-30 12:44:05 +00:00
PCI: initialize and release SR-IOV capability If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:11 +00:00
/* Single Root I/O Virtualization */
struct pci_sriov {
PCI: Clean up whitespace in linux/pci.h, pci/pci.h Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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 */
PCI/IOV: Use VF0 cached config registers for other VFs Cache some config data from VF0 and use it for all other VFs instead of reading it from the config space of each VF. We assume these items are the same across all associated VFs: Revision ID Class Code Subsystem Vendor ID Subsystem ID This is an optimization when enabling SR-IOV on a device with many VFs. Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de> [bhelgaas: changelog, simplify comments, remove unused "device", test CONFIG_PCI_IOV instead of CONFIG_PCI_ATS, rename functions] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
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 */
PCI: Clean up whitespace in linux/pci.h, pci/pci.h Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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 */
[pci] PCI: Add reserved fields to 'struct pci_sriov' Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: RHEL-only The kernel structure 'pci_sriov' is a kABI protected symbol so this patch puts in place reserved member slot entries for future use. Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-14 20:33:01 +00:00
RH_KABI_RESERVE(1)
RH_KABI_RESERVE(2)
RH_KABI_RESERVE(3)
RH_KABI_RESERVE(4)
RH_KABI_RESERVE(5)
RH_KABI_RESERVE(6)
RH_KABI_RESERVE(7)
RH_KABI_RESERVE(8)
PCI: initialize and release SR-IOV capability If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:11 +00:00
};
PCI/DOE: Create mailboxes on device enumeration JIRA: https://issues.redhat.com/browse/RHEL-23582 Currently a DOE instance cannot be shared by multiple drivers because each driver creates its own pci_doe_mb struct for a given DOE instance. For the same reason a DOE instance cannot be shared between the PCI core and a driver. Moreover, finding out which protocols a DOE instance supports requires creating a pci_doe_mb for it. If a device has multiple DOE instances, a driver looking for a specific protocol may need to create a pci_doe_mb for each of the device's DOE instances and then destroy those which do not support the desired protocol. That's obviously an inefficient way to do things. Overcome these issues by creating mailboxes in the PCI core on device enumeration. Provide a pci_find_doe_mailbox() API call to allow drivers to get a pci_doe_mb for a given (pci_dev, vendor, protocol) triple. This API is modeled after pci_find_capability() and can later be amended with a pci_find_next_doe_mailbox() call to iterate over all mailboxes of a given pci_dev which support a specific protocol. On removal, destroy the mailboxes in pci_destroy_dev(), after the driver is unbound. This allows drivers to use DOE in their ->remove() hook. On surprise removal, cancel ongoing DOE exchanges and prevent new ones from being scheduled. Thereby ensure that a hot-removed device doesn't needlessly wait for a running exchange to time out. Tested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ming Li <ming4.li@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/40a6f973f72ef283d79dd55e7e6fddc7481199af.1678543498.git.lukas@wunner.de Signed-off-by: Dan Williams <dan.j.williams@intel.com> (cherry picked from commit ac04840350e2c21a17d867b262a1586603b87a92) Signed-off-by: John W. Linville <linville@redhat.com>
2023-03-11 14:40:12 +00:00
#ifdef CONFIG_PCI_DOE
void pci_doe_init(struct pci_dev *pdev);
void pci_doe_destroy(struct pci_dev *pdev);
void pci_doe_disconnected(struct pci_dev *pdev);
#else
static inline void pci_doe_init(struct pci_dev *pdev) { }
static inline void pci_doe_destroy(struct pci_dev *pdev) { }
static inline void pci_doe_disconnected(struct pci_dev *pdev) { }
#endif
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
/**
* pci_dev_set_io_state - Set the new error state if possible.
*
PCI: Fix kernel-doc formatting Fix kernel-doc formatting throughout drivers/pci and related include files. No change to functionality intended. Check for warnings: $ find include drivers/pci -type f -path "*pci*.[ch]" | xargs scripts/kernel-doc -none [bhelgaas: squashed to one commit] Link: https://lore.kernel.org/r/20210509030237.368540-1-kw@linux.com Link: https://lore.kernel.org/r/20210703151306.1922450-1-kw@linux.com Link: https://lore.kernel.org/r/20210703151306.1922450-2-kw@linux.com Link: https://lore.kernel.org/r/20210703151306.1922450-3-kw@linux.com Link: https://lore.kernel.org/r/20210703151306.1922450-4-kw@linux.com Link: https://lore.kernel.org/r/20210703151306.1922450-5-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
*
PCI: hotplug: Allow marking devices as disconnected during bind/unbind Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2179137 Upstream Status: 74ff8864cc842be994853095dba6db48e716400a commit 74ff8864cc842be994853095dba6db48e716400a Author: Lukas Wunner <lukas@wunner.de> Date: Fri Jan 20 10:19:02 2023 +0100 PCI: hotplug: Allow marking devices as disconnected during bind/unbind On surprise removal, pciehp_unconfigure_device() and acpiphp's trim_stale_devices() call pci_dev_set_disconnected() to mark removed devices as permanently offline. Thereby, the PCI core and drivers know to skip device accesses. However pci_dev_set_disconnected() takes the device_lock and thus waits for a concurrent driver bind or unbind to complete. As a result, the driver's ->probe and ->remove hooks have no chance to learn that the device is gone. That doesn't make any sense, so drop the device_lock and instead use atomic xchg() and cmpxchg() operations to update the device state. As a byproduct, an AB-BA deadlock reported by Anatoli is fixed which occurs on surprise removal with AER concurrently performing a bus reset. AER bus reset: INFO: task irq/26-aerdrv:95 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule rwsem_down_write_slowpath down_write_nested pciehp_reset_slot # acquires reset_lock pci_reset_hotplug_slot pci_slot_reset # acquires device_lock pci_bus_error_reset aer_root_reset pcie_do_recovery aer_process_err_devices aer_isr pciehp surprise removal: INFO: task irq/26-pciehp:96 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule_preempt_disabled __mutex_lock mutex_lock_nested pci_dev_set_disconnected # acquires device_lock pci_walk_bus pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist # acquires reset_lock Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590 Fixes: a6bd101b8f84 ("PCI: Unify device inaccessible") Link: https://lore.kernel.org/r/3dc88ea82bdc0e37d9000e413d5ebce481cbd629.1674205689.git.lukas@wunner.de Reported-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.20+ Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-03-29 14:56:44 +00:00
* If the device is experiencing perm_failure, it has to remain in that state.
* Any other transition is allowed.
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
*
* 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)
{
PCI: hotplug: Allow marking devices as disconnected during bind/unbind Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2179137 Upstream Status: 74ff8864cc842be994853095dba6db48e716400a commit 74ff8864cc842be994853095dba6db48e716400a Author: Lukas Wunner <lukas@wunner.de> Date: Fri Jan 20 10:19:02 2023 +0100 PCI: hotplug: Allow marking devices as disconnected during bind/unbind On surprise removal, pciehp_unconfigure_device() and acpiphp's trim_stale_devices() call pci_dev_set_disconnected() to mark removed devices as permanently offline. Thereby, the PCI core and drivers know to skip device accesses. However pci_dev_set_disconnected() takes the device_lock and thus waits for a concurrent driver bind or unbind to complete. As a result, the driver's ->probe and ->remove hooks have no chance to learn that the device is gone. That doesn't make any sense, so drop the device_lock and instead use atomic xchg() and cmpxchg() operations to update the device state. As a byproduct, an AB-BA deadlock reported by Anatoli is fixed which occurs on surprise removal with AER concurrently performing a bus reset. AER bus reset: INFO: task irq/26-aerdrv:95 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule rwsem_down_write_slowpath down_write_nested pciehp_reset_slot # acquires reset_lock pci_reset_hotplug_slot pci_slot_reset # acquires device_lock pci_bus_error_reset aer_root_reset pcie_do_recovery aer_process_err_devices aer_isr pciehp surprise removal: INFO: task irq/26-pciehp:96 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule_preempt_disabled __mutex_lock mutex_lock_nested pci_dev_set_disconnected # acquires device_lock pci_walk_bus pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist # acquires reset_lock Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590 Fixes: a6bd101b8f84 ("PCI: Unify device inaccessible") Link: https://lore.kernel.org/r/3dc88ea82bdc0e37d9000e413d5ebce481cbd629.1674205689.git.lukas@wunner.de Reported-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.20+ Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-03-29 14:56:44 +00:00
pci_channel_state_t old;
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
switch (new) {
case pci_channel_io_perm_failure:
PCI: hotplug: Allow marking devices as disconnected during bind/unbind Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2179137 Upstream Status: 74ff8864cc842be994853095dba6db48e716400a commit 74ff8864cc842be994853095dba6db48e716400a Author: Lukas Wunner <lukas@wunner.de> Date: Fri Jan 20 10:19:02 2023 +0100 PCI: hotplug: Allow marking devices as disconnected during bind/unbind On surprise removal, pciehp_unconfigure_device() and acpiphp's trim_stale_devices() call pci_dev_set_disconnected() to mark removed devices as permanently offline. Thereby, the PCI core and drivers know to skip device accesses. However pci_dev_set_disconnected() takes the device_lock and thus waits for a concurrent driver bind or unbind to complete. As a result, the driver's ->probe and ->remove hooks have no chance to learn that the device is gone. That doesn't make any sense, so drop the device_lock and instead use atomic xchg() and cmpxchg() operations to update the device state. As a byproduct, an AB-BA deadlock reported by Anatoli is fixed which occurs on surprise removal with AER concurrently performing a bus reset. AER bus reset: INFO: task irq/26-aerdrv:95 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule rwsem_down_write_slowpath down_write_nested pciehp_reset_slot # acquires reset_lock pci_reset_hotplug_slot pci_slot_reset # acquires device_lock pci_bus_error_reset aer_root_reset pcie_do_recovery aer_process_err_devices aer_isr pciehp surprise removal: INFO: task irq/26-pciehp:96 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule_preempt_disabled __mutex_lock mutex_lock_nested pci_dev_set_disconnected # acquires device_lock pci_walk_bus pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist # acquires reset_lock Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590 Fixes: a6bd101b8f84 ("PCI: Unify device inaccessible") Link: https://lore.kernel.org/r/3dc88ea82bdc0e37d9000e413d5ebce481cbd629.1674205689.git.lukas@wunner.de Reported-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.20+ Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-03-29 14:56:44 +00:00
xchg(&dev->error_state, pci_channel_io_perm_failure);
return true;
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
case pci_channel_io_frozen:
PCI: hotplug: Allow marking devices as disconnected during bind/unbind Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2179137 Upstream Status: 74ff8864cc842be994853095dba6db48e716400a commit 74ff8864cc842be994853095dba6db48e716400a Author: Lukas Wunner <lukas@wunner.de> Date: Fri Jan 20 10:19:02 2023 +0100 PCI: hotplug: Allow marking devices as disconnected during bind/unbind On surprise removal, pciehp_unconfigure_device() and acpiphp's trim_stale_devices() call pci_dev_set_disconnected() to mark removed devices as permanently offline. Thereby, the PCI core and drivers know to skip device accesses. However pci_dev_set_disconnected() takes the device_lock and thus waits for a concurrent driver bind or unbind to complete. As a result, the driver's ->probe and ->remove hooks have no chance to learn that the device is gone. That doesn't make any sense, so drop the device_lock and instead use atomic xchg() and cmpxchg() operations to update the device state. As a byproduct, an AB-BA deadlock reported by Anatoli is fixed which occurs on surprise removal with AER concurrently performing a bus reset. AER bus reset: INFO: task irq/26-aerdrv:95 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule rwsem_down_write_slowpath down_write_nested pciehp_reset_slot # acquires reset_lock pci_reset_hotplug_slot pci_slot_reset # acquires device_lock pci_bus_error_reset aer_root_reset pcie_do_recovery aer_process_err_devices aer_isr pciehp surprise removal: INFO: task irq/26-pciehp:96 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule_preempt_disabled __mutex_lock mutex_lock_nested pci_dev_set_disconnected # acquires device_lock pci_walk_bus pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist # acquires reset_lock Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590 Fixes: a6bd101b8f84 ("PCI: Unify device inaccessible") Link: https://lore.kernel.org/r/3dc88ea82bdc0e37d9000e413d5ebce481cbd629.1674205689.git.lukas@wunner.de Reported-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.20+ Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-03-29 14:56:44 +00:00
old = cmpxchg(&dev->error_state, pci_channel_io_normal,
pci_channel_io_frozen);
return old != pci_channel_io_perm_failure;
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
case pci_channel_io_normal:
PCI: hotplug: Allow marking devices as disconnected during bind/unbind Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2179137 Upstream Status: 74ff8864cc842be994853095dba6db48e716400a commit 74ff8864cc842be994853095dba6db48e716400a Author: Lukas Wunner <lukas@wunner.de> Date: Fri Jan 20 10:19:02 2023 +0100 PCI: hotplug: Allow marking devices as disconnected during bind/unbind On surprise removal, pciehp_unconfigure_device() and acpiphp's trim_stale_devices() call pci_dev_set_disconnected() to mark removed devices as permanently offline. Thereby, the PCI core and drivers know to skip device accesses. However pci_dev_set_disconnected() takes the device_lock and thus waits for a concurrent driver bind or unbind to complete. As a result, the driver's ->probe and ->remove hooks have no chance to learn that the device is gone. That doesn't make any sense, so drop the device_lock and instead use atomic xchg() and cmpxchg() operations to update the device state. As a byproduct, an AB-BA deadlock reported by Anatoli is fixed which occurs on surprise removal with AER concurrently performing a bus reset. AER bus reset: INFO: task irq/26-aerdrv:95 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule rwsem_down_write_slowpath down_write_nested pciehp_reset_slot # acquires reset_lock pci_reset_hotplug_slot pci_slot_reset # acquires device_lock pci_bus_error_reset aer_root_reset pcie_do_recovery aer_process_err_devices aer_isr pciehp surprise removal: INFO: task irq/26-pciehp:96 blocked for more than 120 seconds. Tainted: G W 6.2.0-rc3-custom-norework-jan11+ schedule_preempt_disabled __mutex_lock mutex_lock_nested pci_dev_set_disconnected # acquires device_lock pci_walk_bus pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist # acquires reset_lock Link: https://bugzilla.kernel.org/show_bug.cgi?id=215590 Fixes: a6bd101b8f84 ("PCI: Unify device inaccessible") Link: https://lore.kernel.org/r/3dc88ea82bdc0e37d9000e413d5ebce481cbd629.1674205689.git.lukas@wunner.de Reported-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.20+ Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-03-29 14:56:44 +00:00
old = cmpxchg(&dev->error_state, pci_channel_io_frozen,
pci_channel_io_normal);
return old != pci_channel_io_perm_failure;
default:
return false;
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
}
}
PCI: Add device disconnected state Add a new state to pci_dev to be set when it is unexpectedly disconnected. The PCI driver tear down functions can observe this new device state so they may skip operations that will fail. The pciehp and pcie-dpc drivers are aware when the link is down, so these set the flag when their handlers detect the device is disconnected. Tested-by: Krishna Dhulipala <krishnad@fb.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Wei Zhang <wzhang@fb.com>
2017-03-30 03:48:59 +00:00
static inline int pci_dev_set_disconnected(struct pci_dev *dev, void *unused)
{
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
pci_dev_set_io_state(dev, pci_channel_io_perm_failure);
PCI/DOE: Create mailboxes on device enumeration JIRA: https://issues.redhat.com/browse/RHEL-23582 Currently a DOE instance cannot be shared by multiple drivers because each driver creates its own pci_doe_mb struct for a given DOE instance. For the same reason a DOE instance cannot be shared between the PCI core and a driver. Moreover, finding out which protocols a DOE instance supports requires creating a pci_doe_mb for it. If a device has multiple DOE instances, a driver looking for a specific protocol may need to create a pci_doe_mb for each of the device's DOE instances and then destroy those which do not support the desired protocol. That's obviously an inefficient way to do things. Overcome these issues by creating mailboxes in the PCI core on device enumeration. Provide a pci_find_doe_mailbox() API call to allow drivers to get a pci_doe_mb for a given (pci_dev, vendor, protocol) triple. This API is modeled after pci_find_capability() and can later be amended with a pci_find_next_doe_mailbox() call to iterate over all mailboxes of a given pci_dev which support a specific protocol. On removal, destroy the mailboxes in pci_destroy_dev(), after the driver is unbound. This allows drivers to use DOE in their ->remove() hook. On surprise removal, cancel ongoing DOE exchanges and prevent new ones from being scheduled. Thereby ensure that a hot-removed device doesn't needlessly wait for a running exchange to time out. Tested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ming Li <ming4.li@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/40a6f973f72ef283d79dd55e7e6fddc7481199af.1678543498.git.lukas@wunner.de Signed-off-by: Dan Williams <dan.j.williams@intel.com> (cherry picked from commit ac04840350e2c21a17d867b262a1586603b87a92) Signed-off-by: John W. Linville <linville@redhat.com>
2023-03-11 14:40:12 +00:00
pci_doe_disconnected(dev);
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
PCI: Add device disconnected state Add a new state to pci_dev to be set when it is unexpectedly disconnected. The PCI driver tear down functions can observe this new device state so they may skip operations that will fail. The pciehp and pcie-dpc drivers are aware when the link is down, so these set the flag when their handlers detect the device is disconnected. Tested-by: Krishna Dhulipala <krishnad@fb.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Wei Zhang <wzhang@fb.com>
2017-03-30 03:48:59 +00:00
return 0;
}
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
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
PCI: Unify device inaccessible Bring surprise removals and permanent failures together so we no longer need separate flags. The implementation enforces that error handling will not be able to override a surprise removal's permanent channel failure. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:16 +00:00
PCI: Fix is_added/is_busmaster race condition When a PCI device is detected, pdev->is_added is set to 1 and proc and sysfs entries are created. When the device is removed, pdev->is_added is checked for one and then device is detached with clearing of proc and sys entries and at end, pdev->is_added is set to 0. is_added and is_busmaster are bit fields in pci_dev structure sharing same memory location. A strange issue was observed with multiple removal and rescan of a PCIe NVMe device using sysfs commands where is_added flag was observed as zero instead of one while removing device and proc,sys entries are not cleared. This causes issue in later device addition with warning message "proc_dir_entry" already registered. Debugging revealed a race condition between the PCI core setting the is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue setting the is_busmaster bit in pci_set_master(). As these fields are not handled atomically, that clears the is_added bit. Move the is_added bit to a separate private flag variable and use atomic functions to set and retrieve the device addition state. This avoids the race because is_added no longer shares a memory location with is_busmaster. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283 Signed-off-by: Hari Vyas <hari.vyas@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
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);
}
PCI/AER: Expose internal API for obtaining AER information Export some common AER functions and structures for other PCI core drivers to use. Since this is making the function externally visible inside the PCI core, prepend "aer_" to the function name. Signed-off-by: Keith Busch <keith.busch@intel.com> [bhelgaas: move AER declarations from linux/aer.h to drivers/pci/pci.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Oza Pawandeep <poza@codeaurora.org>
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 */
PCI/AER: Generalize TLP Header Log reading JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: 0a5a46a6a61be7b63c12c18495d427f91f3662a9 commit 0a5a46a6a61be7b63c12c18495d427f91f3662a9 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Tue Feb 6 15:57:15 2024 +0200 PCI/AER: Generalize TLP Header Log reading Both AER and DPC RP PIO provide TLP Header Log registers (PCIe r6.1 secs 7.8.4 & 7.9.14) to convey error diagnostics but the struct is named after AER as the struct aer_header_log_regs. Also, not all places that handle TLP Header Log use the struct and the struct members are named individually. Generalize the struct name and members, and use it consistently where TLP Header Log is being handled so that a pcie_read_tlp_log() helper can be easily added. Link: https://lore.kernel.org/r/20240206135717.8565-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: drop ixgbe changes for now, tidy whitespace] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-23 16:45:16 +00:00
struct pcie_tlp_log tlp; /* TLP Header */
PCI/AER: Expose internal API for obtaining AER information Export some common AER functions and structures for other PCI core drivers to use. Since this is making the function externally visible inside the PCI core, prepend "aer_" to the function name. Signed-off-by: Keith Busch <keith.busch@intel.com> [bhelgaas: move AER declarations from linux/aer.h to drivers/pci/pci.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Oza Pawandeep <poza@codeaurora.org>
2018-07-19 21:16:55 +00:00
};
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 */
PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities() Extend support for Root Complex Event Collectors by decoding and caching the RCEC Endpoint Association Extended Capabilities when enumerating. Use that cached information for later error source reporting. See PCIe r5.0, sec 7.9.10. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-4-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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
PCI/DPC: Save and restore config state This patch provides DPC save and restore capabilities. This is necessary for the driver to observe DPC events in the event the configuration space needs to be restored after a reset. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
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);
PCI/DPC: Cache DPC capabilities in pci_init_capabilities() Since Error Disconnect Recover needs to use DPC error handling routines even if the OS doesn't have control of DPC, move the initalization and caching of DPC capabilities from the DPC driver to pci_init_capabilities(). Link: https://lore.kernel.org/r/5888380657c8b9551675b5dbd48e370e4fd2703d.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: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);
PCI/DPC: Save and restore config state This patch provides DPC save and restore capabilities. This is necessary for the driver to observe DPC events in the event the configuration space needs to be restored after a reset. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:08 +00:00
#else
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void pci_save_dpc_state(struct pci_dev *dev) { }
static inline void pci_restore_dpc_state(struct pci_dev *dev) { }
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; }
PCI/DPC: Save and restore config state This patch provides DPC save and restore capabilities. This is necessary for the driver to observe DPC events in the event the configuration space needs to be restored after a reset. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
2018-09-20 16:27:08 +00:00
#endif
PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities() Extend support for Root Complex Event Collectors by decoding and caching the RCEC Endpoint Association Extended Capabilities when enumerating. Use that cached information for later error source reporting. See PCIe r5.0, sec 7.9.10. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-4-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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);
PCI/ERR: Add pcie_link_rcec() to associate RCiEPs A Root Complex Event Collector terminates error and PME messages from associated RCiEPs. Use the RCEC Endpoint Association Extended Capability to identify associated RCiEPs. Link the associated RCiEPs as the RCECs are enumerated. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-12-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21 00:10:32 +00:00
void pcie_link_rcec(struct pci_dev *rcec);
PCI/AER: Add pcie_walk_rcec() to RCEC AER handling Root Complex Event Collectors (RCEC) appear as peers to Root Ports and also have the AER capability. In addition, actions need to be taken for associated RCiEPs. In such cases the RCECs will need to be walked in order to find and act upon their respective RCiEPs. Extend the existing ability to link the RCECs with a walking function pcie_walk_rcec(). Add RCEC support to the current AER service driver and attach the AER service driver to the RCEC device. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-14-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2020-11-21 00:10:34 +00:00
void pcie_walk_rcec(struct pci_dev *rcec,
int (*cb)(struct pci_dev *, void *),
void *userdata);
PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities() Extend support for Root Complex Event Collectors by decoding and caching the RCEC Endpoint Association Extended Capabilities when enumerating. Use that cached information for later error source reporting. See PCIe r5.0, sec 7.9.10. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-4-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21 00:10:24 +00:00
#else
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void pci_rcec_init(struct pci_dev *dev) { }
static inline void pci_rcec_exit(struct pci_dev *dev) { }
static inline void pcie_link_rcec(struct pci_dev *rcec) { }
PCI/AER: Add pcie_walk_rcec() to RCEC AER handling Root Complex Event Collectors (RCEC) appear as peers to Root Ports and also have the AER capability. In addition, actions need to be taken for associated RCiEPs. In such cases the RCECs will need to be walked in order to find and act upon their respective RCiEPs. Extend the existing ability to link the RCECs with a walking function pcie_walk_rcec(). Add RCEC support to the current AER service driver and attach the AER service driver to the RCEC device. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-14-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2020-11-21 00:10:34 +00:00
static inline void pcie_walk_rcec(struct pci_dev *rcec,
int (*cb)(struct pci_dev *, void *),
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
void *userdata) { }
PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities() Extend support for Root Complex Event Collectors by decoding and caching the RCEC Endpoint Association Extended Capabilities when enumerating. Use that cached information for later error source reporting. See PCIe r5.0, sec 7.9.10. Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20201121001036.8560-4-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21 00:10:24 +00:00
#endif
PCI: Enable ATS at the device state restore During S3 or S4 resume or PCI reset, ATS regs aren't restored correctly. This patch enables ATS at the device state restore if PCI device has ATS capability. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-12-17 13:24:40 +00:00
#ifdef CONFIG_PCI_ATS
PCI: Make pci_ats_init() private This interface: void pci_ats_init(struct pci_dev *dev); is only used in drivers/pci/ and does not need to be seen by the rest of the kernel. Move it to drivers/pci/pci.h so it's private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-9-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:45 +00:00
/* Address Translation Service */
void pci_ats_init(struct pci_dev *dev);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
void pci_restore_ats_state(struct pci_dev *dev);
PCI: Enable ATS at the device state restore During S3 or S4 resume or PCI reset, ATS regs aren't restored correctly. This patch enables ATS at the device state restore if PCI device has ATS capability. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-12-17 13:24:40 +00:00
#else
PCI: Make pci_ats_init() private This interface: void pci_ats_init(struct pci_dev *dev); is only used in drivers/pci/ and does not need to be seen by the rest of the kernel. Move it to drivers/pci/pci.h so it's private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-9-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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) { }
PCI: Enable ATS at the device state restore During S3 or S4 resume or PCI reset, ATS regs aren't restored correctly. This patch enables ATS at the device state restore if PCI device has ATS capability. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-12-17 13:24:40 +00:00
#endif /* CONFIG_PCI_ATS */
PCI/ATS: Cache PRI Capability offset Previously each PRI interface searched for the PRI Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pri_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/0c5495d376faf6dbb8eb2165204c474438aaae65.156 7029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-5-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:45 +00:00
#ifdef CONFIG_PCI_PRI
void pci_pri_init(struct pci_dev *dev);
PCI/ATS: Make pci_restore_pri_state(), pci_restore_pasid_state() private These interfaces: void pci_restore_pri_state(struct pci_dev *pdev); void pci_restore_pasid_state(struct pci_dev *pdev); are only used in drivers/pci and do not need to be seen by the rest of the kernel. Most them to drivers/pci/pci.h so they're private to the PCI subsystem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2019-10-09 21:47:15 +00:00
void pci_restore_pri_state(struct pci_dev *pdev);
PCI/ATS: Cache PRI Capability offset Previously each PRI interface searched for the PRI Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pri_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/0c5495d376faf6dbb8eb2165204c474438aaae65.156 7029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-5-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:45 +00:00
#else
static inline void pci_pri_init(struct pci_dev *dev) { }
PCI/ATS: Make pci_restore_pri_state(), pci_restore_pasid_state() private These interfaces: void pci_restore_pri_state(struct pci_dev *pdev); void pci_restore_pasid_state(struct pci_dev *pdev); are only used in drivers/pci and do not need to be seen by the rest of the kernel. Most them to drivers/pci/pci.h so they're private to the PCI subsystem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2019-10-09 21:47:15 +00:00
static inline void pci_restore_pri_state(struct pci_dev *pdev) { }
PCI/ATS: Cache PRI Capability offset Previously each PRI interface searched for the PRI Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pri_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/0c5495d376faf6dbb8eb2165204c474438aaae65.156 7029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-5-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:45 +00:00
#endif
PCI/ATS: Cache PASID Capability offset Previously each PASID interface searched for the PASID Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pasid_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/4957778959fa34eab3e8b3065d1951989c61cb0f.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-6-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:46 +00:00
#ifdef CONFIG_PCI_PASID
void pci_pasid_init(struct pci_dev *dev);
PCI/ATS: Make pci_restore_pri_state(), pci_restore_pasid_state() private These interfaces: void pci_restore_pri_state(struct pci_dev *pdev); void pci_restore_pasid_state(struct pci_dev *pdev); are only used in drivers/pci and do not need to be seen by the rest of the kernel. Most them to drivers/pci/pci.h so they're private to the PCI subsystem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2019-10-09 21:47:15 +00:00
void pci_restore_pasid_state(struct pci_dev *pdev);
PCI/ATS: Cache PASID Capability offset Previously each PASID interface searched for the PASID Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pasid_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/4957778959fa34eab3e8b3065d1951989c61cb0f.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-6-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:46 +00:00
#else
static inline void pci_pasid_init(struct pci_dev *dev) { }
PCI/ATS: Make pci_restore_pri_state(), pci_restore_pasid_state() private These interfaces: void pci_restore_pri_state(struct pci_dev *pdev); void pci_restore_pasid_state(struct pci_dev *pdev); are only used in drivers/pci and do not need to be seen by the rest of the kernel. Most them to drivers/pci/pci.h so they're private to the PCI subsystem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2019-10-09 21:47:15 +00:00
static inline void pci_restore_pasid_state(struct pci_dev *pdev) { }
PCI/ATS: Cache PASID Capability offset Previously each PASID interface searched for the PASID Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pasid_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/4957778959fa34eab3e8b3065d1951989c61cb0f.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-6-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 19:31:46 +00:00
#endif
PCI: initialize and release SR-IOV capability If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:11 +00:00
#ifdef CONFIG_PCI_IOV
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Separate VF BAR updates from standard BAR updates Previously pci_update_resource() used the same code path for updating standard BARs and VF BARs in SR-IOV capabilities. Split the VF BAR update into a new pci_iov_update_resource() internal interface, which makes it simpler to compute the BAR address (we can get rid of pci_resource_bar() and pci_iov_resource_bar()). This patch: - Renames pci_update_resource() to pci_std_update_resource(), - Adds pci_iov_update_resource(), - Makes pci_update_resource() a wrapper that calls the appropriate one, No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
2016-11-28 15:15:52 +00:00
void pci_iov_update_resource(struct pci_dev *dev, int resno);
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI/IOV: Add sysfs MSI-X vector assignment interface A typical cloud provider SR-IOV use case is to create many VFs for use by guest VMs. The VFs may not be assigned to a VM until a customer requests a VM of a certain size, e.g., number of CPUs. A VF may need MSI-X vectors proportional to the number of CPUs in the VM, but there is no standard way to change the number of MSI-X vectors supported by a VF. Some Mellanox ConnectX devices support dynamic assignment of MSI-X vectors to SR-IOV VFs. This can be done by the PF driver after VFs are enabled, and it can be done without affecting VFs that are already in use. The hardware supports a limited pool of MSI-X vectors that can be assigned to the PF or to individual VFs. This is device-specific behavior that requires support in the PF driver. Add a read-only "sriov_vf_total_msix" sysfs file for the PF and a writable "sriov_vf_msix_count" file for each VF. Management software may use these to learn how many MSI-X vectors are available and to dynamically assign them to VFs before the VFs are passed through to a VM. If the PF driver implements the ->sriov_get_vf_total_msix() callback, "sriov_vf_total_msix" contains the total number of MSI-X vectors available for distribution among VFs. If no driver is bound to the VF, writing "N" to "sriov_vf_msix_count" uses the PF driver ->sriov_set_msix_vec_count() callback to assign "N" MSI-X vectors to the VF. When a VF driver subsequently reads the MSI-X Message Control register, it will see the new Table Size "N". Link: https://lore.kernel.org/linux-pci/20210314124256.70253-2-leon@kernel.org Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
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;
PCI: initialize and release SR-IOV capability If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:11 +00:00
#else
static inline int pci_iov_init(struct pci_dev *dev)
{
return -ENODEV;
}
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void pci_iov_release(struct pci_dev *dev) { }
static inline void pci_iov_remove(struct pci_dev *dev) { }
static inline void pci_restore_iov_state(struct pci_dev *dev) { }
PCI: reserve bus range for SR-IOV device Reserve the bus number range used by the Virtual Function when pcibios_assign_all_busses() returns true. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:13 +00:00
static inline int pci_iov_bus_range(struct pci_bus *bus)
{
return 0;
}
PCI: support the ATS capability The PCIe ATS capability makes the Endpoint be able to request the DMA address translation from the IOMMU and cache the translation in the device side, thus alleviate IOMMU pressure and improve the hardware performance in the I/O virtualization environment. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-05-18 05:51:32 +00:00
PCI: initialize and release SR-IOV capability If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-03-20 03:25:11 +00:00
#endif /* CONFIG_PCI_IOV */
PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-07 22:39:50 +00:00
#ifdef CONFIG_PCIE_PTM
PCI/PTM: Consolidate PTM interface declarations Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2135902 Upstream Status: d736d292bba2c5225cb76cd4e04d0e9d00f22498 commit d736d292bba2c5225cb76cd4e04d0e9d00f22498 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Sep 9 15:25:04 2022 -0500 PCI/PTM: Consolidate PTM interface declarations Consolidate all the PTM-related declarations in drivers/pci/pci.h. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-9-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-10-18 23:55:59 +00:00
void pci_ptm_init(struct pci_dev *dev);
PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-07 22:39:50 +00:00
void pci_save_ptm_state(struct pci_dev *dev);
void pci_restore_ptm_state(struct pci_dev *dev);
PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm() Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2135902 Upstream Status: e8bdc5ea481638e0a4fd5639050d2b170417f493 commit e8bdc5ea481638e0a4fd5639050d2b170417f493 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Sep 9 15:25:00 2022 -0500 PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm() We disable PTM during suspend because that allows some Root Ports to enter lower-power PM states, which means we also need to disable PTM for all downstream devices. Add pci_suspend_ptm() and pci_resume_ptm() for this purpose. pci_enable_ptm() and pci_disable_ptm() are for drivers to use to enable or disable PTM. They use dev->ptm_enabled to keep track of whether PTM should be enabled. pci_suspend_ptm() and pci_resume_ptm() are PCI core-internal functions to temporarily disable PTM during suspend and (depending on dev->ptm_enabled) re-enable PTM during resume. Enable/disable/suspend/resume all use internal __pci_enable_ptm() and __pci_disable_ptm() functions that only update the PTM Control register. Outline: pci_enable_ptm(struct pci_dev *dev) { __pci_enable_ptm(dev); dev->ptm_enabled = 1; pci_ptm_info(dev); } pci_disable_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) { __pci_disable_ptm(dev); dev->ptm_enabled = 0; } } pci_suspend_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_disable_ptm(dev); } pci_resume_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_enable_ptm(dev); } Nothing currently calls pci_resume_ptm(); the suspend path saves the PTM state before disabling PTM, so the PTM state restore in the resume path implicitly re-enables it. A future change will use pci_resume_ptm() to fix some problems with this approach. Link: https://lore.kernel.org/r/20220909202505.314195-5-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-10-18 23:40:36 +00:00
void pci_suspend_ptm(struct pci_dev *dev);
void pci_resume_ptm(struct pci_dev *dev);
PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-07 22:39:50 +00:00
#else
PCI/PTM: Consolidate PTM interface declarations Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2135902 Upstream Status: d736d292bba2c5225cb76cd4e04d0e9d00f22498 commit d736d292bba2c5225cb76cd4e04d0e9d00f22498 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Sep 9 15:25:04 2022 -0500 PCI/PTM: Consolidate PTM interface declarations Consolidate all the PTM-related declarations in drivers/pci/pci.h. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-9-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-10-18 23:55:59 +00:00
static inline void pci_ptm_init(struct pci_dev *dev) { }
PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-07 22:39:50 +00:00
static inline void pci_save_ptm_state(struct pci_dev *dev) { }
static inline void pci_restore_ptm_state(struct pci_dev *dev) { }
PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm() Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2135902 Upstream Status: e8bdc5ea481638e0a4fd5639050d2b170417f493 commit e8bdc5ea481638e0a4fd5639050d2b170417f493 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Sep 9 15:25:00 2022 -0500 PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm() We disable PTM during suspend because that allows some Root Ports to enter lower-power PM states, which means we also need to disable PTM for all downstream devices. Add pci_suspend_ptm() and pci_resume_ptm() for this purpose. pci_enable_ptm() and pci_disable_ptm() are for drivers to use to enable or disable PTM. They use dev->ptm_enabled to keep track of whether PTM should be enabled. pci_suspend_ptm() and pci_resume_ptm() are PCI core-internal functions to temporarily disable PTM during suspend and (depending on dev->ptm_enabled) re-enable PTM during resume. Enable/disable/suspend/resume all use internal __pci_enable_ptm() and __pci_disable_ptm() functions that only update the PTM Control register. Outline: pci_enable_ptm(struct pci_dev *dev) { __pci_enable_ptm(dev); dev->ptm_enabled = 1; pci_ptm_info(dev); } pci_disable_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) { __pci_disable_ptm(dev); dev->ptm_enabled = 0; } } pci_suspend_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_disable_ptm(dev); } pci_resume_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_enable_ptm(dev); } Nothing currently calls pci_resume_ptm(); the suspend path saves the PTM state before disabling PTM, so the PTM state restore in the resume path implicitly re-enables it. A future change will use pci_resume_ptm() to fix some problems with this approach. Link: https://lore.kernel.org/r/20220909202505.314195-5-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-10-18 23:40:36 +00:00
static inline void pci_suspend_ptm(struct pci_dev *dev) { }
static inline void pci_resume_ptm(struct pci_dev *dev) { }
PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume The PCI subsystem does not currently save and restore the configuration space for the Precision Time Measurement (PTM) Extended Capability leading to the possibility of the feature returning disabled on S3 resume. This has been observed on Intel Coffee Lake desktops. Add save/restore of the PTM control register. This saves the PTM Enable, Root Select, and Effective Granularity bits. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20201207223951.19667-1-david.e.box@linux.intel.com Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-07 22:39:50 +00:00
#endif
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
unsigned long pci_cardbus_resource_alignment(struct resource *);
PCI: make cardbus-bridge resources optional Allocate resources to cardbus bridge only after all other genuine resources requests are satisfied. Dont retry if resource allocation for cardbus-bridges fail. Signed-off-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-25 20:08:41 +00:00
PCI: fix pci_resource_alignment prototype This fixes the prototype for both pci_resource_alignment() and pci_sriov_resource_alignment(). Patch started as debugging effort from Cam Macdonell. Cc: Cam Macdonell <cam@cs.ualberta.ca> Cc: Avi Kivity <avi@redhat.com> [chrisw: add iov bits] Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-09-08 00:25:20 +00:00
static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
PCI: Remove "extern" from function declarations We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12 18:02:59 +00:00
struct resource *res)
PCI SR-IOV: correct broken resource alignment calculations An SR-IOV capable device includes an SR-IOV PCIe capability which describes the Virtual Function (VF) BAR requirements. A typical SR-IOV device can support multiple VFs whose BARs must be in a contiguous region, effectively an array of VF BARs. The BAR reports the size requirement for a single VF. We calculate the full range needed by simply multiplying the VF BAR size with the number of possible VFs and create a resource spanning the full range. This all seems sane enough except it artificially inflates the alignment requirement for the VF BAR. The VF BAR need only be aligned to the size of a single BAR not the contiguous range of VF BARs. This can cause us to fail to allocate resources for the BAR despite the fact that we actually have enough space. This patch adds a thin PCI specific layer over the generic resource_alignment() function which is aware of the special nature of VF BARs and does sorting and allocation based on the smaller alignment requirement. I recognize that while resource_alignment is generic, it's basically a PCI helper. An alternative to this patch is to add PCI VF BAR specific information to struct resource. I opted for the extra layer rather than adding such PCI specific information to struct resource. This does have the slight downside that we don't cache the BAR size and re-read for each alignment query (happens a small handful of times during boot for each VF BAR). Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Yu Zhao <yu.zhao@intel.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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
PCI: Clean up whitespace in linux/pci.h, pci/pci.h Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-02 19:21:37 +00:00
if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS)
PCI: make cardbus-bridge resources optional Allocate resources to cardbus bridge only after all other genuine resources requests are satisfied. Dont retry if resource allocation for cardbus-bridges fail. Signed-off-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-25 20:08:41 +00:00
return pci_cardbus_resource_alignment(res);
PCI SR-IOV: correct broken resource alignment calculations An SR-IOV capable device includes an SR-IOV PCIe capability which describes the Virtual Function (VF) BAR requirements. A typical SR-IOV device can support multiple VFs whose BARs must be in a contiguous region, effectively an array of VF BARs. The BAR reports the size requirement for a single VF. We calculate the full range needed by simply multiplying the VF BAR size with the number of possible VFs and create a resource spanning the full range. This all seems sane enough except it artificially inflates the alignment requirement for the VF BAR. The VF BAR need only be aligned to the size of a single BAR not the contiguous range of VF BARs. This can cause us to fail to allocate resources for the BAR despite the fact that we actually have enough space. This patch adds a thin PCI specific layer over the generic resource_alignment() function which is aware of the special nature of VF BARs and does sorting and allocation based on the smaller alignment requirement. I recognize that while resource_alignment is generic, it's basically a PCI helper. An alternative to this patch is to add PCI VF BAR specific information to struct resource. I opted for the extra layer rather than adding such PCI specific information to struct resource. This does have the slight downside that we don't cache the BAR size and re-read for each alignment query (happens a small handful of times during boot for each VF BAR). Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Yu Zhao <yu.zhao@intel.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-08-28 20:00:06 +00:00
return resource_alignment(res);
}
PCI: Cache ACS capability offset in device Currently the ACS capability is being looked up at a number of places. Read and store it once at enumeration so that it can be used by all later. No functional change intended. Link: https://lore.kernel.org/r/20200707224604.3737893-2-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-07-07 22:46:02 +00:00
void pci_acs_init(struct pci_dev *dev);
PCI: Hide ACS quirk declarations inside PCI core Move declarations for these functions: pci_dev_specific_acs_enabled() pci_dev_specific_enable_acs() from include/linux/pci.h to drivers/pci/pci.h because nothing outside the PCI core needs to use them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: Add device-specific ACS Redirect disable infrastructure Intel Sunrise Point (SPT) PCH hardware has an implementation of the ACS bits that does not comply with the PCIe standard. To deal with this we need device-specific quirks to disable ACS redirection. Add a new pci_dev_specific_disable_acs_redir() quirk and a new .disable_acs_redir() function pointer for use by non-compliant devices. No functional change intended. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: split to separate patch, move pci_dev_specific_disable_acs_redir() declarations to drivers/pci/pci.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2018-08-09 21:51:43 +00:00
int pci_dev_specific_disable_acs_redir(struct pci_dev *dev);
PCI: Use an error code with PCIe failed link retraining JIRA: https://issues.redhat.com/browse/RHEL-71363 Upstream Status: 59100eb248c0b15585affa546c7f6834b30eb5a4 commit 59100eb248c0b15585affa546c7f6834b30eb5a4 Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Fri Aug 9 14:25:02 2024 +0100 PCI: Use an error code with PCIe failed link retraining Given how the call place in pcie_wait_for_link_delay() got structured now, and that pcie_retrain_link() returns a potentially useful error code, convert pcie_failed_link_retrain() to return an error code rather than a boolean status, fixing handling at the call site mentioned. Update the other call site accordingly. Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'") Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.uk Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.5+ Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-10-09 15:07:21 +00:00
int pcie_failed_link_retrain(struct pci_dev *dev);
PCI: Hide ACS quirk declarations inside PCI core Move declarations for these functions: pci_dev_specific_acs_enabled() pci_dev_specific_enable_acs() from include/linux/pci.h to drivers/pci/pci.h because nothing outside the PCI core needs to use them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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;
}
PCI: Add device-specific ACS Redirect disable infrastructure Intel Sunrise Point (SPT) PCH hardware has an implementation of the ACS bits that does not comply with the PCIe standard. To deal with this we need device-specific quirks to disable ACS redirection. Add a new pci_dev_specific_disable_acs_redir() quirk and a new .disable_acs_redir() function pointer for use by non-compliant devices. No functional change intended. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: split to separate patch, move pci_dev_specific_disable_acs_redir() declarations to drivers/pci/pci.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2018-08-09 21:51:43 +00:00
static inline int pci_dev_specific_disable_acs_redir(struct pci_dev *dev)
{
return -ENOTTY;
}
PCI: Use an error code with PCIe failed link retraining JIRA: https://issues.redhat.com/browse/RHEL-71363 Upstream Status: 59100eb248c0b15585affa546c7f6834b30eb5a4 commit 59100eb248c0b15585affa546c7f6834b30eb5a4 Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Fri Aug 9 14:25:02 2024 +0100 PCI: Use an error code with PCIe failed link retraining Given how the call place in pcie_wait_for_link_delay() got structured now, and that pcie_retrain_link() returns a potentially useful error code, convert pcie_failed_link_retrain() to return an error code rather than a boolean status, fixing handling at the call site mentioned. Update the other call site accordingly. Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'") Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.uk Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.5+ Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-10-09 15:07:21 +00:00
static inline int pcie_failed_link_retrain(struct pci_dev *dev)
PCI: Work around PCIe link training failures JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: a89c82249c3763780522f763dd2e615e2ea114de commit a89c82249c3763780522f763dd2e615e2ea114de Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Sun Jun 11 18:20:10 2023 +0100 PCI: Work around PCIe link training failures Attempt to handle cases such as with a downstream port of the ASMedia ASM2824 PCIe switch where link training never completes and the link continues switching between speeds indefinitely with the data link layer never reaching the active state. It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the switches should negotiate a link speed of 5.0GT/s, falling back to 2.5GT/s if necessary. Instead the link continues oscillating between the two speeds, at the rate of 34-35 times per second, with link training reported repeatedly active ~84% of the time. Limiting the target link speed to 2.5GT/s with the upstream ASM2824 device makes the two switches communicate correctly. Removing the speed restriction afterwards makes the two devices switch to 5.0GT/s then. Make use of these observations and detect the inability to train the link by checking for the Data Link Layer Link Active status bit being off while the Link Bandwidth Management Status indicating that hardware has changed the link speed or width in an attempt to correct unreliable link operation. Restrict the speed to 2.5GT/s then with the Target Link Speed field, request a retrain and wait 200ms for the data link to go up. If this is successful, lift the restriction, letting the devices negotiate a higher speed. Also check for a 2.5GT/s speed restriction the firmware may have already arranged and lift it too with ports of devices known to continue working afterwards (currently only ASM2824), that already report their data link being up. [bhelgaas: reorder and squash stubs from https://lore.kernel.org/r/alpine.DEB.2.21.2306111619570.64925@angie.orcam.me.uk to avoid adding stubs that do nothing] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203022037020.56670@angie.orcam.me.uk/ Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310038540.59226@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:19 +00:00
{
PCI: Use an error code with PCIe failed link retraining JIRA: https://issues.redhat.com/browse/RHEL-71363 Upstream Status: 59100eb248c0b15585affa546c7f6834b30eb5a4 commit 59100eb248c0b15585affa546c7f6834b30eb5a4 Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Fri Aug 9 14:25:02 2024 +0100 PCI: Use an error code with PCIe failed link retraining Given how the call place in pcie_wait_for_link_delay() got structured now, and that pcie_retrain_link() returns a potentially useful error code, convert pcie_failed_link_retrain() to return an error code rather than a boolean status, fixing handling at the call site mentioned. Update the other call site accordingly. Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'") Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.uk Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.5+ Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-10-09 15:07:21 +00:00
return -ENOTTY;
PCI: Work around PCIe link training failures JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: a89c82249c3763780522f763dd2e615e2ea114de commit a89c82249c3763780522f763dd2e615e2ea114de Author: Maciej W. Rozycki <macro@orcam.me.uk> Date: Sun Jun 11 18:20:10 2023 +0100 PCI: Work around PCIe link training failures Attempt to handle cases such as with a downstream port of the ASMedia ASM2824 PCIe switch where link training never completes and the link continues switching between speeds indefinitely with the data link layer never reaching the active state. It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the switches should negotiate a link speed of 5.0GT/s, falling back to 2.5GT/s if necessary. Instead the link continues oscillating between the two speeds, at the rate of 34-35 times per second, with link training reported repeatedly active ~84% of the time. Limiting the target link speed to 2.5GT/s with the upstream ASM2824 device makes the two switches communicate correctly. Removing the speed restriction afterwards makes the two devices switch to 5.0GT/s then. Make use of these observations and detect the inability to train the link by checking for the Data Link Layer Link Active status bit being off while the Link Bandwidth Management Status indicating that hardware has changed the link speed or width in an attempt to correct unreliable link operation. Restrict the speed to 2.5GT/s then with the Target Link Speed field, request a retrain and wait 200ms for the data link to go up. If this is successful, lift the restriction, letting the devices negotiate a higher speed. Also check for a 2.5GT/s speed restriction the firmware may have already arranged and lift it too with ports of devices known to continue working afterwards (currently only ASM2824), that already report their data link being up. [bhelgaas: reorder and squash stubs from https://lore.kernel.org/r/alpine.DEB.2.21.2306111619570.64925@angie.orcam.me.uk to avoid adding stubs that do nothing] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203022037020.56670@angie.orcam.me.uk/ Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310038540.59226@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:19 +00:00
}
PCI: Hide ACS quirk declarations inside PCI core Move declarations for these functions: pci_dev_specific_acs_enabled() pci_dev_specific_enable_acs() from include/linux/pci.h to drivers/pci/pci.h because nothing outside the PCI core needs to use them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-08-09 21:19:52 +00:00
#endif
PCI: acs p2p upsteram forwarding enabling Note: dom0 checking in v4 has been separated out into 2/2. This patch enables P2P upstream forwarding in ACS capable PCIe switches. It solves two potential problems in virtualization environment where a PCIe device is assigned to a guest domain using a HW iommu such as VT-d: 1) Unintentional failure caused by guest physical address programmed into the device's DMA that happens to match the memory address range of other downstream ports in the same PCIe switch. This causes the PCI transaction to go to the matching downstream port instead of go to the root complex to get translated by VT-d as it should be. 2) Malicious guest software intentionally attacks another downstream PCIe device by programming the DMA address into the assigned device that matches memory address range of the downstream PCIe port. We are in process of implementing device filtering software in KVM/XEN management software to allow device assignment of PCIe devices behind a PCIe switch only if it has ACS capability and with the P2P upstream forwarding bits enabled. This patch is intended to work for both KVM and Xen environments. Signed-off-by: Allen Kay <allen.m.kay@intel.com> Reviewed-by: Mathew Wilcox <willy@linux.intel.com> Reviewed-by: Chris Wright <chris@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-10-07 17:27:17 +00:00
PCI/AER: Factor out error reporting to drivers/pci/pcie/err.c Move the error reporting callbacks from aerdrv_core.c to err.c, where they can be used by DPC in addition to AER. As part of aerdrv_core.c, these callbacks were built under CONFIG_PCIEAER. Moving them to the new err.c means they will now be built under CONFIG_PCIEPORTBUS, so adjust the definition of pci_uevent_ers() to match. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> [bhelgaas: in reset_link(), initialize "driver" even if CONFIG_PCIEAER is unset, update pci_uevent_ers() #ifdef wrapper] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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,
PCI/ERR: Rename reset_link() to reset_subordinates() reset_link() appears to be misnamed. The point is to reset any devices below a given bridge, so rename it to reset_subordinates() to make it clear that we are passing a bridge with the intent to reset the devices below it. Link: https://lore.kernel.org/r/20201121001036.8560-5-sean.v.kelley@intel.com Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21 00:10:25 +00:00
pci_channel_state_t state,
pci_ers_result_t (*reset_subordinates)(struct pci_dev *pdev));
PCI/AER: Factor out error reporting to drivers/pci/pcie/err.c Move the error reporting callbacks from aerdrv_core.c to err.c, where they can be used by DPC in addition to AER. As part of aerdrv_core.c, these callbacks were built under CONFIG_PCIEAER. Moving them to the new err.c means they will now be built under CONFIG_PCIEPORTBUS, so adjust the definition of pci_uevent_ers() to match. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> [bhelgaas: in reset_link(), initialize "driver" even if CONFIG_PCIEAER is unset, update pci_uevent_ers() #ifdef wrapper] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-17 21:44:15 +00:00
PCI: Add generic pcie_wait_for_link() interface Clients such as hotplug and Downstream Port Containment (DPC) both need to wait until a link becomes active or inactive. Add a generic pcie_wait_link_active() interface and use it instead of duplicating the code. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
2018-05-17 21:44:11 +00:00
bool pcie_wait_for_link(struct pci_dev *pdev, bool active);
Merge branch 'pci/enumeration' JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: 1abb47390350a1bd5430390e296492e6248865b2 Conflict(s): Upstream had two patches that effectively did the same thing which obviously lead to conflicts: 3c0ec896a4b4 PCI/ASPM: Factor out waiting for link training to complete 9c7f136433d2 PCI/ASPM: Factor out pcie_wait_for_retrain() These were resolved upstream via merge commit 1abb47390350 "Merge branch 'pci/enumeration'". This patch does effectively the same thing as upstream. One way to detect the needed content is to run 'git blame' on the files and look for this patch's commit ID. The end result was also verified by running 'diff -u' on the files against upstream to assure that the content in question matched. commit 1abb47390350a1bd5430390e296492e6248865b2 Merge: 0f32114ea074 08e3ed12ca86 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Mon Jun 26 12:59:56 2023 -0500 Merge branch 'pci/enumeration' - Add PCI_EXT_CAP_ID_PL_32GT define (Ben Dooks) - Propagate firmware node by calling device_set_node() for better modularity (Andy Shevchenko) - Discover Data Link Layer Link Active Reporting earlier so quirks can take advantage of it (Maciej W. Rozycki) - Use cached Data Link Layer Link Active Reporting capability in pciehp, powerpc/eeh, and mlx5 (Maciej W. Rozycki) - Run quirk for devices that require OS to clear Retrain Link earlier, so later quirks can rely on it (Maciej W. Rozycki) - Export pcie_retrain_link() for use outside ASPM (Maciej W. Rozycki) - Add Data Link Layer Link Active Reporting as another way for pcie_retrain_link() to determine the link is up (Maciej W. Rozycki) - Work around link training failures (especially on the ASMedia ASM2824 switch) by training first at 2.5GT/s and then attempting higher rates (Maciej W. Rozycki) * pci/enumeration: PCI: Add failed link recovery for device reset events PCI: Work around PCIe link training failures PCI: Use pcie_wait_for_link_status() in pcie_wait_for_link_delay() PCI: Add support for polling DLLLA to pcie_retrain_link() PCI: Export pcie_retrain_link() for use outside ASPM PCI: Export PCIe link retrain timeout PCI: Execute quirk_enable_clear_retrain_link() earlier PCI/ASPM: Factor out waiting for link training to complete PCI/ASPM: Avoid unnecessary pcie_link_state use PCI/ASPM: Use distinct local vars in pcie_retrain_link() net/mlx5: Rely on dev->link_active_reporting powerpc/eeh: Rely on dev->link_active_reporting PCI: pciehp: Rely on dev->link_active_reporting PCI: Initialize dev->link_active_reporting earlier PCI: of: Propagate firmware node by calling device_set_node() PCI: Add PCI_EXT_CAP_ID_PL_32GT define # Conflicts: # drivers/pci/pcie/aspm.c Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:20 +00:00
int pcie_retrain_link(struct pci_dev *pdev, bool use_lt);
PCI/ASPM: Move pci_save_ltr_state() to aspm.c JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: 1e11b5494c3dbb1e5fce7e95021c1698799c7288 commit 1e11b5494c3dbb1e5fce7e95021c1698799c7288 Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 23 14:58:49 2024 -0600 PCI/ASPM: Move pci_save_ltr_state() to aspm.c Even when CONFIG_PCIEASPM is not set, we save and restore the LTR Capability so that if ASPM L1.2 and LTR were configured by the platform, ASPM L1.2 will still work after suspend/resume, when that platform configuration may be lost. See dbbfadf23190 ("PCI/ASPM: Save LTR Capability for suspend/resume"). Since ASPM L1.2 depends on the LTR Capability, move the save/restore code to the part of aspm.c that is always compiled regardless of CONFIG_PCIEASPM. No functional change intended. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-5-david.e.box@linux.intel.com [bhelgaas: commit log, reorder to make this a pure move] Link: https://lore.kernel.org/r/20240223205851.114931-4-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-24 18:14:57 +00:00
/* ASPM-related functionality we need even without CONFIG_PCIEASPM */
void pci_save_ltr_state(struct pci_dev *dev);
void pci_restore_ltr_state(struct pci_dev *dev);
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: 17423360a27ae58c1850f588bdd8013bbfcd250b commit 17423360a27ae58c1850f588bdd8013bbfcd250b Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 23 14:58:50 2024 -0600 PCI/ASPM: Save L1 PM Substates Capability for suspend/resume 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") restored the L1 PM Substates Capability after resume, which reduced power consumption by making the ASPM L1.x states work after resume. a7152be79b62 ("Revert "PCI/ASPM: Save L1 PM Substates Capability for suspend/resume"") reverted 4ff116d0d5fd because resume failed on some systems, so power consumption after resume increased again. a7152be79b62 mentioned that we restore L1 PM substate configuration even though ASPM L1 may already be enabled. This is due the fact that the pci_restore_aspm_l1ss_state() was called before pci_restore_pcie_state(). Save and restore the L1 PM Substates Capability, following PCIe r6.1, sec 5.5.4 more closely by: 1) Do not restore ASPM configuration in pci_restore_pcie_state() but do that after PCIe capability is restored in pci_restore_aspm_state() following PCIe r6.1, sec 5.5.4. 2) If BIOS reenables L1SS, particularly L1.2, we need to clear the enables in the right order, downstream before upstream. Defer restoring the L1SS config until we are at the downstream component. Then update the config for both ends of the link in the prescribed order. 3) Program ASPM L1 PM substate configuration before L1 enables. 4) Program ASPM L1 PM substate enables last, after rest of the fields in the capability are programmed. [bhelgaas: commit log, squash L1SS-related patches, do both LNKCTL restores in pci_restore_pcie_state()] Link: https://lore.kernel.org/r/20240128233212.1139663-3-david.e.box@linux.intel.com Link: https://lore.kernel.org/r/20240128233212.1139663-4-david.e.box@linux.intel.com Link: https://lore.kernel.org/r/20240223205851.114931-5-helgaas@kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217321 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216782 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877 Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Co-developed-by: David E. Box <david.e.box@linux.intel.com> Reported-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Tasev Nikola <tasev.stefanoska@skynet.be> # Asus UX305FA Cc: Mark Enriquez <enriquezmark36@gmail.com> Cc: Thomas Witt <kernel@witt.link> Cc: Werner Sembach <wse@tuxedocomputers.com> Cc: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-24 18:16:10 +00:00
void pci_configure_aspm_l1ss(struct pci_dev *dev);
void pci_save_aspm_l1ss_state(struct pci_dev *dev);
void pci_restore_aspm_l1ss_state(struct pci_dev *dev);
PCI/ASPM: Move pci_save_ltr_state() to aspm.c JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: 1e11b5494c3dbb1e5fce7e95021c1698799c7288 commit 1e11b5494c3dbb1e5fce7e95021c1698799c7288 Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 23 14:58:49 2024 -0600 PCI/ASPM: Move pci_save_ltr_state() to aspm.c Even when CONFIG_PCIEASPM is not set, we save and restore the LTR Capability so that if ASPM L1.2 and LTR were configured by the platform, ASPM L1.2 will still work after suspend/resume, when that platform configuration may be lost. See dbbfadf23190 ("PCI/ASPM: Save LTR Capability for suspend/resume"). Since ASPM L1.2 depends on the LTR Capability, move the save/restore code to the part of aspm.c that is always compiled regardless of CONFIG_PCIEASPM. No functional change intended. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-5-david.e.box@linux.intel.com [bhelgaas: commit log, reorder to make this a pure move] Link: https://lore.kernel.org/r/20240223205851.114931-4-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-24 18:14:57 +00:00
PCI/ASPM: Unexport internal ASPM interfaces Several of the interfaces defined in include/linux/pci-aspm.h are used only internally from the PCI core: pcie_aspm_init_link_state() pcie_aspm_exit_link_state() pcie_aspm_pm_state_change() pcie_aspm_powersave_config_link() pcie_aspm_create_sysfs_dev_files() pcie_aspm_remove_sysfs_dev_files() Move these to the internal drivers/pci/pci.h header so they don't clutter the driver interface. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI/ASPM: Fix deadlock when enabling ASPM JIRA: https://issues.redhat.com/browse/RHEL-26162 Upstream Status: 1e560864159d002b453da42bd2c13a1805515a20 commit 1e560864159d002b453da42bd2c13a1805515a20 Author: Johan Hovold <johan+linaro@kernel.org> Date: Tue Jan 30 11:02:43 2024 +0100 PCI/ASPM: Fix deadlock when enabling ASPM A last minute revert in 6.7-final introduced a potential deadlock when enabling ASPM during probe of Qualcomm PCIe controllers as reported by lockdep: ============================================ WARNING: possible recursive locking detected 6.7.0 #40 Not tainted -------------------------------------------- kworker/u16:5/90 is trying to acquire lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc but task is already holding lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(pci_bus_sem); lock(pci_bus_sem); *** DEADLOCK *** Call trace: print_deadlock_bug+0x25c/0x348 __lock_acquire+0x10a4/0x2064 lock_acquire+0x1e8/0x318 down_read+0x60/0x184 pcie_aspm_pm_state_change+0x58/0xdc pci_set_full_power_state+0xa8/0x114 pci_set_power_state+0xc4/0x120 qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom] pci_walk_bus+0x64/0xbc qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom] The deadlock can easily be reproduced on machines like the Lenovo ThinkPad X13s by adding a delay to increase the race window during asynchronous probe where another thread can take a write lock. Add a new pci_set_power_state_locked() and associated helper functions that can be called with the PCI bus semaphore held to avoid taking the read lock twice. Link: https://lore.kernel.org/r/ZZu0qx2cmn7IwTyQ@hovoldconsulting.com Link: https://lore.kernel.org/r/20240130100243.11011-1-johan+linaro@kernel.org Fixes: f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()"") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: <stable@vger.kernel.org> # 6.7 Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-02-25 15:40:35 +00:00
void pcie_aspm_pm_state_change(struct pci_dev *pdev, bool locked);
PCI/ASPM: Unexport internal ASPM interfaces Several of the interfaces defined in include/linux/pci-aspm.h are used only internally from the PCI core: pcie_aspm_init_link_state() pcie_aspm_exit_link_state() pcie_aspm_pm_state_change() pcie_aspm_powersave_config_link() pcie_aspm_create_sysfs_dev_files() pcie_aspm_remove_sysfs_dev_files() Move these to the internal drivers/pci/pci.h header so they don't clutter the driver interface. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-15 14:57:28 +00:00
void pcie_aspm_powersave_config_link(struct pci_dev *pdev);
PCI/ASPM: Move pci_configure_ltr() to aspm.c JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: fa84f4435a6202dd90248517f41e54bf3fb85bc5 Conflict(s): Patching file drivers/pci/pci.h; Hunk #2 FAILED at 572. False conflict as this upstream patch's basis was prior to upstream commit 1e560864159d "PCI/ASPM: Fix deadlock when enabling ASPM". commit fa84f4435a6202dd90248517f41e54bf3fb85bc5 Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 23 14:58:47 2024 -0600 PCI/ASPM: Move pci_configure_ltr() to aspm.c The Latency Tolerance Reporting (LTR) mechanism supports the ASPM L1.2 state and is only configured when CONFIG_PCIEASPM is set. Move pci_configure_ltr() and pci_bridge_reconfigure_ltr() into aspm.c since they only build when CONFIG_PCIEASPM is set. No functional change intended. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-2-david.e.box@linux.intel.com [bhelgaas: commit log, split build change from function moves] Link: https://lore.kernel.org/r/20240223205851.114931-2-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-24 17:52:53 +00:00
void pci_configure_ltr(struct pci_dev *pdev);
void pci_bridge_reconfigure_ltr(struct pci_dev *pdev);
PCI/ASPM: Unexport internal ASPM interfaces Several of the interfaces defined in include/linux/pci-aspm.h are used only internally from the PCI core: pcie_aspm_init_link_state() pcie_aspm_exit_link_state() pcie_aspm_pm_state_change() pcie_aspm_powersave_config_link() pcie_aspm_create_sysfs_dev_files() pcie_aspm_remove_sysfs_dev_files() Move these to the internal drivers/pci/pci.h header so they don't clutter the driver interface. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-15 14:57:28 +00:00
#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) { }
PCI/ASPM: Fix deadlock when enabling ASPM JIRA: https://issues.redhat.com/browse/RHEL-26162 Upstream Status: 1e560864159d002b453da42bd2c13a1805515a20 commit 1e560864159d002b453da42bd2c13a1805515a20 Author: Johan Hovold <johan+linaro@kernel.org> Date: Tue Jan 30 11:02:43 2024 +0100 PCI/ASPM: Fix deadlock when enabling ASPM A last minute revert in 6.7-final introduced a potential deadlock when enabling ASPM during probe of Qualcomm PCIe controllers as reported by lockdep: ============================================ WARNING: possible recursive locking detected 6.7.0 #40 Not tainted -------------------------------------------- kworker/u16:5/90 is trying to acquire lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc but task is already holding lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(pci_bus_sem); lock(pci_bus_sem); *** DEADLOCK *** Call trace: print_deadlock_bug+0x25c/0x348 __lock_acquire+0x10a4/0x2064 lock_acquire+0x1e8/0x318 down_read+0x60/0x184 pcie_aspm_pm_state_change+0x58/0xdc pci_set_full_power_state+0xa8/0x114 pci_set_power_state+0xc4/0x120 qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom] pci_walk_bus+0x64/0xbc qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom] The deadlock can easily be reproduced on machines like the Lenovo ThinkPad X13s by adding a delay to increase the race window during asynchronous probe where another thread can take a write lock. Add a new pci_set_power_state_locked() and associated helper functions that can be called with the PCI bus semaphore held to avoid taking the read lock twice. Link: https://lore.kernel.org/r/ZZu0qx2cmn7IwTyQ@hovoldconsulting.com Link: https://lore.kernel.org/r/20240130100243.11011-1-johan+linaro@kernel.org Fixes: f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()"") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: <stable@vger.kernel.org> # 6.7 Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-02-25 15:40:35 +00:00
static inline void pcie_aspm_pm_state_change(struct pci_dev *pdev, bool locked) { }
PCI/ASPM: Unexport internal ASPM interfaces Several of the interfaces defined in include/linux/pci-aspm.h are used only internally from the PCI core: pcie_aspm_init_link_state() pcie_aspm_exit_link_state() pcie_aspm_pm_state_change() pcie_aspm_powersave_config_link() pcie_aspm_create_sysfs_dev_files() pcie_aspm_remove_sysfs_dev_files() Move these to the internal drivers/pci/pci.h header so they don't clutter the driver interface. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-15 14:57:28 +00:00
static inline void pcie_aspm_powersave_config_link(struct pci_dev *pdev) { }
PCI/ASPM: Move pci_configure_ltr() to aspm.c JIRA: https://issues.redhat.com/browse/RHEL-33544 Upstream Status: fa84f4435a6202dd90248517f41e54bf3fb85bc5 Conflict(s): Patching file drivers/pci/pci.h; Hunk #2 FAILED at 572. False conflict as this upstream patch's basis was prior to upstream commit 1e560864159d "PCI/ASPM: Fix deadlock when enabling ASPM". commit fa84f4435a6202dd90248517f41e54bf3fb85bc5 Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 23 14:58:47 2024 -0600 PCI/ASPM: Move pci_configure_ltr() to aspm.c The Latency Tolerance Reporting (LTR) mechanism supports the ASPM L1.2 state and is only configured when CONFIG_PCIEASPM is set. Move pci_configure_ltr() and pci_bridge_reconfigure_ltr() into aspm.c since they only build when CONFIG_PCIEASPM is set. No functional change intended. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-2-david.e.box@linux.intel.com [bhelgaas: commit log, split build change from function moves] Link: https://lore.kernel.org/r/20240223205851.114931-2-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-04-24 17:52:53 +00:00
static inline void pci_configure_ltr(struct pci_dev *pdev) { }
static inline void pci_bridge_reconfigure_ltr(struct pci_dev *pdev) { }
PCI/ASPM: Unexport internal ASPM interfaces Several of the interfaces defined in include/linux/pci-aspm.h are used only internally from the PCI core: pcie_aspm_init_link_state() pcie_aspm_exit_link_state() pcie_aspm_pm_state_change() pcie_aspm_powersave_config_link() pcie_aspm_create_sysfs_dev_files() pcie_aspm_remove_sysfs_dev_files() Move these to the internal drivers/pci/pci.h header so they don't clutter the driver interface. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-15 14:57:28 +00:00
#endif
PCI: Make pcie_set_ecrc_checking(), pcie_ecrc_get_policy() private These interfaces: void pcie_set_ecrc_checking(struct pci_dev *dev); void pcie_ecrc_get_policy(char *str); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-10-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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
PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 665745f274870c921020f610e2c99a3b1613519b commit 665745f274870c921020f610e2c99a3b1613519b Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:52 2024 +0300 PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller This mostly reverts the commit b4c7d2076b4e ("PCI/LINK: Remove bandwidth notification"). An upcoming commit extends this driver building PCIe bandwidth controller on top of it. PCIe bandwidth notifications were first added in the commit e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") but later had to be removed. The significant changes compared with the old bandwidth notification driver include: 1) Don't print the notifications into kernel log, just keep the Link Speed cached in struct pci_bus updated. While somewhat unfortunate, the log spam was the source of complaints that eventually lead to the removal of the bandwidth notifications driver (see the links below for further information). 2) Besides the Link Bandwidth Management Interrupt, also enable Link Autonomous Bandwidth Interrupt to cover the other source of bandwidth changes. 3) Handle Link Speed updates robustly. Refresh the cached Link Speed when enabling Bandwidth Notification Interrupts, and solve the race between Link Speed read and LBMS/LABS update in pcie_bwnotif_irq_thread(). 4) Use concurrency safe LNKCTL RMW operations. 5) The driver is now called PCIe bwctrl (bandwidth controller) instead of just bandwidth notifications because of increased scope and functionality within the driver. 6) Coexist with the Target Link Speed quirk in pcie_failed_link_retrain(). Provide LBMS counting API for it. 7) Tweaks to variable/functions names for consistency and length reasons. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. [bhelgaas: This is based on previous work by Alexandru Gagniuc <mr.nuke.me@gmail.com>; see e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification")] Link: https://lore.kernel.org/r/20241018144755.7875-7-ilpo.jarvinen@linux.intel.com Link: https://lore.kernel.org/all/20190429185611.121751-1-helgaas@kernel.org/ Link: https://lore.kernel.org/linux-pci/20190501142942.26972-1-keith.busch@intel.com/ Link: https://lore.kernel.org/linux-pci/20200115221008.GA191037@google.com/ Suggested-by: Lukas Wunner <lukas@wunner.de> # Building bwctrl on top of bwnotif Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash fix to drop IRQF_ONESHOT and convert to hardirq handler: https://lore.kernel.org/r/20241115165717.15233-1-ilpo.jarvinen@linux.intel.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-03-20 16:33:57 +00:00
#ifdef CONFIG_PCIEPORTBUS
void pcie_reset_lbms_count(struct pci_dev *port);
int pcie_lbms_count(struct pci_dev *port, unsigned long *val);
#else
static inline void pcie_reset_lbms_count(struct pci_dev *port) {}
static inline int pcie_lbms_count(struct pci_dev *port, unsigned long *val)
{
return -EOPNOTSUPP;
}
#endif
PCI: support device-specific reset methods Add a new type of quirk for resetting devices at pci_dev_reset time. This is necessary to handle device with nonstandard reset procedures, especially useful for guest drivers. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-12-07 05:03:21 +00:00
struct pci_dev_reset_methods {
u16 vendor;
u16 device;
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
int (*reset)(struct pci_dev *dev, bool probe);
PCI: support device-specific reset methods Add a new type of quirk for resetting devices at pci_dev_reset time. This is necessary to handle device with nonstandard reset procedures, especially useful for guest drivers. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-12-07 05:03:21 +00:00
};
PCI: Add array to track reset method ordering Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 commit e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:34:54 2021 +0530 PCI: Add array to track reset method ordering Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.c om Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:06:23 +00:00
struct pci_reset_fn_method {
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
int (*reset_fn)(struct pci_dev *pdev, bool probe);
PCI: Add array to track reset method ordering Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 commit e20afa06244eb5d7fa850f9fe2a78ae17ba96f81 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:34:54 2021 +0530 PCI: Add array to track reset method ordering Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.c om Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:06:23 +00:00
char *name;
PCI: support device-specific reset methods Add a new type of quirk for resetting devices at pci_dev_reset time. This is necessary to handle device with nonstandard reset procedures, especially useful for guest drivers. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-12-07 05:03:21 +00:00
};
PCI: Clean up build for CONFIG_PCI_QUIRKS unset Currently, drivers/pci/quirks.c is built unconditionally, but if CONFIG_PCI_QUIRKS is unset, the only things actually built in this file are definitions of global variables and empty functions (due to the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the file). This is not particularly nice and if someone overlooks the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced. To clean that up, move the definitions of the global variables in quirks.c that are always built to pci.c, move the definitions of the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to headers (additionally make these functions static inline) and modify drivers/pci/Makefile so that quirks.c is only built if CONFIG_PCI_QUIRKS is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-01-02 21:57:24 +00:00
#ifdef CONFIG_PCI_QUIRKS
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
int pci_dev_specific_reset(struct pci_dev *dev, bool probe);
PCI: Clean up build for CONFIG_PCI_QUIRKS unset Currently, drivers/pci/quirks.c is built unconditionally, but if CONFIG_PCI_QUIRKS is unset, the only things actually built in this file are definitions of global variables and empty functions (due to the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the file). This is not particularly nice and if someone overlooks the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced. To clean that up, move the definitions of the global variables in quirks.c that are always built to pci.c, move the definitions of the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to headers (additionally make these functions static inline) and modify drivers/pci/Makefile so that quirks.c is only built if CONFIG_PCI_QUIRKS is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-01-02 21:57:24 +00:00
#else
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
static inline int pci_dev_specific_reset(struct pci_dev *dev, bool probe)
PCI: Clean up build for CONFIG_PCI_QUIRKS unset Currently, drivers/pci/quirks.c is built unconditionally, but if CONFIG_PCI_QUIRKS is unset, the only things actually built in this file are definitions of global variables and empty functions (due to the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the file). This is not particularly nice and if someone overlooks the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced. To clean that up, move the definitions of the global variables in quirks.c that are always built to pci.c, move the definitions of the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to headers (additionally make these functions static inline) and modify drivers/pci/Makefile so that quirks.c is only built if CONFIG_PCI_QUIRKS is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-01-02 21:57:24 +00:00
{
return -ENOTTY;
}
#endif
PCI: support device-specific reset methods Add a new type of quirk for resetting devices at pci_dev_reset time. This is necessary to handle device with nonstandard reset procedures, especially useful for guest drivers. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-12-07 05:03:21 +00:00
PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform The acpi_get_rc_resources() is used to get the RC register address that can not be described in MCFG. It takes the _HID & segment to look for and outputs the RC address resource. Use PNP0C02 devices to describe such RC address resource. Use _UID to match segment to tell which root bus the PNP0C02 resource belongs to. [bhelgaas: add dev argument, wrap in #ifdef CONFIG_PCI_QUIRKS] Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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);
PCI: thunder: Fix compile testing Compile-testing these drivers is currently broken. Enabling it causes a couple of build failures though: drivers/pci/controller/pci-thunder-ecam.c:119:30: error: shift count >= width of type [-Werror,-Wshift-count-overflow] drivers/pci/controller/pci-thunder-pem.c:54:2: error: implicit declaration of function 'writeq' [-Werror,-Wimplicit-function-declaration] drivers/pci/controller/pci-thunder-pem.c:392:8: error: implicit declaration of function 'acpi_get_rc_resources' [-Werror,-Wimplicit-function-declaration] Fix them with the obvious one-line changes. Link: https://lore.kernel.org/r/20210308152501.2135937-2-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Robert Richter <rric@kernel.org>
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;
}
PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform The acpi_get_rc_resources() is used to get the RC register address that can not be described in MCFG. It takes the _HID & segment to look for and outputs the RC address resource. Use PNP0C02 devices to describe such RC address resource. Use _UID to match segment to tell which root bus the PNP0C02 resource belongs to. [bhelgaas: add dev argument, wrap in #ifdef CONFIG_PCI_QUIRKS] Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-01 06:33:42 +00:00
#endif
PCI: Add resizable BAR infrastructure Add resizable BAR infrastructure, including defines and helper functions to read the possible sizes of a BAR and update its size. See PCIe r3.1, sec 7.22. Link: https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf Signed-off-by: Christian König <christian.koenig@amd.com> [bhelgaas: rename to functions with "rebar" (to match #defines), drop shift #defines, drop "_MASK" suffixes, fix typos, fix kerneldoc] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
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);
}
PCI: Move private DT related functions into private header The functions in linux/of_pci.h are primarily used by host bridge drivers, so they can be private to drivers/pci/. The remaining functions are still used mostly in host bridge drivers that still live in arch specific code. Hopefully someday, those will get moved into drivers/pci as well. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
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);
PCI: Add function for parsing 'slot-power-limit-milliwatt' DT property Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2118429 Upstream Status: 35662423fb879dd0f32b7beae71fc5f6d8abf45c commit 35662423fb879dd0f32b7beae71fc5f6d8abf45c Author: Pali Rohár <pali@kernel.org> Date: Tue Apr 12 11:49:45 2022 +0200 PCI: Add function for parsing 'slot-power-limit-milliwatt' DT property Add function of_pci_get_slot_power_limit(), which parses the 'slot-power-limit-milliwatt' DT property, returning the value in milliwatts and in format ready for the PCIe Slot Capabilities Register. Link: https://lore.kernel.org/r/20220412094946.27069-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-08-17 15:39:26 +00:00
u32 of_pci_get_slot_power_limit(struct device_node *node,
u8 *slot_power_limit_value,
u8 *slot_power_limit_scale);
PCI: of: Add of_pci_preserve_config() for per-host bridge support JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 407abde9caee0d8f757fc8bed43fa5efc6fe509a commit 407abde9caee0d8f757fc8bed43fa5efc6fe509a Author: Vidya Sagar <vidyas@nvidia.com> Date: Wed May 8 23:11:36 2024 +0530 PCI: of: Add of_pci_preserve_config() for per-host bridge support Add of_pci_preserve_config() to look for the "linux,pci-probe-only" property under a specified node. If it's not found there, look under "of_chosen" in addition. If the caller didn't specify a node, look under "of_chosen". With a future patch, this will support "linux,pci-probe-only" on a per host bridge basis based on the presence of the property in the respective PCI host bridge DT node. Implement of_pci_check_probe_only() using of_pci_preserve_config(). Link: https://lore.kernel.org/r/20240508174138.3630283-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-17 14:42:52 +00:00
bool of_pci_preserve_config(struct device_node *node);
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 PCI: Restrict device disabled status check to DT Commit 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") checked the firmware device status for both DT and ACPI devices. That caused a regression in some ACPI systems. The exact reason isn't clear. It's possibly a firmware bug. For now, at least, refactor the check to be for DT based systems only. Note that the original implementation leaked a refcount which is now correctly handled. [bhelgaas: Per ACPI r6.5, sec 6.3.7, for devices on an enumerable bus, _STA must return with bit[0] ("device is present") set] Link: https://lore.kernel.org/all/m2fs9lgndw.fsf@gmail.com/ Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/r/20230419193513.708818-1-robh@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217317 Reported-by: Donald Hunter <donald.hunter@gmail.com> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Donald Hunter <donald.hunter@gmail.com> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Binbin Zhou <zhoubinbin@loongson.cn> Cc: Liu Peibao <liupeibao@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
int pci_set_of_node(struct pci_dev *dev);
PCI: Make pci_set_of_node(), etc private These interfaces: 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); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-12-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:48 +00:00
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);
PCI: Move private DT related functions into private header The functions in linux/of_pci.h are primarily used by host bridge drivers, so they can be private to drivers/pci/. The remaining functions are still used mostly in host bridge drivers that still live in arch specific code. Hopefully someday, those will get moved into drivers/pci as well. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
2018-05-11 17:15:30 +00:00
PCI: Move DT resource setup into devm_pci_alloc_host_bridge() Now that pci_parse_request_of_pci_ranges() callers just setup pci_host_bridge.windows and dma_ranges directly and don't need the bus range returned, we can just initialize them when allocating the pci_host_bridge struct. With this, pci_parse_request_of_pci_ranges() becomes a static function. Link: https://lore.kernel.org/r/20200722022514.1283916-19-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-07-22 02:25:13 +00:00
int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge *bridge);
PCI: Move private DT related functions into private header The functions in linux/of_pci.h are primarily used by host bridge drivers, so they can be private to drivers/pci/. The remaining functions are still used mostly in host bridge drivers that still live in arch specific code. Hopefully someday, those will get moved into drivers/pci as well. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
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;
}
PCI: Make pci_set_of_node(), etc private These interfaces: 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); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-12-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:48 +00:00
PCI: Add function for parsing 'slot-power-limit-milliwatt' DT property Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2118429 Upstream Status: 35662423fb879dd0f32b7beae71fc5f6d8abf45c commit 35662423fb879dd0f32b7beae71fc5f6d8abf45c Author: Pali Rohár <pali@kernel.org> Date: Tue Apr 12 11:49:45 2022 +0200 PCI: Add function for parsing 'slot-power-limit-milliwatt' DT property Add function of_pci_get_slot_power_limit(), which parses the 'slot-power-limit-milliwatt' DT property, returning the value in milliwatts and in format ready for the PCIe Slot Capabilities Register. Link: https://lore.kernel.org/r/20220412094946.27069-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-08-17 15:39:26 +00:00
static inline u32
of_pci_get_slot_power_limit(struct device_node *node,
u8 *slot_power_limit_value,
u8 *slot_power_limit_scale)
{
if (slot_power_limit_value)
*slot_power_limit_value = 0;
if (slot_power_limit_scale)
*slot_power_limit_scale = 0;
return 0;
}
PCI: of: Add of_pci_preserve_config() for per-host bridge support JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 407abde9caee0d8f757fc8bed43fa5efc6fe509a commit 407abde9caee0d8f757fc8bed43fa5efc6fe509a Author: Vidya Sagar <vidyas@nvidia.com> Date: Wed May 8 23:11:36 2024 +0530 PCI: of: Add of_pci_preserve_config() for per-host bridge support Add of_pci_preserve_config() to look for the "linux,pci-probe-only" property under a specified node. If it's not found there, look under "of_chosen" in addition. If the caller didn't specify a node, look under "of_chosen". With a future patch, this will support "linux,pci-probe-only" on a per host bridge basis based on the presence of the property in the respective PCI host bridge DT node. Implement of_pci_check_probe_only() using of_pci_preserve_config(). Link: https://lore.kernel.org/r/20240508174138.3630283-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-17 14:42:52 +00:00
static inline bool of_pci_preserve_config(struct device_node *node)
{
return false;
}
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 PCI: Restrict device disabled status check to DT Commit 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") checked the firmware device status for both DT and ACPI devices. That caused a regression in some ACPI systems. The exact reason isn't clear. It's possibly a firmware bug. For now, at least, refactor the check to be for DT based systems only. Note that the original implementation leaked a refcount which is now correctly handled. [bhelgaas: Per ACPI r6.5, sec 6.3.7, for devices on an enumerable bus, _STA must return with bit[0] ("device is present") set] Link: https://lore.kernel.org/all/m2fs9lgndw.fsf@gmail.com/ Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/r/20230419193513.708818-1-robh@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217317 Reported-by: Donald Hunter <donald.hunter@gmail.com> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Donald Hunter <donald.hunter@gmail.com> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Binbin Zhou <zhoubinbin@loongson.cn> Cc: Liu Peibao <liupeibao@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
static inline int pci_set_of_node(struct pci_dev *dev) { return 0; }
PCI: Make pci_set_of_node(), etc private These interfaces: 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); are only used in drivers/pci/ and do not need to be seen by the rest of the kernel. Move them to drivers/pci/pci.h so they're private to the PCI subsystem. Link: https://lore.kernel.org/r/20190724233848.73327-12-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-07-24 23:38:48 +00:00
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) { }
PCI: Move DT resource setup into devm_pci_alloc_host_bridge() Now that pci_parse_request_of_pci_ranges() callers just setup pci_host_bridge.windows and dma_ranges directly and don't need the bus range returned, we can just initialize them when allocating the pci_host_bridge struct. With this, pci_parse_request_of_pci_ranges() becomes a static function. Link: https://lore.kernel.org/r/20200722022514.1283916-19-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
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;
}
PCI: Move private DT related functions into private header The functions in linux/of_pci.h are primarily used by host bridge drivers, so they can be private to drivers/pci/. The remaining functions are still used mostly in host bridge drivers that still live in arch specific code. Hopefully someday, those will get moved into drivers/pci as well. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
2018-05-11 17:15:30 +00:00
#endif /* CONFIG_OF */
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 PCI: Create device tree node for bridge The PCI endpoint device such as Xilinx Alveo PCI card maps the register spaces from multiple hardware peripherals to its PCI BAR. Normally, the PCI core discovers devices and BARs using the PCI enumeration process. There is no infrastructure to discover the hardware peripherals that are present in a PCI device, and which can be accessed through the PCI BARs. Apparently, the device tree framework requires a device tree node for the PCI device. Thus, it can generate the device tree nodes for hardware peripherals underneath. Because PCI is self discoverable bus, there might not be a device tree node created for PCI devices. Furthermore, if the PCI device is hot pluggable, when it is plugged in, the device tree nodes for its parent bridges are required. Add support to generate device tree node for PCI bridges. Add an of_pci_make_dev_node() interface that can be used to create device tree node for PCI devices. Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on, the kernel will generate device tree nodes for PCI bridges unconditionally. Initially, add the basic properties for the dynamically generated device tree nodes which include #address-cells, #size-cells, device_type, compatible, ranges, reg. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/1692120000-46900-3-git-send-email-lizhi.hou@amd.com Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
struct of_changeset;
#ifdef CONFIG_PCI_DYNAMIC_OF_NODES
void of_pci_make_dev_node(struct pci_dev *pdev);
void of_pci_remove_node(struct pci_dev *pdev);
int of_pci_add_properties(struct pci_dev *pdev, struct of_changeset *ocs,
struct device_node *np);
#else
static inline void of_pci_make_dev_node(struct pci_dev *pdev) { }
static inline void of_pci_remove_node(struct pci_dev *pdev) { }
#endif
PCI/AER: Move internal declarations to drivers/pci/pci.h Since pci_aer_init() and pci_no_aer() are used only internally, move their declarations to the PCI internal header file. Also, no one cares about return value of pci_aer_init(), so make it void. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-21 23:48:26 +00:00
#ifdef CONFIG_PCIEAER
void pci_no_aer(void);
void pci_aer_init(struct pci_dev *dev);
PCI/AER: Define aer_stats structure for AER capable devices Define a structure to hold the AER statistics. There are 2 groups of statistics: dev_* counters that are to be collected for all AER capable devices and rootport_* counters that are collected for all (AER capable) rootports only. Allocate and free this structure when device is added or released (thus counters survive the lifetime of the device). Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-30 20:07:17 +00:00
void pci_aer_exit(struct pci_dev *dev);
PCI/AER: Add sysfs attributes to provide AER stats and breakdown Add sysfs attributes to provide total and breakdown of the AERs seen, into different type of correctable, fatal and nonfatal errors: /sys/bus/pci/devices/<dev>/aer_dev_correctable /sys/bus/pci/devices/<dev>/aer_dev_fatal /sys/bus/pci/devices/<dev>/aer_dev_nonfatal Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-21 23:48:28 +00:00
extern const struct attribute_group aer_stats_attr_group;
PCI/AER: Clear only ERR_FATAL status bits during fatal recovery During recovery from fatal errors, we previously called pci_cleanup_aer_uncorrect_error_status(), which cleared *all* uncorrectable error status bits (both ERR_FATAL and ERR_NONFATAL). Instead, call a new pci_aer_clear_fatal_status() that clears only the ERR_FATAL bits (as indicated by the PCI_ERR_UNCOR_SEVER register). Based-on-patch-by: Oza Pawandeep <poza@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-19 22:55:58 +00:00
void pci_aer_clear_fatal_status(struct pci_dev *dev);
PCI/AER: Rationalize error status register clearing The AER interfaces to clear error status registers were a confusing mess: - pci_cleanup_aer_uncorrect_error_status() cleared non-fatal errors from the Uncorrectable Error Status register. - pci_aer_clear_fatal_status() cleared fatal errors from the Uncorrectable Error Status register. - pci_cleanup_aer_error_status_regs() cleared the Root Error Status register (for Root Ports), the Uncorrectable Error Status register, and the Correctable Error Status register. Rename them to make them consistent: From To ---------------------------------------- ------------------------------- pci_cleanup_aer_uncorrect_error_status() pci_aer_clear_nonfatal_status() pci_aer_clear_fatal_status() pci_aer_clear_fatal_status() pci_cleanup_aer_error_status_regs() pci_aer_clear_status() Since pci_cleanup_aer_error_status_regs() (renamed to pci_aer_clear_status()) is only used within drivers/pci/, move the declaration from <linux/aer.h> to drivers/pci/pci.h. [bhelgaas: commit log, add renames] Link: https://lore.kernel.org/r/d1310a75dc3d28f7e8da4e99c45fbd3e60fe238e.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: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);
PCI: Unexport pci_save_aer_state() JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: ba3da66783184ca94a6c1be2a6a03d20d8889b14 commit ba3da66783184ca94a6c1be2a6a03d20d8889b14 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Jun 9 17:24:57 2023 -0500 PCI: Unexport pci_save_aer_state() pci_save_aer_state() and pci_restore_aer_state() are only used in drivers/pci, so don't expose them to the rest of the kernel. No functional change intended. Link: https://lore.kernel.org/r/20230609222500.1267795-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:15 +00:00
void pci_save_aer_state(struct pci_dev *dev);
void pci_restore_aer_state(struct pci_dev *dev);
PCI/AER: Move internal declarations to drivers/pci/pci.h Since pci_aer_init() and pci_no_aer() are used only internally, move their declarations to the PCI internal header file. Also, no one cares about return value of pci_aer_init(), so make it void. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-21 23:48:26 +00:00
#else
static inline void pci_no_aer(void) { }
PCI/AER: Change pci_aer_init() stub to return void Commit 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") changed pci_aer_init() to return "void", but didn't change the stub for when CONFIG_PCIEAER isn't enabled. Change the stub to match. Fixes: 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.19+
2019-04-12 06:43:06 +00:00
static inline void pci_aer_init(struct pci_dev *d) { }
PCI/AER: Define aer_stats structure for AER capable devices Define a structure to hold the AER statistics. There are 2 groups of statistics: dev_* counters that are to be collected for all AER capable devices and rootport_* counters that are collected for all (AER capable) rootports only. Allocate and free this structure when device is added or released (thus counters survive the lifetime of the device). Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-30 20:07:17 +00:00
static inline void pci_aer_exit(struct pci_dev *d) { }
PCI/AER: Clear only ERR_FATAL status bits during fatal recovery During recovery from fatal errors, we previously called pci_cleanup_aer_uncorrect_error_status(), which cleared *all* uncorrectable error status bits (both ERR_FATAL and ERR_NONFATAL). Instead, call a new pci_aer_clear_fatal_status() that clears only the ERR_FATAL bits (as indicated by the PCI_ERR_UNCOR_SEVER register). Based-on-patch-by: Oza Pawandeep <poza@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-19 22:55:58 +00:00
static inline void pci_aer_clear_fatal_status(struct pci_dev *dev) { }
PCI/AER: Rationalize error status register clearing The AER interfaces to clear error status registers were a confusing mess: - pci_cleanup_aer_uncorrect_error_status() cleared non-fatal errors from the Uncorrectable Error Status register. - pci_aer_clear_fatal_status() cleared fatal errors from the Uncorrectable Error Status register. - pci_cleanup_aer_error_status_regs() cleared the Root Error Status register (for Root Ports), the Uncorrectable Error Status register, and the Correctable Error Status register. Rename them to make them consistent: From To ---------------------------------------- ------------------------------- pci_cleanup_aer_uncorrect_error_status() pci_aer_clear_nonfatal_status() pci_aer_clear_fatal_status() pci_aer_clear_fatal_status() pci_cleanup_aer_error_status_regs() pci_aer_clear_status() Since pci_cleanup_aer_error_status_regs() (renamed to pci_aer_clear_status()) is only used within drivers/pci/, move the declaration from <linux/aer.h> to drivers/pci/pci.h. [bhelgaas: commit log, add renames] Link: https://lore.kernel.org/r/d1310a75dc3d28f7e8da4e99c45fbd3e60fe238e.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: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; }
PCI: Unexport pci_save_aer_state() JIRA: https://issues.redhat.com/browse/RHEL-2570 Upstream Status: ba3da66783184ca94a6c1be2a6a03d20d8889b14 commit ba3da66783184ca94a6c1be2a6a03d20d8889b14 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Fri Jun 9 17:24:57 2023 -0500 PCI: Unexport pci_save_aer_state() pci_save_aer_state() and pci_restore_aer_state() are only used in drivers/pci, so don't expose them to the rest of the kernel. No functional change intended. Link: https://lore.kernel.org/r/20230609222500.1267795-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-09-18 17:25:15 +00:00
static inline void pci_save_aer_state(struct pci_dev *dev) { }
static inline void pci_restore_aer_state(struct pci_dev *dev) { }
PCI/AER: Move internal declarations to drivers/pci/pci.h Since pci_aer_init() and pci_no_aer() are used only internally, move their declarations to the PCI internal header file. Also, no one cares about return value of pci_aer_init(), so make it void. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-21 23:48:26 +00:00
#endif
PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.c Move program_hpx_type0(), program_hpx_type1(), etc., and enums hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific. Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and drivers/pci/probe.c. Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:50 +00:00
#ifdef CONFIG_ACPI
PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge() JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 9d7d5db8e78ef1b67690bbffa5af60016d8e279d commit 9d7d5db8e78ef1b67690bbffa5af60016d8e279d Author: Vidya Sagar <vidyas@nvidia.com> Date: Wed May 8 23:11:35 2024 +0530 PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge() Move the PRESERVE_BOOT_CONFIG _DSM evaluation from acpi_pci_root_create() to pci_register_host_bridge(). This will help unify the ACPI _DSM path and the DT-based "linux,pci-probe-only" paths. This should be safe because it happens earlier than it used to: acpi_pci_root_create pci_create_root_bus pci_register_host_bridge + bridge->preserve_config = pci_preserve_config(bridge) pci_acpi_preserve_config + acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) - acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) No functional change intended. Link: https://lore.kernel.org/r/20240508174138.3630283-2-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-17 14:40:23 +00:00
bool pci_acpi_preserve_config(struct pci_host_bridge *bridge);
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;
PCI: Add pci_set_acpi_fwnode() to set ACPI_COMPANION Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 3a15955d7cf0b6c7527ee3bd97c3c355450e3fa1 commit 3a15955d7cf0b6c7527ee3bd97c3c355450e3fa1 Author: Shanker Donthineni <sdonthineni@nvidia.com> Date: Tue Aug 17 23:34:57 2021 +0530 PCI: Add pci_set_acpi_fwnode() to set ACPI_COMPANION Move the existing logic from acpi_pci_bridge_d3() to a separate function pci_set_acpi_fwnode() to set the ACPI fwnode. No functional change intended. Link: https://lore.kernel.org/r/20210817180500.1253-7-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:06:58 +00:00
void pci_set_acpi_fwnode(struct pci_dev *dev);
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
int pci_dev_acpi_reset(struct pci_dev *dev, bool probe);
PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2015786 Upstream Status: d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 commit d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Sep 20 21:17:08 2021 +0200 PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Using struct pci_platform_pm_ops for ACPI adds unnecessary indirection to the interactions between the PCI core and ACPI PM, which is also subject to retpolines. Moreover, it is not particularly clear from the current code that, as far as PCI PM is concerned, "platform" really means just ACPI except for the special casess when Intel MID PCI PM is used or when ACPI support is disabled (through the kernel config or command line, or because there are no usable ACPI tables on the system). To address the above, rework the PCI PM code to invoke ACPI PM functions directly as needed and drop the acpi_pci_platform_pm object that is not necessary any more. Accordingly, update some of the ACPI PM functions in question to do extra checks in case the ACPI support is disabled (which previously was taken care of by avoiding to set the pci_platform_ops pointer in those cases). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-07-12 19:14:39 +00:00
bool acpi_pci_power_manageable(struct pci_dev *dev);
bool acpi_pci_bridge_d3(struct pci_dev *dev);
int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state);
pci_power_t acpi_pci_get_power_state(struct pci_dev *dev);
void acpi_pci_refresh_power_state(struct pci_dev *dev);
int acpi_pci_wakeup(struct pci_dev *dev, bool enable);
bool acpi_pci_need_resume(struct pci_dev *dev);
pci_power_t acpi_pci_choose_state(struct pci_dev *pdev);
PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.c Move program_hpx_type0(), program_hpx_type1(), etc., and enums hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific. Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and drivers/pci/probe.c. Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:50 +00:00
#else
PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge() JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 9d7d5db8e78ef1b67690bbffa5af60016d8e279d commit 9d7d5db8e78ef1b67690bbffa5af60016d8e279d Author: Vidya Sagar <vidyas@nvidia.com> Date: Wed May 8 23:11:35 2024 +0530 PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge() Move the PRESERVE_BOOT_CONFIG _DSM evaluation from acpi_pci_root_create() to pci_register_host_bridge(). This will help unify the ACPI _DSM path and the DT-based "linux,pci-probe-only" paths. This should be safe because it happens earlier than it used to: acpi_pci_root_create pci_create_root_bus pci_register_host_bridge + bridge->preserve_config = pci_preserve_config(bridge) pci_acpi_preserve_config + acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) - acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) No functional change intended. Link: https://lore.kernel.org/r/20240508174138.3630283-2-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-17 14:40:23 +00:00
static inline bool pci_acpi_preserve_config(struct pci_host_bridge *bridge)
{
return false;
}
PCI: Change the type of probe argument in reset functions Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 9bdc81ce440ec6ea899b236879aee470ec388020 commit 9bdc81ce440ec6ea899b236879aee470ec388020 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:35:00 2021 +0530 PCI: Change the type of probe argument in reset functions Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:51 +00:00
static inline int pci_dev_acpi_reset(struct pci_dev *dev, bool probe)
PCI: Add support for ACPI _RST reset method Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: 6937b7dd434962377e00efc04adac0390c287199 commit 6937b7dd434962377e00efc04adac0390c287199 Author: Shanker Donthineni <sdonthineni@nvidia.com> Date: Tue Aug 17 23:34:59 2021 +0530 PCI: Add support for ACPI _RST reset method _RST is a standard ACPI method that performs a function level reset of a device (ACPI v6.3, sec 7.3.25). Add pci_dev_acpi_reset() to probe for _RST method and execute if present. The default priority of this reset is set to below device-specific and above hardware resets. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-9-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:07:37 +00:00
{
return -ENOTTY;
}
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void pci_set_acpi_fwnode(struct pci_dev *dev) { }
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)
PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.c Move program_hpx_type0(), program_hpx_type1(), etc., and enums hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific. Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and drivers/pci/probe.c. Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:50 +00:00
{
return -ENODEV;
}
PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2015786 Upstream Status: d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 commit d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Sep 20 21:17:08 2021 +0200 PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Using struct pci_platform_pm_ops for ACPI adds unnecessary indirection to the interactions between the PCI core and ACPI PM, which is also subject to retpolines. Moreover, it is not particularly clear from the current code that, as far as PCI PM is concerned, "platform" really means just ACPI except for the special casess when Intel MID PCI PM is used or when ACPI support is disabled (through the kernel config or command line, or because there are no usable ACPI tables on the system). To address the above, rework the PCI PM code to invoke ACPI PM functions directly as needed and drop the acpi_pci_platform_pm object that is not necessary any more. Accordingly, update some of the ACPI PM functions in question to do extra checks in case the ACPI support is disabled (which previously was taken care of by avoiding to set the pci_platform_ops pointer in those cases). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-07-12 19:14:39 +00:00
static inline bool acpi_pci_power_manageable(struct pci_dev *dev)
{
return false;
}
static inline bool acpi_pci_bridge_d3(struct pci_dev *dev)
{
return false;
}
static inline int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
return -ENODEV;
}
static inline pci_power_t acpi_pci_get_power_state(struct pci_dev *dev)
{
return PCI_UNKNOWN;
}
PCI: Fix code formatting inconsistencies JIRA: https://issues.redhat.com/browse/RHEL-15044 Upstream Status: eb6723b40d1766cfbbbc0aa11690da03c339184f commit eb6723b40d1766cfbbbc0aa11690da03c339184f Author: Bjorn Helgaas <bhelgaas@google.com> Date: Thu Aug 24 13:33:05 2023 -0500 PCI: Fix code formatting inconsistencies Remove unnecessary "return;" in void functions and format consistently. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-11-01 22:08:51 +00:00
static inline void acpi_pci_refresh_power_state(struct pci_dev *dev) { }
PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2015786 Upstream Status: d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 commit d97c5d4c622f6acfd5eddac81799d37c9a4e6a92 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Sep 20 21:17:08 2021 +0200 PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Using struct pci_platform_pm_ops for ACPI adds unnecessary indirection to the interactions between the PCI core and ACPI PM, which is also subject to retpolines. Moreover, it is not particularly clear from the current code that, as far as PCI PM is concerned, "platform" really means just ACPI except for the special casess when Intel MID PCI PM is used or when ACPI support is disabled (through the kernel config or command line, or because there are no usable ACPI tables on the system). To address the above, rework the PCI PM code to invoke ACPI PM functions directly as needed and drop the acpi_pci_platform_pm object that is not necessary any more. Accordingly, update some of the ACPI PM functions in question to do extra checks in case the ACPI support is disabled (which previously was taken care of by avoiding to set the pci_platform_ops pointer in those cases). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-07-12 19:14:39 +00:00
static inline int acpi_pci_wakeup(struct pci_dev *dev, bool enable)
{
return -ENODEV;
}
static inline bool acpi_pci_need_resume(struct pci_dev *dev)
{
return false;
}
static inline pci_power_t acpi_pci_choose_state(struct pci_dev *pdev)
{
return PCI_POWER_ERROR;
}
PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.c Move program_hpx_type0(), program_hpx_type1(), etc., and enums hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific. Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and drivers/pci/probe.c. Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 09:49:50 +00:00
#endif
PCI/ASPM: Add sysfs attributes for controlling ASPM link states Add sysfs attributes to Endpoints and other Upstream Ports to control ASPM, Clock PM, and L1 PM Substates. The new attributes are: /sys/devices/pci*/.../link/clkpm /sys/devices/pci*/.../link/l0s_aspm /sys/devices/pci*/.../link/l1_aspm /sys/devices/pci*/.../link/l1_1_aspm /sys/devices/pci*/.../link/l1_2_aspm /sys/devices/pci*/.../link/l1_1_pcipm /sys/devices/pci*/.../link/l1_2_pcipm An attribute is only visible if both ends of the Link leading to the device support the state. Writing y/1/on to the file enables the state; n/0/off disables it. These attributes can be used to tune the power/performance tradeoff for individual devices. [bhelgaas: commit log, rename directory to "link"] Link: https://lore.kernel.org/r/b1c83f8a-9bf6-eac5-82d0-cf5b90128fbf@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-10-05 12:07:56 +00:00
#ifdef CONFIG_PCIEASPM
extern const struct attribute_group aspm_ctrl_attr_group;
#endif
PCI: Allow userspace to query and set device reset mechanism Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2039086 Upstream Status: d88f521da3efd698e36d0d504a2abba6ac4f5ef8 commit d88f521da3efd698e36d0d504a2abba6ac4f5ef8 Author: Amey Narkhede <ameynarkhede03@gmail.com> Date: Tue Aug 17 23:34:56 2021 +0530 PCI: Allow userspace to query and set device reset mechanism Add "reset_method" sysfs attribute to enable user to query and set preferred device reset methods and their ordering. [bhelgaas: on invalid sysfs input, return error and preserve previous config, as in earlier patch versions] Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-6-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-17 22:06:46 +00:00
extern const struct attribute_group pci_dev_reset_method_attr_group;
PCI: PM: Do not use pci_platform_pm_ops for Intel MID PM Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2015786 Upstream Status: d5b0d88385f5a5f865f6761d7c93e373221914a4 commit d5b0d88385f5a5f865f6761d7c93e373221914a4 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Sep 20 21:16:59 2021 +0200 PCI: PM: Do not use pci_platform_pm_ops for Intel MID PM There are only two users of struct pci_platform_pm_ops in the tree, one of which is Intel MID PM and the other one is ACPI. They are mutually exclusive and the MID PM should take precedence when they both are enabled, but whether or not this really is the case hinges on the specific ordering of arch_initcall() calls made by them. The struct pci_platform_pm_ops abstraction is not really necessary for just these two users, but it adds complexity and overhead because of retoplines involved in using all of the function pointers in there. It also makes following the code a bit more difficult than it would be otherwise. Moreover, Intel MID PCI PM doesn't even implement the majority of the function pointers in struct pci_platform_pm_ops in a meaningful way, so switch over the PCI core to calling the relevant MID PM routines, mid_pci_set_power_state() and mid_pci_set_power_state(), directly as needed and drop mid_pci_platform_pm. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-07-12 19:13:23 +00:00
#ifdef CONFIG_X86_INTEL_MID
bool pci_use_mid_pm(void);
int mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state);
pci_power_t mid_pci_get_power_state(struct pci_dev *pdev);
#else
static inline bool pci_use_mid_pm(void)
{
return false;
}
static inline int mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state)
{
return -ENODEV;
}
static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev)
{
return PCI_UNKNOWN;
}
#endif
PCI: Add managed pcim_intx() JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: 25216afc9db53d85dc648aba8fb7f6d31f2c8731 commit 25216afc9db53d85dc648aba8fb7f6d31f2c8731 Author: Philipp Stanner <pstanner@redhat.com> Date: Thu Jun 13 13:50:23 2024 +0200 PCI: Add managed pcim_intx() pci_intx() is a "hybrid" function, i.e., it is managed if pcim_enable_device() has been called, but unmanaged otherwise. Add pcim_intx(), which is always managed, and implement pci_intx() using it. Remove the now-unused struct pci_devres.orig_intx and .restore_intx and find_pci_dr(). Link: https://lore.kernel.org/r/20240613115032.29098-11-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> [kwilczynski: squashed in https://lore.kernel.org/r/426645d40776198e0fcc942f4a6cac4433c7a9aa.camel@red hat.com to fix problem reported and tested by Ashish Kalra <Ashish.Kalra@amd.com>: https://lore.kernel.org/r/20240708214656.4721-1-Ashish.Kalra@amd.com https://lore.kernel.org/r/8c4634e9-4f02-4c54-9c89-d75e2f4bf026@amd.com/] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-16 21:13:17 +00:00
int pcim_intx(struct pci_dev *dev, int enable);
PCI: Add managed pcim_request_region() JIRA: https://issues.redhat.com/browse/RHEL-59033 Upstream Status: d47bde708086c77b1ceeb7643e600089f63dd03b commit d47bde708086c77b1ceeb7643e600089f63dd03b Author: Philipp Stanner <pstanner@redhat.com> Date: Thu Jun 13 13:50:18 2024 +0200 PCI: Add managed pcim_request_region() These existing functions: pci_request_region() pci_request_selected_regions() pci_request_selected_regions_exclusive() are "hybrid" functions built on __pci_request_region() and are managed if pcim_enable_device() has been called, but unmanaged otherwise. Add these new functions: pcim_request_region() pcim_request_region_exclusive() These are *always* managed and use the new pcim_addr_devres tracking infrastructure instead of find_pci_dr() and struct pci_devres.region_mask. Implement the hybrid functions using the new "pure" functions and remove struct pci_devres.region_mask, which is no longer needed. Link: https://lore.kernel.org/r/20240613115032.29098-6-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-09-16 20:58:13 +00:00
int pcim_request_region_exclusive(struct pci_dev *pdev, int bar,
const char *name);
void pcim_release_region(struct pci_dev *pdev, int bar);
PCI: Add standard PCI Config Address macros Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2135902 Upstream Status: 8a9b7ef74369f08a8bde2a45168056f1cad9fb2c commit 8a9b7ef74369f08a8bde2a45168056f1cad9fb2c Author: Pali Rohár <pali@kernel.org> Date: Sat Sep 24 11:24:02 2022 +0200 PCI: Add standard PCI Config Address macros Lot of PCI and PCIe controllers are using standard Config Address for PCI Configuration Mechanism #1 (as defined in PCI Local Bus Specification) or its extended version. So introduce new macros PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() in include file drivers/pci/pci.h which can be suitable for PCI and PCIe controllers which uses this type of access to PCI config space. Link: https://lore.kernel.org/r/20220924092404.31776-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-10-20 18:34:25 +00:00
/*
* Config Address for PCI Configuration Mechanism #1
*
* See PCI Local Bus Specification, Revision 3.0,
* Section 3.2.2.3.2, Figure 3-2, p. 50.
*/
#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */
#define PCI_CONF1_DEV_SHIFT 11 /* Device number */
#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */
#define PCI_CONF1_BUS_MASK 0xff
#define PCI_CONF1_DEV_MASK 0x1f
#define PCI_CONF1_FUNC_MASK 0x7
#define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */
#define PCI_CONF1_ENABLE BIT(31)
#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT)
#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT)
#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT)
#define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK)
#define PCI_CONF1_ADDRESS(bus, dev, func, reg) \
(PCI_CONF1_ENABLE | \
PCI_CONF1_BUS(bus) | \
PCI_CONF1_DEV(dev) | \
PCI_CONF1_FUNC(func) | \
PCI_CONF1_REG(reg))
/*
* Extension of PCI Config Address for accessing extended PCIe registers
*
* No standardized specification, but used on lot of non-ECAM-compliant ARM SoCs
* or on AMD Barcelona and new CPUs. Reserved bits [27:24] of PCI Config Address
* are used for specifying additional 4 high bits of PCI Express register.
*/
#define PCI_CONF1_EXT_REG_SHIFT 16
#define PCI_CONF1_EXT_REG_MASK 0xf00
#define PCI_CONF1_EXT_REG(x) (((x) & PCI_CONF1_EXT_REG_MASK) << PCI_CONF1_EXT_REG_SHIFT)
#define PCI_CONF1_EXT_ADDRESS(bus, dev, func, reg) \
(PCI_CONF1_ADDRESS(bus, dev, func, reg) | \
PCI_CONF1_EXT_REG(reg))
PCI: replace cfg space size (256/4096) by macros. This is a cleanup that changes all PCI configuration space size representations to the macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE). And the macros are also moved from drivers/pci/probe.c to drivers/pci/pci.h. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-10-13 11:18:07 +00:00
#endif /* DRIVERS_PCI_H */