#
17423360 |
|
23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
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>
|
#
0a5a46a6 |
|
06-Feb-2024 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
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>
|
#
1e11b549 |
|
23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
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>
|
#
fa84f443 |
|
23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
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>
|
#
39714fd7 |
|
05-Mar-2024 |
Ethan Zhao <haifeng.zhao@linux.intel.com> |
PCI: Make pci_dev_is_disconnected() helper public for other drivers Make pci_dev_is_disconnected() public so that it can be called from Intel VT-d driver to quickly fix/workaround the surprise removal unplug hang issue for those ATS capable devices on PCIe switch downstream hotplug capable ports. Beside pci_device_is_present() function, this one has no config space space access, so is light enough to optimize the normal pure surprise removal and safe removal flow. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Tested-by: Haorong Ye <yehaorong@bytedance.com> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> Link: https://lore.kernel.org/r/20240301080727.3529832-2-haifeng.zhao@linux.intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
2ea548a3 |
|
30-Oct-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI: Remove obsolete pci_cleanup_rom() declaration Commit d9c8bea179a6 ("PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY") removed pci_cleanup_rom(), but retained its declaration in pci.h. Remove it. Link: https://lore.kernel.org/r/fc30de5276e21d5a3ebcb7e58a8b43e399f7e6e6.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>
|
#
be9c3a4c |
|
30-Oct-2023 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
815a3909 |
|
31-Jan-2024 |
Philipp Stanner <pstanner@redhat.com> |
PCI: Move devres code from pci.c to devres.c The file pci.c is very large and contains a number of devres functions. These functions should now reside in devres.c. Move as much devres-specific code from pci.c to devres.c as possible. There are a few callers left in pci.c that do devres operations. These should be ported in the future. Add corresponding TODOs. The reason they are not moved right now in this commit is that PCI's devres currently implements a sort of "hybrid-mode": pci_request_region(), for instance, does not have a corresponding pcim_ equivalent, yet. Instead, the function can be made managed by previously calling pcim_enable_device() (instead of pci_enable_device()). This makes it unreasonable to move pci_request_region() to devres.c. Moving the functions would require changes to PCI's API and is, therefore, left for future work. In summary, this commit serves as a preparation step for a following patch series that will cleanly separate the PCI's managed and unmanaged API. Link: https://lore.kernel.org/r/20240131090023.12331-5-pstanner@redhat.com Suggested-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1e560864 |
|
30-Jan-2024 |
Johan Hovold <johan+linaro@kernel.org> |
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
|
#
ac4f1897 |
|
02-Jan-2024 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
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>
|
#
65f8e0be |
|
06-Nov-2021 |
Puranjay Mohan <puranjay12@gmail.com> |
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>
|
#
f93e71ae |
|
31-Dec-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()" This reverts commit 08d0cc5f34265d1a1e3031f319f594bd1970976c. Michael reported that when attempting to resume from suspend to RAM on ASUS mini PC PN51-BB757MDE1 (DMI model: MINIPC PN51-E1), 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") caused a 12-second delay with no output, followed by a reboot. Workarounds include: - Reverting 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") - Booting with "pcie_aspm=off" - Booting with "pcie_aspm.policy=performance" - "echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm" before suspending - Connecting a USB flash drive Link: https://lore.kernel.org/r/20240102232550.1751655-1-helgaas@kernel.org Fixes: 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") Reported-by: Michael Schaller <michael@5challer.de> Link: https://lore.kernel.org/r/76c61361-b8b4-435f-a9f1-32b716763d62@5challer.de Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: <stable@vger.kernel.org>
|
#
164f66be |
|
18-Oct-2023 |
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> |
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>
|
#
eb6723b4 |
|
24-Aug-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
e78bd50b |
|
21-Aug-2023 |
Frank Li <Frank.Li@nxp.com> |
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>
|
#
407d1a51 |
|
15-Aug-2023 |
Lizhi Hou <lizhi.hou@amd.com> |
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>
|
#
a89c8224 |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
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>
|
#
680e9c47 |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Add support for polling DLLLA to pcie_retrain_link() Let the caller of pcie_retrain_link() specify whether they want to use the LT bit or the DLLLA bit of the Link Status Register to determine if link training has completed. It is up to the caller to verify whether the use of the DLLLA bit, the implementation of which is optional, is valid for the device requested. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2306110310540.64925@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
37edd87e |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Export pcie_retrain_link() for use outside ASPM Export pcie_retrain_link() for link retrain needs outside ASPM. Struct pcie_link_state is local to ASPM and only used by pcie_retrain_link() to get at the associated PCI device, so change the operand and adjust the lone call site accordingly. Document the interface. No functional change at this point. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2306110229010.64925@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
33a176ab |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
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>
|
#
ba3da667 |
|
09-Jun-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
7b3ba09f |
|
25-Apr-2023 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Shorten pci_bridge_wait_for_secondary_bus() wait time for slow links With slow links (<= 5GT/s) active link reporting is not mandatory, so if a device is disconnected during system sleep we might end up waiting for it to respond for ~60s, which slows down resume time. PCIe r6.0, sec 6.6.1, mandates that software must wait for at least 1s before it can assume a device is broken, so use that minimum requirement for slow links and bail out if the device doesn't respond within 1s. However, if the port supports active link reporting we can wait longer as we do with the fast links. This should make system resume time faster for slow links as well while still following the PCIe spec. While there move the PCI_RESET_WAIT constant into pci.c because it is not used outside of that file anymore. Link: https://lore.kernel.org/r/20230425064751.24951-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: Lukas Wunner <lukas@wunner.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
|
#
ac048403 |
|
11-Mar-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI/DOE: Create mailboxes on device enumeration 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>
|
#
e74b2b58 |
|
04-Apr-2023 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
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>
|
#
0d21e71a |
|
19-Apr-2023 |
Rob Herring <robh@kernel.org> |
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>
|
#
74ff8864 |
|
20-Jan-2023 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
53b54ad0 |
|
15-Jan-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI/DPC: Await readiness of secondary bus after reset pci_bridge_wait_for_secondary_bus() is called after a Secondary Bus Reset, but not after a DPC-induced Hot Reset. As a result, the delays prescribed by PCIe r6.0 sec 6.6.1 are not observed and devices on the secondary bus may be accessed before they're ready. One affected device is Intel's Ponte Vecchio HPC GPU. It comprises a PCIe switch whose upstream port is not immediately ready after reset. Because its config space is restored too early, it remains in D0uninitialized, its subordinate devices remain inaccessible and DPC recovery fails with messages such as: i915 0000:8c:00.0: can't change power state from D3cold to D0 (config space inaccessible) intel_vsec 0000:8e:00.1: can't change power state from D3cold to D0 (config space inaccessible) pcieport 0000:89:02.0: AER: device recovery failed Fix it. Link: https://lore.kernel.org/r/9f5ff00e1593d8d9a4b452398b98aa14d23fca11.1673769517.git.lukas@wunner.de Tested-by: Ravi Kishore Koppuravuri <ravi.kishore.koppuravuri@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org
|
#
ac91e698 |
|
15-Jan-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI: Unify delay handling for reset and resume Sheng Bi reports that pci_bridge_secondary_bus_reset() may fail to wait for devices on the secondary bus to become accessible after reset: Although it does call pci_dev_wait(), it erroneously passes the bridge's pci_dev rather than that of a child. The bridge of course is always accessible while its secondary bus is reset, so pci_dev_wait() returns immediately. Sheng Bi proposes introducing a new pci_bridge_secondary_bus_wait() function which is called from pci_bridge_secondary_bus_reset(): https://lore.kernel.org/linux-pci/20220523171517.32407-1-windy.bi.enflame@gmail.com/ However we already have pci_bridge_wait_for_secondary_bus() which does almost exactly what we need. So far it's only called on resume from D3cold (which implies a Fundamental Reset per PCIe r6.0 sec 5.8). Re-using it for Secondary Bus Resets is a leaner and more rational approach than introducing a new function. That only requires a few minor tweaks: - Amend pci_bridge_wait_for_secondary_bus() to await accessibility of the first device on the secondary bus by calling pci_dev_wait() after performing the prescribed delays. pci_dev_wait() needs two parameters, a reset reason and a timeout, which callers must now pass to pci_bridge_wait_for_secondary_bus(). The timeout is 1 sec for resume (PCIe r6.0 sec 6.6.1) and 60 sec for reset (commit 821cdad5c46c ("PCI: Wait up to 60 seconds for device to become ready after FLR")). Introduce a PCI_RESET_WAIT macro for the 1 sec timeout. - Amend pci_bridge_wait_for_secondary_bus() to return 0 on success or -ENOTTY on error for consumption by pci_bridge_secondary_bus_reset(). - Drop an unnecessary 1 sec delay from pci_reset_secondary_bus() which is now performed by pci_bridge_wait_for_secondary_bus(). A static delay this long is only necessary for Conventional PCI, so modern PCIe systems benefit from shorter reset times as a side effect. Fixes: 6b2f1351af56 ("PCI: Wait for device to become ready after secondary bus reset") Link: https://lore.kernel.org/r/da77c92796b99ec568bd070cbe4725074a117038.1673769517.git.lukas@wunner.de Reported-by: Sheng Bi <windy.bi.enflame@gmail.com> Tested-by: Ravi Kishore Koppuravuri <ravi.kishore.koppuravuri@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: stable@vger.kernel.org # v4.17+
|
#
a7152be7 |
|
03-Feb-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI/ASPM: Save L1 PM Substates Capability for suspend/resume" This reverts commit 4ff116d0d5fd8a025604b0802d93a2d5f4e465d1. Tasev Nikola and Mark Enriquez reported that resume from suspend was broken in v6.1-rc1. Tasev bisected to a47126ec29f5 ("PCI/PTM: Cache PTM Capability offset"), but we can't figure out how that could be related. Mark saw the same symptoms and bisected to 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume"), which does have a connection: it restores L1 Substates configuration while ASPM L1 may be enabled: pci_restore_state pci_restore_aspm_l1ss_state aspm_program_l1ss pci_write_config_dword(PCI_L1SS_CTL1, ctl1) # L1SS restore pci_restore_pcie_state pcie_capability_write_word(PCI_EXP_LNKCTL, cap[i++]) # L1 restore which is a problem because PCIe r6.0, sec 5.5.4, requires that: If setting either or both of the enable bits for ASPM L1 PM Substates, both ports must be configured as described in this section while ASPM L1 is disabled. Separately, Thomas Witt reported that 5e85eba6f50d ("PCI/ASPM: Refactor L1 PM Substates Control Register programming") broke suspend/resume, and it depends on 4ff116d0d5fd. Revert 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") to fix the resume issue and enable revert of 5e85eba6f50d to fix the issue Thomas reported. Note that reverting 4ff116d0d5fd means L1 Substates config may be lost on suspend/resume. As far as we know the system will use more power but will still *work* correctly. Fixes: 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216782 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877 Reported-by: Tasev Nikola <tasev.stefanoska@skynet.be> Reported-by: Mark Enriquez <enriquezmark36@gmail.com> Reported-by: Thomas Witt <kernel@witt.link> Tested-by: Mark Enriquez <enriquezmark36@gmail.com> Tested-by: Thomas Witt <kernel@witt.link> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v6.1+ Cc: Vidya Sagar <vidyas@nvidia.com>
|
#
503fa236 |
|
17-Sep-2022 |
Maciej W. Rozycki <macro@orcam.me.uk> |
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>
|
#
4ff116d0 |
|
13-Sep-2022 |
Vidya Sagar <vidyas@nvidia.com> |
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume Previously the L1 PM Substates Control Registers (CTL1 and CTL2) weren't saved and restored during suspend/resume leading to the L1 PM Substates configuration being lost post-resume. Save the L1 PM Substates Control Registers so that the configuration is retained post-resume. [bhelgaas: drop pci_is_pcie() testing; we can rely on pci_configure_ltr() having already done that] Link: https://lore.kernel.org/r/20220913131822.16557-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8a9b7ef7 |
|
24-Sep-2022 |
Pali Rohár <pali@kernel.org> |
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>
|
#
d736d292 |
|
09-Sep-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
e8bdc5ea |
|
09-Sep-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
08d0cc5f |
|
11-Jul-2022 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
PCI/ASPM: Remove pcie_aspm_pm_state_change() pcie_aspm_pm_state_change() was introduced at the inception of PCIe ASPM code, but it can cause some issues. For instance, when ASPM config is changed via sysfs, those changes won't persist across power state change because pcie_aspm_pm_state_change() overwrites them. Also, if the driver restores L1SS [1] after system resume, the restored state will also be overwritten by pcie_aspm_pm_state_change(). Remove pcie_aspm_pm_state_change(). If there's any hardware that really needs it to function, a quirk can be used instead. [1] https://lore.kernel.org/linux-pci/20220201123536.12962-1-vidyas@nvidia.com/ Link: https://lore.kernel.org/r/20220509073639.2048236-1-kai.heng.feng@canonical.com [bhelgaas: remove additional pcie_aspm_pm_state_change() call in pci_set_low_power_state(), added by 10aa5377fc8a ("PCI/PM: Split pci_raw_set_power_state()") and moved by 7957d201456f ("PCI/PM: Relocate pci_set_low_power_state()")] Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
35662423 |
|
12-Apr-2022 |
Pali Rohár <pali@kernel.org> |
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>
|
#
e1b0d0bb |
|
12-Oct-2021 |
Mingchuang Qiao <mingchuang.qiao@mediatek.com> |
PCI: Re-enable Downstream Port LTR after reset or hotplug Per PCIe r5.0, sec 7.5.3.16, Downstream Ports must disable LTR if the link goes down (the Port goes DL_Down status). This is a problem because the Downstream Port's dev->ltr_path is still set, so we think LTR is still enabled, and we enable LTR in the Endpoint. When it sends LTR messages, they cause Unsupported Request errors at the Downstream Port. This happens in the reset path, where we may enable LTR in pci_restore_pcie_state() even though the Downstream Port disabled LTR because the reset caused a link down event. It also happens in the hot-remove and hot-add path, where we may enable LTR in pci_configure_ltr() even though the Downstream Port disabled LTR when the hot-remove took the link down. In these two scenarios, check the upstream bridge and restore its LTR enable if appropriate. The Unsupported Request may be logged by AER as follows: pcieport 0000:00:1d.0: AER: Uncorrected (Non-Fatal) error received: id=00e8 pcieport 0000:00:1d.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=00e8(Requester ID) pcieport 0000:00:1d.0: device [8086:9d18] error status/mask=00100000/00010000 pcieport 0000:00:1d.0: [20] Unsupported Request (First) In addition, if LTR is not configured correctly, the link cannot enter the L1.2 state, which prevents some machines from entering the S0ix low power state. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20211012075614.54576-1-mingchuang.qiao@mediatek.com Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com> Signed-off-by: Mingchuang Qiao <mingchuang.qiao@mediatek.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
98634aa8 |
|
20-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Drop struct pci_platform_pm_ops After previous changes there are no more users of struct pci_platform_pm_ops in the tree, so drop it along with all of the remaining related code. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
d97c5d4c |
|
20-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
d5b0d883 |
|
20-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
f0ab0017 |
|
02-Aug-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
9bdc81ce |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
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>
|
#
6937b7dd |
|
17-Aug-2021 |
Shanker Donthineni <sdonthineni@nvidia.com> |
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>
|
#
3a15955d |
|
17-Aug-2021 |
Shanker Donthineni <sdonthineni@nvidia.com> |
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>
|
#
d88f521d |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
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>
|
#
e20afa06 |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
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.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>
|
#
1d71eb53 |
|
26-Jul-2021 |
Vinicius Costa Gomes <vinicius.gomes@intel.com> |
Revert "PCI: Make pci_enable_ptm() private" Make pci_enable_ptm() accessible from the drivers. Exposing this to the driver enables the driver to use the 'ptm_enabled' field of 'pci_dev' to check if PTM is enabled or not. This reverts commit ac6c26da29c1 ("PCI: Make pci_enable_ptm() private"). Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
#
347269c1 |
|
03-Jul-2021 |
Krzysztof Wilczyński <kw@linux.com> |
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>
|
#
a97396c6 |
|
01-May-2021 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
e947e7b1 |
|
01-Apr-2021 |
Heiner Kallweit <hkallweit1@gmail.com> |
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>
|
#
506140f9 |
|
27-Apr-2021 |
Krzysztof Wilczyński <kw@linux.com> |
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>
|
#
d93f8399 |
|
16-Apr-2021 |
Krzysztof Wilczyński <kw@linux.com> |
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>
|
#
16f7ae59 |
|
08-Mar-2021 |
Arnd Bergmann <arnd@arndb.de> |
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>
|
#
c3d5c2d9 |
|
04-Apr-2021 |
Leon Romanovsky <leon@kernel.org> |
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>
|
#
8fbdbb66 |
|
05-Jan-2021 |
Darren Salt <devspam@moreofthesa.me.uk> |
PCI: Export pci_rebar_get_possible_sizes() Export pci_rebar_get_possible_sizes() for use by modular drivers. Signed-off-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20210107175017.15893-2-nirmoy.das@amd.com
|
#
40fb68c7 |
|
27-Jan-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI/ASPM: Save/restore L1SS Capability for suspend/resume" This reverts commit 4257f7e008ea394fcecc050f1569c3503b8bcc15. Kenneth reported that after 4257f7e008ea, he sees a torrent of disk I/O errors on his NVMe device after suspend/resume until a reboot. Link: https://lore.kernel.org/linux-pci/20201228040513.GA611645@bjorn-Precision-5520/ Reported-by: Kenneth R. Crudup <kenny@panix.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a697f072 |
|
07-Dec-2020 |
David E. Box <david.e.box@linux.intel.com> |
PCI: Disable PTM during suspend to save power There are systems (for example, Intel based mobile platforms since Coffee Lake) where the power drawn while suspended can be significantly reduced by disabling Precision Time Measurement (PTM) on PCIe root ports as this allows the port to enter a lower-power PM state and the SoC to reach a lower-power idle state. To save this power, disable the PTM feature on root ports during pci_prepare_to_sleep() and pci_finish_runtime_suspend(). The feature will be returned to its previous state during restore and error recovery. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209361 Link: https://lore.kernel.org/r/20201207223951.19667-2-david.e.box@linux.intel.com Reported-by: Len Brown <len.brown@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
39850ed5 |
|
07-Dec-2020 |
David E. Box <david.e.box@linux.intel.com> |
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>
|
#
af113553 |
|
20-Nov-2020 |
Sean V Kelley <sean.v.kelley@intel.com> |
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>
|
#
507b460f |
|
20-Nov-2020 |
Sean V Kelley <sean.v.kelley@intel.com> |
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>
|
#
830dfe88 |
|
02-Dec-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/MSI: Move MSI/MSI-X flags updaters to msi.c pci_msi_set_enable() and pci_msix_clear_and_set_ctrl() are only used from msi.c, so move them from drivers/pci/pci.h to msi.c. No functional change intended. Link: https://lore.kernel.org/r/20201203185110.1583077-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thierry Reding <treding@nvidia.com>
|
#
cbc40d5c |
|
02-Dec-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
8f1bbfbc |
|
20-Nov-2020 |
Sean V Kelley <sean.v.kelley@intel.com> |
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>
|
#
90655631 |
|
20-Nov-2020 |
Sean V Kelley <sean.v.kelley@intel.com> |
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>
|
#
34191749 |
|
18-Nov-2020 |
Gustavo Pimentel <Gustavo.Pimentel@synopsys.com> |
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>
|
#
4257f7e0 |
|
24-Oct-2020 |
Vidya Sagar <vidyas@nvidia.com> |
PCI/ASPM: Save/restore L1SS Capability for suspend/resume Previously ASPM L1 Substates control registers (CTL1 and CTL2) weren't saved and restored during suspend/resume leading to L1 Substates configuration being lost post-resume. Save the L1 Substates control registers so that the configuration is retained post-resume. Link: https://lore.kernel.org/r/20201024190442.871-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
638c133e |
|
29-Sep-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
454d082d |
|
29-Sep-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Remove unused PCI_PM_BUS_WAIT 476e7faefc43 ("PCI PM: Do not wait for buses in B2 or B3 during resume") removed the last use of PCI_PM_BUS_WAIT. Remove the definition as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3789af9a |
|
30-Jul-2020 |
Krzysztof Wilczyński <kw@linux.com> |
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>
|
#
669cbc70 |
|
21-Jul-2020 |
Rob Herring <robh@kernel.org> |
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>
|
#
600a5b4f |
|
16-Jul-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
52fbf5bd |
|
07-Jul-2020 |
Rajat Jain <rajatja@google.com> |
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>
|
#
16d79cd4 |
|
02-Jul-2020 |
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> |
PCI: Use 'pci_channel_state_t' instead of 'enum pci_channel_state' The method struct pci_error_handlers.error_detected() is defined and documented as taking an 'enum pci_channel_state' for the second argument, but most drivers use 'pci_channel_state_t' instead. This 'pci_channel_state_t' is not a typedef for the enum but a typedef for a bitwise type in order to have better/stricter typechecking. Consolidate everything by using 'pci_channel_state_t' in the method's definition, in the related helpers and in the drivers. Enforce use of 'pci_channel_state_t' by replacing 'enum pci_channel_state' with an anonymous 'enum'. Note: Currently, from a typechecking point of view this patch changes nothing because only the constants defined by the enum are bitwise, not the enum itself (sparse doesn't have the notion of 'bitwise enum'). This may change in some not too far future, hence the patch. [bhelgaas: squash in https://lore.kernel.org/r/20200702162651.49526-3-luc.vanoostenryck@gmail.com https://lore.kernel.org/r/20200702162651.49526-4-luc.vanoostenryck@gmail.com] Link: https://lore.kernel.org/r/20200702162651.49526-2-luc.vanoostenryck@gmail.com Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
894020fd |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
aea47413 |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
20e15e67 |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
27005618 |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
e8e5ff2a |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
b6cf1a42 |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
PCI/ERR: Remove service dependency in pcie_do_recovery() Previously we passed the PCIe service type parameter to pcie_do_recovery(), where reset_link() looked up the underlying pci_port_service_driver and its .reset_link() function pointer. Instead of using this roundabout way, we can just pass the driver-specific .reset_link() callback function when calling pcie_do_recovery() function. This allows us to call pcie_do_recovery() from code that is not a PCIe port service driver, e.g., Error Disconnect Recover (EDR) support. Remove pcie_port_find_service() and pcie_port_service_driver.reset_link since they are now unused. Link: https://lore.kernel.org/r/60e02b87b526cdf2930400059d98704bf0a147d1.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>
|
#
757bfaa2 |
|
17-Feb-2020 |
Yicong Yang <yangyicong@hisilicon.com> |
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>
|
#
6348a34d |
|
28-Feb-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use pci_speed_string() for all PCI/PCI-X/PCIe strings Previously some PCI speed strings came from pci_speed_string(), some came from the PCIe-specific PCIE_SPEED2STR(), and some came from a PCIe-specific switch statement. These methods were inconsistent: pci_speed_string() PCIE_SPEED2STR() switch ------------------ ---------------- ------ 33 MHz PCI ... 2.5 GT/s PCIe 2.5 GT/s 2.5 GT/s 5.0 GT/s PCIe 5 GT/s 5 GT/s 8.0 GT/s PCIe 8 GT/s 8 GT/s 16.0 GT/s PCIe 16 GT/s 16 GT/s 32.0 GT/s PCIe 32 GT/s 32 GT/s Standardize on pci_speed_string() as the single source of these strings. Note that this adds ".0" and "PCIe" to some messages, including sysfs "max_link_speed" files, a brcmstb "link up" message, and the link status dmesg logging, e.g., nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) I think it's better to standardize on a single version of the speed text. Previously we had strings like this: /sys/bus/pci/slots/0/cur_bus_speed: 8.0 GT/s PCIe /sys/bus/pci/slots/0/max_bus_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8 GT/s /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8 GT/s This changes the latter two to match the slots files: /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8.0 GT/s PCIe Based-on-patch by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
e56faff5 |
|
28-Feb-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
9cb3985a |
|
17-Feb-2020 |
Yicong Yang <yangyicong@hisilicon.com> |
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>
|
#
f8bf2aeb |
|
10-Dec-2019 |
James Sewart <jamessewart@arista.com> |
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>
|
#
87e90283 |
|
05-Oct-2019 |
Heiner Kallweit <hkallweit1@gmail.com> |
PCI/ASPM: Remove PCIEASPM_DEBUG Kconfig option and related code Previously, CONFIG_PCIEASPM_DEBUG enabled "link_state" and "clk_ctl" sysfs files that controlled ASPM. We believe these files were rarely if ever used. We recently added sysfs ASPM controls that are always present, so the debug code is no longer needed. Removing this debug code has been discussed for quite some time, see e.g. [0]. Remove PCIEASPM_DEBUG and the related code. [0] https://lore.kernel.org/lkml/20180727202619.GD173328@bhelgaas-glaptop.roam.corp.google.com/ Link: https://lore.kernel.org/r/ec935d8e-c084-3938-f1d1-748617596b25@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
72ea91af |
|
05-Oct-2019 |
Heiner Kallweit <hkallweit1@gmail.com> |
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>
|
#
ad9001f2 |
|
11-Nov-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Add missing link delays required by the PCIe spec Currently Linux does not follow PCIe spec regarding the required delays after reset. A concrete example is a Thunderbolt add-in-card that consists of a PCIe switch and two PCIe endpoints: +-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller +-01.0-[04-36]-- DS hotplug port +-02.0-[37]----00.0 xHCI controller \-04.0-[38-6b]-- DS hotplug port The root port (1b.0) and the PCIe switch downstream ports are all PCIe Gen3 so they support 8GT/s link speeds. We wait for the PCIe hierarchy to enter D3cold (runtime): pcieport 0000:00:1b.0: power state changed by ACPI to D3cold When it wakes up from D3cold, according to the PCIe 5.0 section 5.8 the PCIe switch is put to reset and its power is re-applied. This means that we must follow the rules in PCIe 5.0 section 6.6.1. For the PCIe Gen3 ports we are dealing with here, the following applies: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Translating this into the above topology we would need to do this (DLLLA stands for Data Link Layer Link Active): 0000:00:1b.0: wait for 100 ms after DLLLA is set before access to 0000:01:00.0 0000:02:00.0: wait for 100 ms after DLLLA is set before access to 0000:03:00.0 0000:02:02.0: wait for 100 ms after DLLLA is set before access to 0000:37:00.0 I've instrumented the kernel with some additional logging so we can see the actual delays performed: pcieport 0000:00:1b.0: power state changed by ACPI to D0 pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms For the switch upstream port (01:00.0 reachable through 00:1b.0 root port) we wait for 100 ms but not taking into account the DLLLA requirement. We then wait 10 ms for D3hot -> D0 transition of the root port and the two downstream hotplug ports. This means that we deviate from what the spec requires. Performing the same check for system sleep (s2idle) transitions it turns out to be even worse. None of the mandatory delays are performed. If this would be S3 instead of s2idle then according to PCI FW spec 3.2 section 4.6.8. there is a specific _DSM that allows the OS to skip the delays but this platform does not provide the _DSM and does not go to S3 anyway so no firmware is involved that could already handle these delays. On this particular platform these delays are not actually needed because there is an additional delay as part of the ACPI power resource that is used to turn on power to the hierarchy but since that additional delay is not required by any of standards (PCIe, ACPI) it is not present in the Intel Ice Lake, for example where missing the mandatory delays causes pciehp to start tearing down the stack too early (links are not yet trained). Below is an example how it looks like when this happens: pcieport 0000:83:04.0: pciehp: Slot(4): Card not present pcieport 0000:87:04.0: PME# disabled pcieport 0000:83:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:86:00 pcieport 0000:86:00.0: Refused to change power state, currently in D3 pcieport 0000:86:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x201ff) pcieport 0000:86:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) ... There is also one reported case (see the bugzilla link below) where the missing delay causes xHCI on a Titan Ridge controller fail to runtime resume when USB-C dock is plugged. This does not involve pciehp but instead the PCI core fails to runtime resume the xHCI device: pcieport 0000:04:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:04:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100406) xhci_hcd 0000:39:00.0: Refused to change power state, currently in D3 xhci_hcd 0000:39:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x1ff) xhci_hcd 0000:39:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) ... Add a new function pci_bridge_wait_for_secondary_bus() that is called on PCI core resume and runtime resume paths accordingly if the bridge entered D3cold (and thus went through reset). This is second attempt to add the missing delays. The previous solution in c2bf1fc212f7 ("PCI: Add missing link delays required by the PCIe spec") was reverted because of two issues it caused: 1. One system become unresponsive after S3 resume due to PME service spinning in pcie_pme_work_fn(). The root port in question reports that the xHCI sent PME but the xHCI device itself does not have PME status set. The PME status bit is never cleared in the root port resulting the indefinite loop in pcie_pme_work_fn(). 2. Slows down resume if the root/downstream port does not support Data Link Layer Active Reporting because pcie_wait_for_link_delay() waits 1100 ms in that case. This version should avoid the above issues because we restrict the delay to happen only if the port went into D3cold. Link: https://lore.kernel.org/linux-pci/SL2P216MB01878BBCD75F21D882AEEA2880C60@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=203885 Link: https://lore.kernel.org/r/20191112091617.70282-3-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
adfac8f6 |
|
05-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
3b55809c |
|
28-Oct-2019 |
Rob Herring <robh@kernel.org> |
PCI: Make devm_of_pci_get_host_bridge_resources() static Now that all the PCI host drivers are using pci_parse_request_of_pci_ranges(), make devm_of_pci_get_host_bridge_resources() static. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
|
#
331f6345 |
|
30-Oct-2019 |
Rob Herring <robh@kernel.org> |
PCI: of: Add inbound resource parsing to helpers Extend devm_of_pci_get_host_bridge_resources() and pci_parse_request_of_pci_ranges() helpers to also parse the inbound addresses from DT 'dma-ranges' and populate a resource list with the translated addresses. This will help ensure 'dma-ranges' is always parsed in a consistent way. Tested-by: Srinath Mannam <srinath.mannam@broadcom.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> # for AArdvark Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Will Deacon <will@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Toan Le <toan@os.amperecomputing.com> Cc: Ley Foon Tan <lftan@altera.com> Cc: Tom Joseph <tjoseph@cadence.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in> Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Cc: Simon Horman <horms@verge.net.au> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Michal Simek <michal.simek@xilinx.com> Cc: rfi@lists.rocketboards.org Cc: linux-mediatek@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org
|
#
d7b8a217 |
|
22-Oct-2019 |
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> |
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>
|
#
af65d1ad |
|
18-Oct-2019 |
Patel, Mayurkumar <mayurkumar.patel@intel.com> |
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>
|
#
fef2dd8b |
|
09-Oct-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
751035b8 |
|
05-Sep-2019 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
c065190b |
|
05-Sep-2019 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
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>
|
#
984998e3 |
|
22-Aug-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
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>
|
#
4a2dbedd |
|
27-Aug-2019 |
Krzysztof Wilczynski <kw@linux.com> |
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>
|
#
8c3aac6e |
|
27-Aug-2019 |
Krzysztof Wilczynski <kw@linux.com> |
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>
|
#
aaee0c1f |
|
13-Aug-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
PCI/IOV: Move sysfs SR-IOV functions to iov.c The sysfs SR-IOV functions are only needed when the kernel is built with SR-IOV support. Rather than put them in pci-sysfs.c under #ifdef CONFIG_PCI_IOV, move them to iov.c, which is only compiled when CONFIG_PCI_IOV=y. Link: https://lore.kernel.org/r/20190813204513.4790-4-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Donald Dutile <ddutile@redhat.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
|
#
0617bded |
|
07-Aug-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
Revert "PCI: Add missing link delays required by the PCIe spec" Commit c2bf1fc212f7 ("PCI: Add missing link delays required by the PCIe spec") turned out causing issues with some systems either by making them unresponsive or slowing down runtime and system wide resume of PCIe devices. While root cause for the unresponsiveness is still under investigation given the amount of issues reported better to revert it for now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204413 Link: https://lore.kernel.org/linux-pci/SL2P216MB01878BBCD75F21D882AEEA2880C60@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM/ Link: https://lore.kernel.org/linux-pci/2857501d-c167-547d-c57d-d5d24ea1f1dc@molgen.mpg.de/ Reported-by: Matthias Andree <matthias.andree@gmx.de> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
621f7e35 |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
ac6c26da |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
PCI: Make pci_enable_ptm() private This interface: int pci_enable_ptm(struct pci_dev *dev, u8 *granularity); 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-11-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
72bde9ce |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
b92b512a |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
5da78d95 |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
PCI: Make pcie_update_link_speed() private This interface: void pcie_update_link_speed(struct pci_bus *bus, u16 link_status); 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-8-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ecd29c1a |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
003d3b2c |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
440589dd |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
975e1ac1 |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
669696eb |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
c776dd50 |
|
24-Jul-2019 |
Kelsey Skunberg <skunberg.kelsey@gmail.com> |
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>
|
#
76bf6a86 |
|
13-Jun-2019 |
Alex Williamson <alex.williamson@redhat.com> |
Revert "PCI/IOV: Use VF0 cached config space size for other VFs" Revert 975bb8b4dc93 ("PCI/IOV: Use VF0 cached config space size for other VFs"), which attempted to cache the config space size from the first VF to re-use for subsequent VFs. The cached value was determined prior to discovering the PCIe capability on the VF, which resulted in the first VF reporting the correct config space size (4K), as it has a special case through pci_cfg_space_size(), while all the other VFs only reported 256 bytes. As this was only a performance optimization, we're better off without it. Fixes: 975bb8b4dc93 ("PCI/IOV: Use VF0 cached config space size for other VFs") Link: https://lore.kernel.org/r/156046663197.29869.3633634445109057665.stgit@gimli.home Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: KarimAllah Ahmed <karahmed@amazon.de> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Hao Zheng <yinhe@linux.alibaba.com>
|
#
b51033e0 |
|
25-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
c2bf1fc2 |
|
12-Jun-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Add missing link delays required by the PCIe spec Currently Linux does not follow PCIe spec regarding the required delays after reset. A concrete example is a Thunderbolt add-in-card that consists of a PCIe switch and two PCIe endpoints: +-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller +-01.0-[04-36]-- DS hotplug port +-02.0-[37]----00.0 xHCI controller \-04.0-[38-6b]-- DS hotplug port The root port (1b.0) and the PCIe switch downstream ports are all PCIe gen3 so they support 8GT/s link speeds. We wait for the PCIe hierarchy to enter D3cold (runtime): pcieport 0000:00:1b.0: power state changed by ACPI to D3cold When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the PCIe switch is put to reset and its power is re-applied. This means that we must follow the rules in PCIe 4.0 section 6.6.1. For the PCIe gen3 ports we are dealing with here, the following applies: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Translating this into the above topology we would need to do this (DLLLA stands for Data Link Layer Link Active): pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0 pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0 pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0 I've instrumented the kernel with additional logging so we can see the actual delays the kernel performs: pcieport 0000:00:1b.0: power state changed by ACPI to D0 pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms pcieport 0000:00:1b.0: waking up bus pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60) ... pcieport 0000:00:1b.0: PME# disabled pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:01:00.0: PME# disabled pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:02:00.0: PME# disabled pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407) pcieport 0000:02:01.0: PME# disabled pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:02:02.0: PME# disabled pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:02:04.0: PME# disabled pcieport 0000:02:01.0: PME# enabled pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms pcieport 0000:02:04.0: PME# enabled pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000) ... thunderbolt 0000:03:00.0: PME# disabled xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000) ... xhci_hcd 0000:37:00.0: PME# disabled For the switch upstream port (01:00.0) we wait for 100ms but not taking into account the DLLLA requirement. We then wait 10ms for D3hot -> D0 transition of the root port and the two downstream hotplug ports. This means that we deviate from what the spec requires. Performing the same check for system sleep (s2idle) transitions we can see following when resuming from s2idle: pcieport 0000:00:1b.0: power state changed by ACPI to D0 pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60) ... pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) ... pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0) pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0) pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff) pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1) pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60) pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0) pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60) pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60) pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0) pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1) pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60) pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001) pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0) pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702) pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001) pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00) pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1) pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400) pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151) pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00) pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161) pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402) pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1) pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802) pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407) pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302) pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407) pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407) pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407) xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000) ... thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000) This is even worse. None of the mandatory delays are performed. If this would be S3 instead of s2idle then according to PCI FW spec 3.2 section 4.6.8. there is a specific _DSM that allows the OS to skip the delays but this platform does not provide the _DSM and does not go to S3 anyway so no firmware is involved that could already handle these delays. In this particular Intel Coffee Lake platform these delays are not actually needed because there is an additional delay as part of the ACPI power resource that is used to turn on power to the hierarchy but since that additional delay is not required by any of standards (PCIe, ACPI) it is not present in the Intel Ice Lake, for example where missing the mandatory delays causes pciehp to start tearing down the stack too early (links are not yet trained). For this reason, change the PCIe portdrv PM resume hooks so that they perform the mandatory delays before the downstream component gets resumed. We perform the delays before port services are resumed because otherwise pciehp might find that the link is not up (even if it is just training) and tears-down the hierarchy. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0c7376ad |
|
06-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
31f996ef |
|
12-Apr-2019 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
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+
|
#
0fa635ae |
|
19-Mar-2019 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
2209e06f |
|
28-Nov-2018 |
Alexandru Gagniuc <mr.nuke.me@gmail.com> |
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>
|
#
975bb8b4 |
|
11-Oct-2018 |
KarimAllah Ahmed <karahmed@amazon.de> |
PCI/IOV: Use VF0 cached config space size for other VFs Cache the config space size from VF0 and use it for all other VFs instead of reading it from the config space of each VF. We assume that it will be the same across all associated VFs. This is an optimization when enabling SR-IOV on a device with many VFs. Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de> [bhelgaas: use CONFIG_PCI_IOV (not CONFIG_PCI_ATS)] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
26ad34d5 |
|
27-Sep-2018 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI / ACPI: Whitelist D3 for more PCIe hotplug ports In order to have better power management for Thunderbolt PCIe chains, Windows enables power management for native PCIe hotplug ports if there is the following ACPI _DSD attached to the root port: Name (_DSD, Package () { ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"), Package () { Package () {"HotPlugSupportInD3", 1} } }) This is also documented in: https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3 Do the same in Linux by introducing new firmware PM callback (->bridge_d3()) and then implement it for ACPI based systems so that the above property is checked. There is one catch, though. The initial pci_dev->bridge_d3 is set before the root port has ACPI companion bound (the device is not added to the PCI bus either) so we need to look up the ACPI companion manually in that case in acpi_pci_bridge_d3(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a6bd101b |
|
20-Sep-2018 |
Keith Busch <kbusch@kernel.org> |
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>
|
#
bdb5ac85 |
|
20-Sep-2018 |
Keith Busch <kbusch@kernel.org> |
PCI/ERR: Handle fatal error recovery We don't need to be paranoid about the topology changing while handling an error. If the device has changed in a hotplug capable slot, we can rely on the presence detection handling to react to a changing topology. Restore the fatal error handling behavior that existed before merging DPC with AER with 7e9084b36740 ("PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices"). Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
|
#
c4eed62a |
|
20-Sep-2018 |
Keith Busch <kbusch@kernel.org> |
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>
|
#
4f802170 |
|
20-Sep-2018 |
Keith Busch <kbusch@kernel.org> |
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>
|
#
2d1ce5ec |
|
06-Aug-2018 |
Alexandru Gagniuc <mr.nuke.me@gmail.com> |
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>
|
#
73c47dde |
|
09-Aug-2018 |
Logan Gunthorpe <logang@deltatee.com> |
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>
|
#
bd2e9567 |
|
09-Aug-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
44bda4b7 |
|
03-Jul-2018 |
Hari Vyas <hari.vyas@broadcom.com> |
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>
|
#
ec752f5d |
|
19-Jul-2018 |
Oza Pawandeep <poza@codeaurora.org> |
PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL Clear the device status bits while handling both ERR_FATAL and ERR_NONFATAL cases. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> [bhelgaas: rename to pci_aer_clear_device_status(), declare internal to PCI core instead of exposing it everywhere] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7ab92e89 |
|
19-Jul-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
381634ca |
|
19-Jul-2018 |
Sinan Kaya <okaya@codeaurora.org> |
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>
|
#
81aa5206 |
|
21-Jun-2018 |
Rajat Jain <rajatja@google.com> |
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>
|
#
db89ccbe |
|
30-Jun-2018 |
Rajat Jain <rajatja@google.com> |
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>
|
#
60ed982a |
|
21-Jun-2018 |
Rajat Jain <rajatja@google.com> |
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>
|
#
1e451160 |
|
19-Jul-2018 |
Keith Busch <kbusch@kernel.org> |
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>
|
#
aa667c64 |
|
09-Jul-2018 |
James Puthukattukaran <james.puthukattukaran@oracle.com> |
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>
|
#
11eb0e0e |
|
04-Jun-2018 |
Sinan Kaya <okaya@codeaurora.org> |
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>
|
#
38972375 |
|
29-Jun-2018 |
Jakub Kicinski <kuba@kernel.org> |
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>
|
#
0b91439d |
|
17-May-2018 |
Oza Pawandeep <poza@codeaurora.org> |
PCI/AER: Pass service type to pcie_do_fatal_recovery() Pass the service type to pcie_do_fatal_recovery() instead of assuming AER. We will make DPC also use pcie_do_fatal_recovery(), and it needs to do things a little differently for AER and DPC. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2e28bc84 |
|
17-May-2018 |
Oza Pawandeep <poza@codeaurora.org> |
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>
|
#
9f5a70f1 |
|
17-May-2018 |
Oza Pawandeep <poza@codeaurora.org> |
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>
|
#
9e2aee80 |
|
10-May-2018 |
Rob Herring <robh@kernel.org> |
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>
|
#
cf0921be |
|
19-Mar-2018 |
KarimAllah Ahmed <karahmed@amazon.de> |
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>
|
#
b852f63a |
|
30-Mar-2018 |
Tal Gilboa <talgi@mellanox.com> |
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>
|
#
c70b65fb |
|
30-Mar-2018 |
Tal Gilboa <talgi@mellanox.com> |
PCI: Add pcie_get_width_cap() to find max supported link width Add pcie_get_width_cap() to find the max link width supported by a device. Change max_link_width_show() to use pcie_get_width_cap(). Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: return width directly instead of error and *width, don't export outside drivers/pci] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
|
#
6cf57be0 |
|
30-Mar-2018 |
Tal Gilboa <talgi@mellanox.com> |
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>
|
#
f9ea894c |
|
19-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/VPD: Move VPD structures to vpd.c The VPD-related structures are only used in vpd.c, so move them from drivers/pci/pci.h to vpd.c. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b1c615c4 |
|
19-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/VPD: Move VPD sysfs code to vpd.c Move the VPD-related sysfs code from pci-sysfs.c to vpd.c. This follows the pattern of pcie_aspm_create_sysfs_dev_files(). The goal is to encapsulate all the VPD code and structures in vpd.c. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
dcb0453d |
|
09-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
0aa0f5d1 |
|
02-Dec-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
7d8e7d19 |
|
15-Dec-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
b2441318 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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>
|
#
276b738d |
|
24-Oct-2017 |
Christian König <christian.koenig@amd.com> |
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>
|
#
3142d832 |
|
28-Aug-2017 |
Filippo Sironi <sironi@amazon.de> |
PCI: Cache the VF device ID in the SR-IOV structure Cache the VF device ID in the SR-IOV structure and use it instead of reading it over and over from the PF config space capability. Signed-off-by: Filippo Sironi <sironi@amazon.de> [bhelgaas: rename to "vf_device" to match pci_dev->device] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
69f2dc24 |
|
12-Sep-2017 |
Bhumika Goyal <bhumirks@gmail.com> |
PCI: Constify pci_dev_type structure Make this const as it not modified in the file referencing it. It is only stored in a const field 'type' of a device structure. Also, add const to the variable declaration in the header file. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
62ce94a7 |
|
11-Jul-2017 |
Sinan Kaya <okaya@codeaurora.org> |
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>
|
#
0ce3fcaf |
|
11-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
0847684c |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Simplify device wakeup settings code After previous changes it is not necessary to distinguish between device wakeup for run time and device wakeup from system sleep states any more, so rework the PCI device wakeup settings code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
17530e71 |
|
22-May-2017 |
Jakub Kicinski <kuba@kernel.org> |
PCI: Protect pci_driver->sriov_configure() usage with device_lock() Every method in struct device_driver or structures derived from it like struct pci_driver MUST provide exclusion vs the driver's ->remove() method, usually by using device_lock(). Protect use of pci_driver->sriov_configure() by holding the device lock while calling it. The PCI core sets the pci_dev->driver pointer in local_pci_probe() before calling ->probe() and only clears it after ->remove(). This means driver's ->sriov_configure() callback will happily race with probe() and remove(), most likely leading to BUGs, since drivers don't expect this. Remove the iov lock completely, since we remove the last user. [bhelgaas: changelog, thanks to Christoph for locking rule] Link: http://lkml.kernel.org/r/20170522225023.14010-1-jakub.kicinski@netronome.com Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
0e7df224 |
|
12-Apr-2017 |
Bodong Wang <bodong@mellanox.com> |
PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding Sometimes it is not desirable to bind SR-IOV VFs to drivers. This can save host side resource usage by VF instances that will be assigned to VMs. Add a new PCI sysfs interface "sriov_drivers_autoprobe" to control that from the PF. To modify it, echo 0/n/N (disable probe) or 1/y/Y (enable probe) to: /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe Note that this must be done before enabling VFs. The change will not take effect if VFs are already enabled. Simply, one can disable VFs by setting sriov_numvfs to 0, choose whether to probe or not, and then re-enable the VFs by restoring sriov_numvfs. [bhelgaas: changelog, ABI doc] Signed-off-by: Bodong Wang <bodong@mellanox.com> Signed-off-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
f7195824 |
|
12-Apr-2017 |
David Woodhouse <dwmw@amazon.co.uk> |
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>
|
#
8531e283 |
|
10-Mar-2017 |
Lukas Wunner <lukas@wunner.de> |
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
|
#
89ee9f76 |
|
29-Mar-2017 |
Keith Busch <kbusch@kernel.org> |
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>
|
#
5b0948df |
|
06-Jan-2017 |
Emil Tantilov <emil.s.tantilov@intel.com> |
PCI: Lock each enable/disable num_vfs operation in sysfs Enabling/disabling SRIOV via sysfs by echo-ing multiple values simultaneously: # echo 63 > /sys/class/net/ethX/device/sriov_numvfs& # echo 63 > /sys/class/net/ethX/device/sriov_numvfs # sleep 5 # echo 0 > /sys/class/net/ethX/device/sriov_numvfs& # echo 0 > /sys/class/net/ethX/device/sriov_numvfs results in the following bug: kernel BUG at drivers/pci/iov.c:495! invalid opcode: 0000 [#1] SMP CPU: 1 PID: 8050 Comm: bash Tainted: G W 4.9.0-rc7-net-next #2092 RIP: 0010:[<ffffffff813b1647>] [<ffffffff813b1647>] pci_iov_release+0x57/0x60 Call Trace: [<ffffffff81391726>] pci_release_dev+0x26/0x70 [<ffffffff8155be6e>] device_release+0x3e/0xb0 [<ffffffff81365ee7>] kobject_cleanup+0x67/0x180 [<ffffffff81365d9d>] kobject_put+0x2d/0x60 [<ffffffff8155bc27>] put_device+0x17/0x20 [<ffffffff8139c08a>] pci_dev_put+0x1a/0x20 [<ffffffff8139cb6b>] pci_get_dev_by_id+0x5b/0x90 [<ffffffff8139cca5>] pci_get_subsys+0x35/0x40 [<ffffffff8139ccc8>] pci_get_device+0x18/0x20 [<ffffffff8139ccfb>] pci_get_domain_bus_and_slot+0x2b/0x60 [<ffffffff813b09e7>] pci_iov_remove_virtfn+0x57/0x180 [<ffffffff813b0b95>] pci_disable_sriov+0x65/0x140 [<ffffffffa00a1af7>] ixgbe_disable_sriov+0xc7/0x1d0 [ixgbe] [<ffffffffa00a1e9d>] ixgbe_pci_sriov_configure+0x3d/0x170 [ixgbe] [<ffffffff8139d28c>] sriov_numvfs_store+0xdc/0x130 ... RIP [<ffffffff813b1647>] pci_iov_release+0x57/0x60 Use the existing mutex lock to protect each enable/disable operation. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com> CC: Alexander Duyck <alexander.h.duyck@intel.com>
|
#
cc10385b |
|
21-Sep-2016 |
Wang Sheng-Hui <shhuiw@foxmail.com> |
PCI: Move config space size macros to pci_regs.h Move PCI configuration space size macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE) from drivers/pci/pci.h to include/uapi/linux/pci_regs.h so they can be used by more drivers and eliminate duplicate definitions. [bhelgaas: Expand comment to include PCI-X details] Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
169de969 |
|
30-Nov-2016 |
Dongdong Liu <liudongdong3@huawei.com> |
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>
|
#
286c2378 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove pci_resource_bar() and pci_iov_resource_bar() pci_std_update_resource() only deals with standard BARs, so we don't have to worry about the complications of VF BARs in an SR-IOV capability. Compute the BAR address inline and remove pci_resource_bar(). That makes pci_iov_resource_bar() unused, so remove that as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
6ffa2489 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
c6a63307 |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
1ed276a7 |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
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>
|
#
cc7cc02b |
|
17-Sep-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Query platform firmware for device power state Usually the most accurate way to determine a PCI device's power state is to read its PM Control & Status Register. There are two cases however when this is not an option: If the device doesn't have the PM capability at all, or if it is in D3cold (in which case its config space is inaccessible). In both cases, we can alternatively query the platform firmware for its opinion on the device's power state. To facilitate this, augment struct pci_platform_pm_ops with a ->get_power callback and implement it for acpi_pci_platform_pm (the only pci_platform_pm_ops existing so far). It is used by a forthcoming commit to let pci_update_current_state() recognize D3cold. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9bb04a0c |
|
11-Jun-2016 |
Jonathan Yong <jonathan.yong@intel.com> |
PCI: Add Precision Time Measurement (PTM) support Add Precision Time Measurement (PTM) support (see PCIe r3.1, sec 6.22). Enable PTM on PTM Root devices and switch ports. This does not enable PTM on endpoints. There currently are no PTM-capable devices on the market, but it is expected to be supported by the Intel Apollo Lake platform. [bhelgaas: complete rework] Signed-off-by: Jonathan Yong <jonathan.yong@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9d26d3a8 |
|
02-Jun-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
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>
|
#
cb92148b |
|
15-Apr-2016 |
Hariprasad Shenai <hariprasad@chelsio.com> |
PCI: Add pci_set_vpd_size() to set VPD size After 104daa71b396 ("PCI: Determine actual VPD size on first access"), the PCI core computes the valid VPD size by parsing the VPD starting at offset 0x0. We don't attempt to read past that valid size because that causes some devices to crash. However, some devices do have data past that valid size. For example, Chelsio adapters contain two VPD structures, and the driver needs both of them. Add pci_set_vpd_size(). If a driver knows it is safe to read past the end of the VPD data structure at offset 0, it can use pci_set_vpd_size() to allow access to as much data as it needs. [bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and return int (not ssize_t)] Fixes: 104daa71b396 ("PCI: Determine actual VPD size on first access") Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
408641e9 |
|
22-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fold struct pci_vpd_pci22 into struct pci_vpd We only support one flavor of VPD, so there's no need to complicate things by having a "generic" struct pci_vpd and a more specific struct pci_vpd_pci22. Fold struct pci_vpd_pci22 directly into struct pci_vpd. [bhelgaas: remove NULL check before kfree of dev->vpd (per kfreeaddr.cocci)] Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.com>
|
#
f1cd93f9 |
|
22-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Rename VPD symbols to remove unnecessary "pci22" There's only one kind of VPD, so we don't need to qualify it as "the version described by PCI spec rev 2.2." Rename the following symbols to remove unnecessary "pci22": PCI_VPD_PCI22_SIZE -> PCI_VPD_MAX_SIZE pci_vpd_pci22_size() -> pci_vpd_size() pci_vpd_pci22_wait() -> pci_vpd_wait() pci_vpd_pci22_read() -> pci_vpd_read() pci_vpd_pci22_write() -> pci_vpd_write() pci_vpd_pci22_ops -> pci_vpd_ops pci_vpd_pci22_init() -> pci_vpd_init() Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.com>
|
#
da006847 |
|
22-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove struct pci_vpd_ops.release function pointer The struct pci_vpd_ops.release function pointer is always pci_vpd_pci22_release(), so there's no need for the flexibility of a function pointer. Inline the pci_vpd_pci22_release() body into pci_vpd_release() and remove pci_vpd_pci22_release() and the struct pci_vpd_ops.release function pointer. Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.com>
|
#
64379079 |
|
22-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Move pci_vpd_release() from header file to pci/access.c Move pci_vpd_release() so it's next to the other VPD functions. This puts it next to pci_vpd_pci22_init(), which allocates the space freed by pci_vpd_release(). Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.com>
|
#
299f2ffe |
|
06-Dec-2015 |
Julia Lawall <Julia.Lawall@lip6.fr> |
PCI / PM: constify pci_platform_pm_ops structure The pci_platform_pm_ops structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
128fc68c |
|
30-Nov-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/MSI: Remove empty pci_msi_init_pci_dev() 4a7cc8316705 ("genirq/MSI: Move msi_list from struct pci_dev to struct device") removed the contents of pci_msi_init_pci_dev(). All implementation of it are now empty, so remove it completely. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7c7a0e94 |
|
10-Nov-2015 |
Gabriele Paoloni <gabriele.paoloni@huawei.com> |
ARM/PCI: Move align_resource function pointer to pci_host_bridge structure Commit b3a72384fe29 ("ARM/PCI: Replace pci_sys_data->align_resource with global function pointer") introduced an ARM-specific align_resource() function pointer. This is not portable to other arches and doesn't work for platforms with two different PCIe host bridge controllers. Move the function pointer to the pci_host_bridge structure so each host bridge driver can specify its own align_resource() function. Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
|
#
938174e5 |
|
29-Oct-2015 |
Sean O. Stalley <sean.stalley@intel.com> |
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>
|
#
2cef548a |
|
29-Sep-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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>
|
#
fff905f3 |
|
29-Jun-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
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>
|
#
19bdb6e4 |
|
26-May-2015 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Move pci_ari_enabled() to global header pci_ari_enabled() is useful outside of drivers/pci, particularly for deriving INTx routing via ACPI _PRT, so move it to the global header. Also convert to bool return. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Don Dutile <ddutile@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6a25f5e3 |
|
07-May-2015 |
Michael S. Tsirkin <mst@redhat.com> |
PCI/MSI: Export pci_msi_set_enable(), pci_msix_clear_and_set_ctrl() Move pci_msi_set_enable() and pci_msix_clear_and_set_ctrl() to drivers/pci/pci.h so they're available even when MSI isn't configured into the kernel. No functional change. [bhelgaas: changelog, split into separate patch] Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Fam Zheng <famz@redhat.com>
|
#
3390e085 |
|
25-Mar-2015 |
Aaron Lu <aaron.lu@intel.com> |
PCI: Export pci_find_host_bridge() for use inside PCI core The find_pci_host_bridge() function can be useful to other PCI code so export it. Change its name to pci_find_host_bridge(). Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
4449f079 |
|
25-Mar-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
PCI: Calculate maximum number of buses required for VFs An SR-IOV device can change its First VF Offset and VF Stride based on the values of ARI Capable Hierarchy and NumVFs. The number of buses required for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see SR-IOV spec r1.1, sec 2.1.2). Previously pci_iov_bus_range() computed how many buses would be required by TotalVFs, but this was based on a single NumVFs value and may not have been the maximum for all NumVFs configurations. Iterate over all valid NumVFs and calculate the maximum number of bus numbers that could ever be required for VFs of this device. [bhelgaas: changelog, compute busnr of NumVFs, not TotalVFs, remove kerenl-doc comment marker] Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
0e6c9122 |
|
25-Mar-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
PCI: Keep individual VF BAR size in struct pci_sriov Currently we don't store the individual VF BAR size. We calculate it when needed by dividing the PF's IOV resource size (which contains space for *all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability again. Keep the individual VF BAR size in struct pci_sriov.barsz[], add pci_iov_resource_size() to retrieve it, and use that instead of doing the division or reading the SR-IOV capability BAR. [bhelgaas: rename to "barsz[]", simplify barsz[] index computation, remove SR-IOV capability BAR sizing] Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
bac2a909 |
|
20-Jan-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Avoid resuming PCI devices during system suspend Commit f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) modified the ACPI PM domain's system suspend callbacks to allow devices attached to it to be left in the runtime-suspended state during system suspend so as to optimize the suspend process. This was based on the general mechanism introduced by commit aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily). Extend that approach to PCI devices by modifying the PCI bus type's ->prepare callback to return 1 for devices that are runtime-suspended when it is being executed and that are in a suitable power state and need not be resumed going forward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0f7e7aee |
|
15-Jan-2015 |
Yinghai Lu <yinghai@kernel.org> |
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+
|
#
26ff46c6 |
|
11-Nov-2014 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: Remove fixed parameter in pci_iov_resource_bar() pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Chris Wright <chrisw@sous-sol.org> CC: Yu Zhao <yuzhao@google.com>
|
#
7a1562d4 |
|
11-Nov-2014 |
Yinghai Lu <yinghai@kernel.org> |
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>
|
#
326c1cda |
|
03-May-2014 |
Yijing Wang <wangyijing@huawei.com> |
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>
|
#
10874f5a |
|
14-Apr-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
46cb7b1b |
|
30-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove unused SR-IOV VF Migration support This reverts commit 74bb1bcc7dbb ("PCI: handle SR-IOV Virtual Function Migration"), removing this exported interface: pci_sriov_migration() Since pci_sriov_migration() is unused, it is impossible to schedule sriov_migration_task() or use any of the other migration infrastructure. This is based on Stephen Hemminger's patch (see link below), but goes a bit further. Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.net Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Stephen Hemminger <stephen@networkplumber.org>
|
#
0b950f0f |
|
10-Jan-2014 |
Stephen Hemminger <stephen@networkplumber.org> |
PCI: Make local functions static Using 'make namespacecheck' identify code which should be declared static. Checked for users in other driver/archs as well. Compile tested only. This stops exporting the following interfaces to modules: pci_target_state() pci_load_saved_state() [bhelgaas: retained pci_find_next_ext_capability() and pci_cfg_space_size()] Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
5136b2da |
|
07-Oct-2013 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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>
|
#
0f49ba55 |
|
07-Oct-2013 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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>
|
#
244afeca |
|
23-Aug-2013 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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>
|
#
343e51ae |
|
31-Jul-2013 |
Jacob Keller <jacob.e.keller@intel.com> |
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>
|
#
56039e65 |
|
24-Jul-2013 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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>
|
#
d66ecb72 |
|
22-Jun-2013 |
Jiang Liu <jiang.liu@huawei.com> |
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>
|
#
f39d5b72 |
|
12-Apr-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
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>
|
#
4f535093 |
|
21-Jan-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Put pci_dev in device tree as early as possible We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
31ab2476 |
|
14-Jan-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Rename pci_enable_ari() to pci_configure_ari() pci_enable_ari() now supports enabling or disabling ARI forwarding. So rename pci_enable_ari() to pci_configure_ari() for easy understanding. No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d2e5f0c1 |
|
22-Dec-2012 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PCI: Rework the setup and cleanup of device wakeup Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
|
#
8ccc9aa1 |
|
21-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
PCI: Move pci_uevent into pci-driver.c With the demise of CONFIG_HOTPLUG as an option, the pci_uevent function located in hotplug.c will now always be used and doesn't need special treatment in the Makefile. Move pci_uevent into pci-driver.c and remove hotplug.c Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b40b97ae |
|
21-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
PCI: Remove CONFIG_HOTPLUG ifdefs Remove conditional code based on CONFIG_HOTPLUG being false. It's always on now in preparation of it going away as an option. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6b136724 |
|
09-Nov-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use spec names for SR-IOV capability fields Use the same names (almost) as the spec for TotalVFs, InitialVFs, NumVFs. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
bff73156 |
|
05-Nov-2012 |
Donald Dutile <ddutile@redhat.com> |
PCI: Provide method to reduce the number of total VFs supported Some implementations of SRIOV provide a capability structure value of TotalVFs that is greater than what the software can support. Provide a method to reduce the capability structure reported value to the value the driver can support. This ensures sysfs reports the current capability of the system, hardware and software. Example for its use: igb & ixgbe -- report 8 & 64 as TotalVFs, but drivers only support 7 & 63 maximum. Signed-off-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
4e15c46b |
|
05-Nov-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Add pci_device_type to pdev's device struct Need type filled in device structure so it can be used for visible attribute control in sysfs for pci_dev. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b3c32c4f |
|
24-Oct-2012 |
Huang Ying <ying.huang@intel.com> |
PCI/PM: Fix proc config reg access for D3cold and bridge suspending In https://bugzilla.kernel.org/show_bug.cgi?id=48981 Peter reported that /proc/bus/pci/??/??.? does not work for 3.6. This is because the device configuration space registers are not accessible if the corresponding parent bridge is suspended or the device is put into D3cold state. This is the same as /sys/bus/pci/devices/0000:??:??.?/config access issue. So the function used to solve sysfs issue is used to solve this issue. This patch moves pci_config_pm_runtime_get()/_put() from pci/pci-sysfs.c to pci/pci.c and makes them extern so they can be used by both the sysfs and proc paths. [bhelgaas: changelog, references, reporters] Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48981 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=49031 Reported-by: Forrest Loomis <cybercyst@gmail.com> Reported-by: Peter <lekensteyn@gmail.com> Reported-by: Micael Dias <kam1kaz3@gmail.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+
|
#
db288c9c |
|
05-Jul-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / PM: restore the original behavior of pci_set_power_state() Commit cc2893b6 (PCI: Ensure we re-enable devices on resume) addressed the problem with USB not being powered after resume on recent Lenovo machines, but it did that in a suboptimal way. Namely, it should have changed the relevant code paths only, which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed to restore the device's power and standard configuration registers after system resume from suspend or hibernation. Instead, however, it modified pci_set_power_state() which is executed in several other situations too. That resulted in some undesirable effects, like attempting to change a device's power state in the same way multiple times in a row (up to as many as 4 times in a row in the snd_hda_intel driver). Fix the bug addressed by commit cc2893b6 in an alternative way, by forcibly powering up all devices in pci_pm_default_resume_early(), which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq() to restore the device's power and standard configuration registers, and modifying pci_pm_runtime_resume() to avoid the forcible power-up if not necessary. Then, revert the changes made by commit cc2893b6 to make the confusion introduced by it go away. Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
448bd857 |
|
22-Jun-2012 |
Huang Ying <ying.huang@intel.com> |
PCI/PM: add PCIe runtime D3cold support This patch adds runtime D3cold support and corresponding ACPI platform support. This patch only enables runtime D3cold support; it does not enable D3cold support during system suspend/hibernate. D3cold is the deepest power saving state for a PCIe device, where its main power is removed. While it is in D3cold, you can't access the device at all, not even its configuration space (which is still accessible in D3hot). Therefore the PCI PM registers can not be used to transition into/out of the D3cold state; that must be done by platform logic such as ACPI _PR3. To support wakeup from D3cold, a system may provide auxiliary power, which allows a device to request wakeup using a Beacon or the sideband WAKE# signal. WAKE# is usually connected to platform logic such as ACPI GPE. This is quite different from other power saving states, where devices request wakeup via a PME message on the PCIe link. Some devices, such as those in plug-in slots, have no direct platform logic. For example, there is usually no ACPI _PR3 for them. D3cold support for these devices can be done via the PCIe Downstream Port leading to the device. When the PCIe port is powered on/off, the device is powered on/off too. Wakeup events from the device will be notified to the corresponding PCIe port. For more information about PCIe D3cold and corresponding ACPI support, please refer to: - PCI Express Base Specification Revision 2.0 - Advanced Configuration and Power Interface Specification Revision 5.0 [bhelgaas: changelog] Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Originally-by: Zheng Yan <zheng.z.yan@intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
06aef8ce |
|
17-May-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: hotplug: remove pci_do_scan_bus() All callers of pci_do_scan_bus() are gone, so remove it. Note that pci_do_scan_bus() was exported, so out-of-tree modules could depend on it. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a8e4b9c1 |
|
18-May-2012 |
Yinghai Lu <yinghai@kernel.org> |
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>
|
#
c63587d7 |
|
10-Jun-2012 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: export pci_user functions for use by other drivers VFIO PCI support will make use of these for user-initiated PCI config accesses. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7b543663 |
|
02-Apr-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: add generic device into pci_host_bridge struct Use that device for pci_root_bus bridge pointer. Use pci_release_bus_bridge_dev() to release allocated pci_host_bridge in remove path. Use root bus bridge pointer to get host bridge pointer instead of searching host bridge list. That leaves the host bridge list unused, so remove it. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
610929e1 |
|
02-Apr-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: move host bridge-related code to host-bridge.c Move host bridge-related code from probe.c to a new host-bridge.c. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2069ecfb |
|
15-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
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>
|
#
b55438fd |
|
23-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
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>
|
#
f796841e |
|
11-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: fix memleak for pci dev removing during hotplug unreferenced object 0xffff880276d17700 (size 64): comm "swapper/0", pid 1, jiffies 4294897182 (age 3976.028s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 18 f9 de 76 02 88 ff ff ...........v.... 10 00 00 00 0e 00 00 00 0f 28 40 00 00 00 00 00 .........(@..... backtrace: [<ffffffff81c8aede>] kmemleak_alloc+0x26/0x43 [<ffffffff811385f0>] __kmalloc+0x121/0x183 [<ffffffff813cf821>] pci_add_cap_save_buffer+0x35/0x7c [<ffffffff813d12b7>] pci_allocate_cap_save_buffers+0x1d/0x65 [<ffffffff813cdb52>] pci_device_add+0x92/0xf1 [<ffffffff81c8afe6>] pci_scan_single_device+0x9f/0xa1 [<ffffffff813cdbd2>] pci_scan_slot.part.20+0x21/0x106 [<ffffffff813cdce2>] pci_scan_slot+0x2b/0x35 [<ffffffff81c8dae4>] __pci_scan_child_bus+0x51/0x107 [<ffffffff81c8d75b>] pci_scan_bridge+0x376/0x6ae [<ffffffff81c8db60>] __pci_scan_child_bus+0xcd/0x107 [<ffffffff81c8dbab>] pci_scan_child_bus+0x11/0x2a [<ffffffff81cca58c>] pci_acpi_scan_root+0x18b/0x21c [<ffffffff81c916be>] acpi_pci_root_add+0x1e1/0x42a [<ffffffff81406210>] acpi_device_probe+0x50/0x190 [<ffffffff814a0227>] really_probe+0x99/0x126 Need to free saved_buffer for capabilities. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
efdc87da |
|
27-Jan-2012 |
Yinghai Lu <yinghai@kernel.org> |
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>
|
#
1900ca13 |
|
17-Dec-2011 |
Hao, Xudong <xudong.hao@intel.com> |
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>
|
#
a2e27787 |
|
04-Nov-2011 |
Jan Kiszka <jan.kiszka@siemens.com> |
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>
|
#
0a2daa1c |
|
25-Jul-2011 |
Ram Pai <linuxram@us.ibm.com> |
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>
|
#
f483d392 |
|
07-Jul-2011 |
Ram Pai <linuxram@us.ibm.com> |
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>
|
#
166e9278 |
|
10-Jun-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
x86/ia64: intel-iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge() has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled in this patch, too. As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it. Compile-tested on x86_64. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
|
#
dc2c2c9d |
|
12-May-2011 |
Yinghai Lu <yinghai@kernel.org> |
PCI/sysfs: move bus cpuaffinity to class dev_attrs Requested by Greg KH to fix a race condition in the creating of PCI bus cpuaffinity files. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b9d320fc |
|
12-May-2011 |
Yinghai Lu <yinghai@kernel.org> |
PCI: add rescan to /sys/.../pci_bus/.../ After remove the device from /sys, we have to rescan all or find out the bridge and access /sys../device/rescan there. this patch add /sys/.../pci_bus/.../rescan. So user can rescan more easy. that is more clean and easy to understand. like after remove 0000:c4:00.0, you can rescan 0000:c4 directly. -v2: According to Jesse, use function instead of exposing attr, so could hide #ifdef in header file. also add code to remove rescan file in remove path. -v3: GregKH pointed out that we should use dev_attrs to avoid racing. So add pcibus_attrs and make it to be member of pcibus_attrs. -v4: Change name to pcibus_dev_attrs according to GregKH Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5cdede24 |
|
04-Apr-2011 |
Joerg Roedel <joerg.roedel@amd.com> |
PCI: Move ATS declarations in seperate header file This patch moves the relevant declarations from the local header file in drivers/pci to a more accessible locations so that it can be used by the AMD IOMMU driver too. The file is named pci-ats.h because support for the PCI PRI capability will also be added there in a later patch-set. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6058989b |
|
02-Mar-2011 |
Narendra_K@Dell.com <Narendra_K@Dell.com> |
PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs This patch exports ACPI _DSM (Device Specific Method) provided firmware instance number and string name of PCI devices as defined by 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming a PCI or PCI Express Device Under Operating Systems) to sysfs. New files created are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../acpi_index which contains the firmware device type instance for the given device. cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label Embedded Broadcom 5709C NIC 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index 2 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label Embedded Broadcom 5709C NIC 2 The ACPI _DSM provided firmware 'instance number' and 'string name' will be given priority if the firmware also provides 'SMBIOS type 41 device type instance and string'. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b6e335ae |
|
29-Dec-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
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>
|
#
415e12b2 |
|
06-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI/ACPI: Request _OSC control once for each root bridge (v3) Move the evaluation of acpi_pci_osc_control_set() (to request control of PCI Express native features) into acpi_pci_root_add() to avoid calling it many times for the same root complex with the same arguments. Additionally, check if all of the requisite _OSC support bits are set before calling acpi_pci_osc_control_set() for a given root complex. References: https://bugzilla.kernel.org/show_bug.cgi?id=20232 Reported-by: Ozan Caglayan <ozan@pardus.org.tr> Tested-by: Ozan Caglayan <ozan@pardus.org.tr> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
3b519e4e |
|
10-Nov-2010 |
Martin Wilck <martin.wilck@ts.fujitsu.com> |
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>
|
#
bf4d2908 |
|
04-Oct-2010 |
Matthew Garrett <mjg@redhat.com> |
PCI: Export some PCI PM functionality It's helpful to have some extra PCI power management functions available to platform code, so move the declarations to an exported header. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0e52247a |
|
07-Sep-2010 |
Cam Macdonell <cam@cs.ualberta.ca> |
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>
|
#
f1a7bfaf |
|
20-Aug-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: PCIe AER: Introduce pci_aer_available() Introduce a function allowing the caller to check whether to try to enable PCIe AER. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b879743f |
|
02-Aug-2010 |
Narendra K <Narendra_K@dell.com> |
PCI: Fix warnings when CONFIG_DMI unset This patch fixes the below warnings introduced by the commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided firmware instance and label to sysfs"). drivers/pci/pci.h: In function ‘pci_create_firmware_label_files’: drivers/pci/pci.h:16: warning: ‘return’ with a value, in function returning void drivers/pci/pci.h: In function ‘pci_remove_firmware_label_files’: drivers/pci/pci.h:18: warning: ‘return’ with a value, in function returning void The warnings are seen because of the below code, doing a retun 0 from the functions 'pci_create_firmware_label_files' and 'pci_remove_firmware_label_files' defined as void. +#ifndef CONFIG_DMI +static inline void pci_create_firmware_label_files(struct pci_dev *pdev) +{ return 0; } +static inline void pci_remove_firmware_label_files(struct pci_dev *pdev) +{ return 0; } Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
911e1c9b |
|
26-Jul-2010 |
Narendra K <Narendra_K@dell.com> |
PCI: export SMBIOS provided firmware instance and label to sysfs This patch exports SMBIOS provided firmware instance and label of onboard PCI devices to sysfs. New files are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../index which contains the firmware device type instance for the given device. Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c125e96f |
|
05-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Make it possible to avoid races between wakeup and system sleep One of the arguments during the suspend blockers discussion was that the mainline kernel didn't contain any mechanisms making it possible to avoid races between wakeup and system suspend. Generally, there are two problems in that area. First, if a wakeup event occurs exactly when /sys/power/state is being written to, it may be delivered to user space right before the freezer kicks in, so the user space consumer of the event may not be able to process it before the system is suspended. Second, if a wakeup event occurs after user space has been frozen, it is not generally guaranteed that the ongoing transition of the system into a sleep state will be aborted. To address these issues introduce a new global sysfs attribute, /sys/power/wakeup_count, associated with a running counter of wakeup events and three helper functions, pm_stay_awake(), pm_relax(), and pm_wakeup_event(), that may be used by kernel subsystems to control the behavior of this attribute and to request the PM core to abort system transitions into a sleep state already in progress. The /sys/power/wakeup_count file may be read from or written to by user space. Reads will always succeed (unless interrupted by a signal) and return the current value of the wakeup events counter. Writes, however, will only succeed if the written number is equal to the current value of the wakeup events counter. If a write is successful, it will cause the kernel to save the current value of the wakeup events counter and to abort the subsequent system transition into a sleep state if any wakeup events are reported after the write has returned. [The assumption is that before writing to /sys/power/state user space will first read from /sys/power/wakeup_count. Next, user space consumers of wakeup events will have a chance to acknowledge or veto the upcoming system transition to a sleep state. Finally, if the transition is allowed to proceed, /sys/power/wakeup_count will be written to and if that succeeds, /sys/power/state will be written to as well. Still, if any wakeup events are reported to the PM core by kernel subsystems after that point, the transition will be aborted.] Additionally, put a wakeup events counter into struct dev_pm_info and make these per-device wakeup event counters available via sysfs, so that it's possible to check the activity of various wakeup event sources within the kernel. To illustrate how subsystems can use pm_wakeup_event(), make the low-level PCI runtime PM wakeup-handling code use it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: markgross <markgross@thegnar.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
|
#
8356dda2 |
|
30-Apr-2010 |
Bill Pemberton <wfp5p@virginia.edu> |
PCI: make bitfield unsigned Fix sparse warning: drivers/pci/pci.h:247:25: error: dubious one-bit signed bitfield Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> CC: linux-pci@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6cbf8214 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Run-time callbacks for PCI bus type Introduce run-time PM callbacks for the PCI bus type. Make the new callbacks work in analogy with the existing system sleep PM callbacks, so that the drivers already converted to struct dev_pm_ops can use their suspend and resume routines for run-time PM without modifications. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b67ea761 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / ACPI / PM: Platform support for PCI PME wake-up Although the majority of PCI devices can generate PMEs that in principle may be used to wake up devices suspended at run time, platform support is generally necessary to convert PMEs into wake-up events that can be delivered to the kernel. If ACPI is used for this purpose, PME signals generated by a PCI device will trigger the ACPI GPE associated with the device to generate an ACPI wake-up event that we can set up a handler for, provided that everything is configured correctly. Unfortunately, the subset of PCI devices that have GPEs associated with them is quite limited. The devices without dedicated GPEs have to rely on the GPEs associated with other devices (in the majority of cases their upstream bridges and, possibly, the root bridge) to generate ACPI wake-up events in response to PME signals from them. Add ACPI platform support for PCI PME wake-up: o Add a framework making is possible to use ACPI system notify handlers for run-time PM. o Add new PCI platform callback ->run_wake() to struct pci_platform_pm_ops allowing us to enable/disable the platform to generate wake-up events for given device. Implemet this callback for the ACPI platform. o Define ACPI wake-up handlers for PCI devices and PCI root buses and make the PCI-ACPI binding code register wake-up notifiers for all PCI devices present in the ACPI tables. o Add function pci_dev_run_wake() which can be used by PCI drivers to check if given device is capable of generating wake-up events at run time. Developed in cooperation with Matthew Garrett <mjg@redhat.com>. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
58ff4633 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Add function for checking PME status of devices Add function pci_check_pme_status() that will check the PME status bit of given device and clear it along with the PME enable bit. It will be necessary for PCI run-time power management. Based on a patch from Shaohua Li <shaohua.li@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
93177a74 |
|
02-Jan-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
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>
|
#
5b889bf2 |
|
31-Dec-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Fix build if quirks are not enabled After commit b9c3b266411d27f1a6466c19d146d08db576bfea ("PCI: support device-specific reset methods") the kernel build is broken if CONFIG_PCI_QUIRKS is unset. Fix this by moving pci_dev_specific_reset() to drivers/pci/quirks.c and providing an empty replacement for !CONFIG_PCI_QUIRKS builds. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b9c3b266 |
|
06-Dec-2009 |
Dexuan Cui <dexuan.cui@intel.com> |
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>
|
#
ae21ee65 |
|
07-Oct-2009 |
Allen Kay <allen.m.kay@intel.com> |
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>
|
#
0ba379ec |
|
06-Sep-2009 |
Eric W. Biederman <ebiederm@xmission.com> |
PCI: Simplify hotplug mch quirk. There is a very old quirk for the intel E7502 E7320 and E7525 memory controller hubs that disables usage of msi interrupts on pcie hotplug bridges of those devices, and disables changing the affinity of irqs. Today all we have to do to disable msi on a specific device is to set dev->no_msi, which is much more straightforward than the previous logic. The re-running of this fixup after pci hotplug happens below these devices is totally bogus. All of the state we change is pure software state and we don't change the hardware at all. Which means hotplug on the lower devices doesn't have a chance to change this state. So we can safely remove the special case from the pciehp driver and the pcie portdriver. I suspect the special case was someone's expermental debug code that slipped in. Certainly it isn't mentioned in commit 6fb8880a61510295aece04a542767161f624dffe aka BKrev: 41966101LJ_ogfOU0m2aE6teZfQnuQ where the code first appears. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
711d5779 |
|
27-Jul-2009 |
Michael S. Tsirkin <mst@redhat.com> |
PCI: expose function reset capability in sysfs Some devices allow an individual function to be reset without affecting other functions in the same device: that's what pci_reset_function does. For devices that have this support, expose reset attribite in sysfs. This is useful e.g. for virtualization, where a qemu userspace process wants to reset the device when the guest is reset, to emulate machine reboot as closely as possible. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6faf17f6 |
|
28-Aug-2009 |
Chris Wright <chrisw@sous-sol.org> |
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>
|
#
e277d2fc |
|
17-May-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: handle Virtual Function ATS enabling The SR-IOV spec requires that the Smallest Translation Unit and the Invalidate Queue Depth fields in the Virtual Function ATS capability are hardwired to 0. If a function is a Virtual Function, then and set its Physical Function's STU before enabling the ATS. 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>
|
#
302b4215 |
|
17-May-2009 |
Yu Zhao <yu.zhao@intel.com> |
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>
|
#
0128a89c |
|
16-Mar-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Move pci_restore_standard_config to pci-driver.c Move pci_restore_standard_config() from pci.c to pci-driver.c and make it static. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
705b1aaa |
|
20-Mar-2009 |
Alex Chiang <achiang@hp.com> |
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>
|
#
74bb1bcc |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: handle SR-IOV Virtual Function Migration Add or remove a Virtual Function after receiving a Migrate In or Out Request. 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>
|
#
dd7cc44d |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: add SR-IOV API for Physical Function driver Add or remove the Virtual Function when the SR-IOV is enabled or disabled by the device driver. This can happen anytime rather than only at the device probe stage. 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>
|
#
480b93b7 |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: centralize device setup code Move the device setup stuff into pci_setup_device() which will be used to setup the Virtual Function later. 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>
|
#
a28724b0 |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
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>
|
#
8c5cdb6a |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: restore saved SR-IOV state Restore the volatile registers in the SR-IOV capability after the D3->D0 transition. 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>
|
#
d1b054da |
|
19-Mar-2009 |
Yu Zhao <yu.zhao@intel.com> |
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>
|
#
32a9a682 |
|
16-Mar-2009 |
Yuji Shimada <shimada-yxb@necst.nec.co.jp> |
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>
|
#
b33bfdef |
|
09-Jan-2009 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: fix struct pci_platform_pm_ops kernel-doc Fix struct pci_platform_pm_ops kernel-doc notation. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
aa8c6c93 |
|
16-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
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>
|
#
73410429 |
|
07-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Avoid touching devices behind bridges in unknown state It generally is better to avoid accessing devices behind bridges that may not be in the D0 power state, because in that case the bridges' secondary buses may not be accessible. For this reason, during the early phase of resume (ie. with interrupts disabled), before restoring the standard config registers of a device, check the power state of the bridge the device is behind and postpone the restoration of the device's config space, as well as any other operations that would involve accessing the device, if that state is not D0. In such cases the restoration of the device's config space will be retried during the "normal" phase of resume (ie. with interrupts enabled), so that the bridge can be put into D0 before that happens. Also, save standard configuration registers of PCI devices during the "normal" phase of suspend (ie. with interrupts enabled), so that the bridges the devices are behind can be put into low power states (we don't put bridges into low power states at the moment, but we may want to do it in the future and it seems reasonable to design for that). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
fa58d305 |
|
07-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Add suspend counterpart of pci_reenable_device PCI devices without drivers are not disabled during suspend and hibernation, but they are enabled during resume, with the help of pci_reenable_device(), so there is an unbalanced execution of pcibios_enable_device() in the resume code path. To correct this introduce function pci_disable_enabled_device() that will disable the argument device, if it is enabled when the function is being run, without updating the device's pci_dev structure and use it in the suspend code path to balance the pci_reenable_device() executed during resume. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
287d19ce |
|
18-Dec-2008 |
Stephen Hemminger <shemminger@vyatta.com> |
PCI: revise VPD access interface Change PCI VPD API which was only used by sysfs to something usable in drivers. * move iteration over multiple words to the low level * use conventional types for arguments * add exportable wrapper Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
eb9c39d0 |
|
17-Dec-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: set device wakeup capable flag if platform support is present When PCI devices are initialized, we check whether they support PCI PM caps and set the device can_wakeup flag if so. However, some devices may have platform provided wakeup events rather than PCI PME signals, so we need to set can_wakeup in that case too. Doing so should allow wakeups from many more devices, especially on cost constrained systems. Reported-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Joseph Chan <JosephChan@via.com.tw> Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
876e501a |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: factor pci_bus_add_child() from pci_bus_add_devices() This patch splits a new function, pci_bus_add_child(), from pci_bus_add_devices(). The new function can be used to register PCI buses to the device core. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
613e7ed6 |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: add a new function to map BAR offsets Add a function to map a given resource number to a corresponding register so drivers can get the offset and type of device specific BARs. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0b400c7e |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
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>
|
#
6a49d812 |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: enhance pci_ari_enabled() Change parameter of pci_ari_enabled() from 'pci_dev' to 'pci_bus'. ARI forwarding on the bridge mostly concerns the subordinate devices rather than the bridge itself. So this change will make the function easier to use. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
63f4898a |
|
07-Dec-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: handle PCI state saving with interrupts disabled Since interrupts will soon be disabled at PCI resume time, we need to pre-allocate memory to save/restore PCI config space (or use GFP_ATOMIC, but this is safer). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
07ae95f9 |
|
10-Nov-2008 |
Andrew Patterson <andrew.patterson@hp.com> |
ACPI/PCI: PCI MSI _OSC support capabilities called when root bridge added The _OSC capability OSC_MSI_SUPPORT is set when the root bridge is added with pci_acpi_osc_support(), so we no longer need to do it in the PCI MSI driver. Also adds the function pci_msi_enabled, which returns true if pci=nomsi is not on the kernel command-line. Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
9eff02e2 |
|
24-Oct-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: check mmap range of /proc/bus/pci files too /proc/bus/pci allows you to mmap resource ranges too, so we should probably be checking to make sure the mapping is somewhat valid. Uses the same code as the recent sysfs mmap range checking patch from Linus. Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d389fec6 |
|
16-Oct-2008 |
Taku Izumi <izumi.taku@jp.fujitsu.com> |
ACPI/PCI: Set support bit for MSI in support field of _OSC Currently linux doesn't have any code to set the "MSI supported" bit in Support Fireld of _OSC. This patch adds the code for that. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f19aeb1f |
|
03-Oct-2008 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
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>
|
#
58c3a727 |
|
14-Oct-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: support PCIe ARI capability This patch adds support for PCI Express Alternative Routing-ID Interpretation (ARI) capability. The ARI capability extends the Function Number field of the PCI Express Endpoint by reusing the Device Number which is otherwise hardwired to 0. With ARI, an Endpoint can have up to 256 functions. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
557848c3 |
|
13-Oct-2008 |
Zhao, Yu <yu.zhao@intel.com> |
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>
|
#
93ff68a5 |
|
06-Sep-2008 |
Mike Travis <travis@sgi.com> |
PCI: make CPU list affinity visible Stephen Hemminger wrote: > Looks like Mike created cpulistaffinty in sysfs but never completed > the job. This patch hooks things up correctly, taking care to remove the new file when the bus is destroyed. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
a80a6da1 |
|
04-Jun-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI ACPI: Drop the second argument of platform_pci_choose_state Since the second argument of acpi_pci_choose_state() and platform_pci_choose_state() is never used, remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
eb9d0fe4 |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI ACPI: Rework PCI handling of wake-up * Introduce function acpi_pm_device_sleep_wake() for enabling and disabling the system wake-up capability of devices that are power manageable by ACPI. * Introduce function acpi_bus_can_wakeup() allowing other (dependent) subsystems to check if ACPI is able to enable the system wake-up capability of given device. * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake(). * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and for the ACPI 'driver' make it use acpi_bus_can_wakeup(). * Move the PME# handlig code out of pci_enable_wake() and split it into two functions, pci_pme_capable() and pci_pme_active(), allowing the caller to check if given device is capable of generating PME# from given power state and to enable/disable the device's PME# functionality, respectively. * Modify pci_enable_wake() to use the new ACPI callbacks and the new PME#-related functions. * Drop the generic .platform_enable_wakeup() callback that is not used any more. * Introduce device_set_wakeup_capable() that will set the power.can_wakeup flag of given device. * Rework PCI device PM initialization so that, if given device is capable of generating wake-up events, either natively through the PME# mechanism, or with the help of the platform, its power.can_wakeup flag is set and its power.should_wakeup flag is unset as appropriate. * Make ACPI set the power.can_wakeup flag for devices found to be wake-up capable by it. * Make the ACPI wake-up code enable/disable GPEs for devices that have the wakeup.flags.prepared flag set (which means that their wake-up power has been enabled). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
961d9120 |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Introduce platform_pci_power_manageable function Introduce function pointer platform_pci_power_manageable to be used by the platform-related code to point to a function allowing us to check if given device is power manageable by the platform. Introduce acpi_pci_power_manageable() playing that role for ACPI. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
99cb233d |
|
02-Jul-2008 |
Benjamin Li <benli@broadcom.com> |
PCI: Limit VPD read/write lengths for Broadcom 5706, 5708, 5709 rev. For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the VPD end tag will hang the device. This problem was initially observed when a vpd entry was created in sysfs ('/sys/bus/pci/devices/<id>/vpd'). A read to this sysfs entry will dump 32k of data. Reading a full 32k will cause an access beyond the VPD end tag causing the device to hang. Once the device is hung, the bnx2 driver will not be able to reset the device. We believe that it is legal to read beyond the end tag and therefore the solution is to limit the read/write length. A majority of this patch is from Matthew Wilcox who gave code for reworking the PCI vpd size information. A PCI quirk added for the Broadcom NIC's to limit the read/write's. Signed-off-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8d2bdf49 |
|
04-Jun-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI ACPI: Drop the second argument of platform_pci_choose_state Since the second argument of acpi_pci_choose_state() and platform_pci_choose_state() is never used, remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f46753c5 |
|
10-Jun-2008 |
Alex Chiang <achiang@hp.com> |
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>
|
#
94e61088 |
|
05-Mar-2008 |
Ben Hutchings <bhutchings@solarflare.com> |
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>
|
#
fd7d1ced |
|
22-May-2007 |
Greg Kroah-Hartman <gregkh@suse.de> |
PCI: make pci_bus a struct device This moves the pci_bus class device to be a real struct device and at the same time, place it in the device tree in the correct location. Note, the old "bridge" symlink is now gone, but this was a non-standard link and no userspace program used it. If you need to determine the device that the bus is on, follow the standard device symlink, or walk up the device tree. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
367b09fe |
|
30-Jan-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
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>
|
#
94688cf2 |
|
07-Nov-2007 |
Linas Vepstas <linas@austin.ibm.com> |
PCI: export pci_restore_msi_state() PCI error recovery usually involves the PCI adapter being reset. If the device is using MSI, the reset will cause the MSI state to be lost; the device driver needs to restore the MSI state. The pci_restore_msi_state() routine is currently protected by CONFIG_PM; remove this, and also export the symbol, so that it can be used in a modle. Signed-off-by: Linas Vepstas <linas@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
994a65e2 |
|
21-Oct-2007 |
Keshavamurthy, Anil S <anil.s.keshavamurthy@intel.com> |
Intel IOMMU: PCI generic helper function When devices are under a p2p bridge, upstream transactions get replaced by the device id of the bridge as it owns the PCIE transaction. Hence its necessary to setup translations on behalf of the bridge as well. Due to this limitation all devices under a p2p share the same domain in a DMAR. We just cache the type of device, if its a native PCIe device or not for later use. [akpm@linux-foundation.org: BUG_ON -> WARN_ON+recover] Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Ashok Raj <ashok.raj@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Christoph Lameter <clameter@sgi.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7f785763 |
|
05-Oct-2007 |
Randy Dunlap <randy.dunlap@oracle.com> |
pci: implement "pci=noaer" For cases in which CONFIG_PCIEAER=y (such as distro kernels), allow users to disable PCIE Advanced Error Reporting by using "pci=noaer" on the kernel command line. This can be used to work around hardware or (kernel) software problems. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
7eff2e7a |
|
14-Aug-2007 |
Kay Sievers <kay.sievers@vrfy.org> |
Driver core: change add_uevent_var to use a struct This changes the uevent buffer functions to use a struct instead of a long list of parameters. It does no longer require the caller to do the proper buffer termination and size accounting, which is currently wrong in some places. It fixes a known bug where parts of the uevent environment are overwritten because of wrong index calculations. Many thanks to Mathieu Desnoyers for finding bugs and improving the error handling. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ce5ccdef |
|
16-Jul-2007 |
Kumar Gala <galak@kernel.crashing.org> |
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>
|
#
f0a664bb |
|
10-Jul-2007 |
Tejun Heo <htejun@gmail.com> |
PCI: export __pci_reenable_device() Some odd ACPI implementations choke if certain controller is disabled when ACPI suspend is invoked but we still need to make sure the PCI device is enabled during resume. Simply using pci_enable_device() unbalances device enable count. Export __pci_reenable_device(). Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
#
ab826ca4 |
|
19-Jul-2007 |
Shaohua Li <shaohua.li@intel.com> |
ACPI: Use ACPI methods to select PCI device suspend state applied after Rafel's 'PM: Update global suspend and hibernation operations framework' patch set Signed-off-by: Shaohua Li<shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4aa9bc95 |
|
05-Apr-2007 |
Michael Ellerman <michael@ellerman.id.au> |
MSI: Use a list instead of the custom link structure The msi descriptors are linked together with what looks a lot like a linked list, but isn't a struct list_head list. Make it one. The only complication is that previously we walked a list of irqs, and got the descriptor for each with get_irq_msi(). Now we have a list of descriptors and need to get the irq out of it, so it needs to be in the actual struct msi_desc. We use 0 to indicate no irq is setup. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
392ee1e6 |
|
08-Mar-2007 |
Eric W. Biederman <ebiederm@xmission.com> |
[PATCH] msi: Safer state caching. There are two ways pci_save_state and pci_restore_state are used. As helper functions during suspend/resume, and as helper functions around a hardware reset event. When used as helper functions around a hardware reset event there is no reason to believe the calls will be paired, nor is there a good reason to believe that if we restore the msi state from before the reset that it will match the current msi state. Since arch code may change the msi message without going through the driver, drivers currently do not have enough information to even know when to call pci_save_state to ensure they will have msi state in sync with the other kernel irq reception data structures. It turns out the solution is straight forward, cache the state in the existing msi data structures (not the magic pci saved things) and have the msi code update the cached state each time we write to the hardware. This means we never need to read the hardware to figure out what the hardware state should be. By modifying the caching in this manner we get to remove our save_state routines and only need to provide restore_state routines. The only fields that were at all tricky to regenerate were the msi and msi-x control registers and the way we regenerate them currently is a bit dependent upon assumptions on how we use the allow msi registers to be configured and used making the code a little bit brittle. If we ever change what cases we allow or how we configure the msi bits we can address the fragility then. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f5f2b131 |
|
05-Mar-2007 |
Eric W. Biederman <ebiederm@xmission.com> |
[PATCH] msi: sanely support hardware level msi disabling In some cases when we are not using msi we need a way to ensure that the hardware does not have an msi capability enabled. Currently the code has been calling disable_msi_mode to try and achieve that. However disable_msi_mode has several other side effects and is only available when msi support is compiled in so it isn't really appropriate. Instead this patch implements pci_msi_off which disables all msi and msix capabilities unconditionally with no additional side effects. pci_disable_device was redundantly clearing the bus master enable flag and clearing the msi enable bit. A device that is not allowed to perform bus mastering operations cannot generate intx or msi interrupt messages as those are essentially a special case of dma, and require bus mastering. So the call in pci_disable_device to disable msi capabilities was redundant. quirk_pcie_pxh also called disable_msi_mode and is updated to use pci_msi_off. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Michael Ellerman <michael@ellerman.id.au> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8fed4b65 |
|
25-Jan-2007 |
Michael Ellerman <michael@ellerman.id.au> |
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>
|
#
88187dfa |
|
25-Jan-2007 |
Michael Ellerman <michael@ellerman.id.au> |
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>
|
#
38cc1302 |
|
17-Dec-2006 |
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> |
PCI : add extremely specialized __pci_reenable_device for default resume Original patch was posted as "PCI : Move pci_fixup_device and is_enabled". This 3 of 3 patches does: - add __pci_reenable_device (recover former change of 1st patch) Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
924b08f3 |
|
17-Dec-2006 |
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> |
PCI : remove too specialized __pci_enable_device for default resume Original patch was posted as "PCI : Move pci_fixup_device and is_enabled". This 1 of 3 patches does: - reverts small part of Inaky's patch (remove __pci_enable_device) This change will be recovered by 3rd patch. - temporarily remove pci_fixup_device. This change will be recovered by 2nd patch. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
bae94d02 |
|
22-Nov-2006 |
Inaky Perez-Gonzalez <inaky@linux.intel.com> |
PCI: switch pci_{enable,disable}_device() to be nestable Changes the pci_{enable,disable}_device() functions to work in a nested basis, so that eg, three calls to enable_device() require three calls to disable_device(). The reason for this is to simplify PCI drivers for multi-interface/capability devices. These are devices that cram more than one interface in a single function. A relevant example of that is the Wireless [USB] Host Controller Interface (similar to EHCI) [see http://www.intel.com/technology/comms/wusb/whci.htm]. In these kind of devices, multiple interfaces are accessed through a single bar and IRQ line. For that, the drivers map only the smallest area of the bar to access their register banks and use shared IRQ handlers. However, because the order at which those drivers load cannot be known ahead of time, the sequence in which the calls to pci_enable_device() and pci_disable_device() cannot be predicted. Thus: 1. driverA starts pci_enable_device() 2. driverB starts pci_enable_device() 3. driverA shutdown pci_disable_device() 4. driverB shutdown pci_disable_device() between steps 3 and 4, driver B would loose access to it's device, even if it didn't intend to. By using this modification, the device won't be disabled until all the callers to enable() have called disable(). This is implemented by replacing 'struct pci_dev->is_enabled' from a bitfield to an atomic use count. Each caller to enable increments it, each caller to disable decrements it. When the count increments from 0 to 1, __pci_enable_device() is called to actually enable the device. When it drops to zero, pci_disable_device() actually does the disabling. We keep the backend __pci_enable_device() for pci_default_resume() to use and also change the sysfs method implementation, so that userspace enabling/disabling the device doesn't disable it one time too much. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3f79e107 |
|
30-Aug-2006 |
Brice Goglin <brice@myri.com> |
MSI: Cleanup existing MSI quirks Move MSI quirks in CONFIG_PCI_MSI, document why the serverworks quirk does not simply set PCI_BUS_FLAGS_NO_MSI, and create a generic quirk for other chipsets where setting PCI_BUS_FLAGS_NO_MSI is fine. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ffadcc2f |
|
12-Jul-2006 |
Kristen Carlson Accardi <kristen.c.accardi@intel.com> |
[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>
|
#
e31dd6e4 |
|
12-Jun-2006 |
Greg Kroah-Hartman <gregkh@suse.de> |
[PATCH] 64bit resource: change pci core and arch code to use resource_size_t Based on a patch series originally from Vivek Goyal <vgoyal@in.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
d71374da |
|
01-Jun-2006 |
Zhang Yanmin <yanmin.zhang@intel.com> |
[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>
|
#
41017f0c |
|
08-Feb-2006 |
Shaohua Li <shaohua.li@intel.com> |
[PATCH] PCI: MSI(X) save/restore for suspend/resume Add MSI(X) configure sapce save/restore in generic PCI helper. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
309e57df |
|
05-Mar-2006 |
Matthew Wilcox <willy@infradead.org> |
[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>
|
#
54c762fe |
|
21-Dec-2005 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] PCI: drivers/pci: some cleanups This patch contains the following cleanups: - hotplug/pciehp_core.c: make the needlessly global hpdriver_context static - #if 0 the following unused functions: - pci.c: pci_bus_max_busnr() - pci.c: pci_max_busnr() - proc.c: pci_proc_attach_bus() - remove.c: pci_remove_device_safe Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
312c004d |
|
16-Nov-2005 |
Kay Sievers <kay.sievers@suse.de> |
[PATCH] driver core: replace "hotplug" by "uevent" Leave the overloaded "hotplug" word to susbsystems which are handling real devices. The driver core does not "plug" anything, it just exports the state to userspace and generates events. Signed-off-by: Kay Sievers <kay.sievers@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
e04b0ea2 |
|
27-Sep-2005 |
Brian King <brking@us.ibm.com> |
[PATCH] PCI: Block config access during BIST Some PCI adapters (eg. ipr scsi adapters) have an exposure today in that they issue BIST to the adapter to reset the card. If, during the time it takes to complete BIST, userspace attempts to access PCI config space, the host bus bridge will master abort the access since the ipr adapter does not respond on the PCI bus for a brief period of time when running BIST. On PPC64 hardware, this master abort results in the host PCI bridge isolating that PCI device from the rest of the system, making the device unusable until Linux is rebooted. This patch is an attempt to close that exposure by introducing some blocking code in the PCI code. When blocked, writes will be humored and reads will return the cached value. Ben Herrenschmidt has also mentioned that he plans to use this in PPC power management. Signed-off-by: Brian King <brking@us.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/pci/access.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++ drivers/pci/pci-sysfs.c | 20 +++++----- drivers/pci/pci.h | 7 +++ drivers/pci/proc.c | 28 +++++++-------- drivers/pci/syscall.c | 14 +++---- include/linux/pci.h | 7 +++ 6 files changed, 134 insertions(+), 31 deletions(-)
|
#
cdb9b9f7 |
|
05-Sep-2005 |
Paul Mackerras <paulus@samba.org> |
[PATCH] PCI: Small rearrangement of PCI probing code This patch makes some small rearrangements of the PCI probing code in order to make it possible for arch code to set up the PCI tree without needing to duplicate code from the PCI layer unnecessarily. PPC64 will use this to set up the PCI tree from the Open Firmware device tree, which we need to do on logically-partitioned pSeries systems. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4b47b0ee |
|
16-Aug-2005 |
Andrew Morton <akpm@osdl.org> |
[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>
|
#
4602b88d |
|
16-Aug-2005 |
Kristen Accardi <kristen.c.accardi@intel.com> |
[PATCH] PCI: 6700/6702PXH quirk On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug driver and SHPC driver in MSI mode are used together. This patch will prevent MSI from being enabled for the SHPC as part of an early pci quirk, as well as on any pci device which sets the no_msi bit. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
b913100d |
|
18-Mar-2005 |
David Shaohua Li <shaohua.li@intel.com> |
[ACPI] pci_set_power_state() now calls platform_pci_set_power_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>
|
#
0f64474b |
|
18-Mar-2005 |
David Shaohua Li <shaohua.li@intel.com> |
[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>
|
#
c22610da |
|
09-May-2005 |
Scott Murray <scottm@somanetworks.com> |
[PATCH] PCI Hotplug: remove pci_visit_dev If my CPCI hotplug update patch is applied, then there are no longer any in tree users of the pci_visit_dev API, and it and its related code can be removed. Signed-off-by: Scott Murray <scottm@somanetworks.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
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!
|