#
64dbb2d7 |
|
05-Mar-2024 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/ASPM: Disable L1 before configuring L1 Substates Per PCIe r6.1, sec 5.5.4, L1 must be disabled while setting ASPM L1 PM Substates enable bits. Previously this was enforced by clearing PCI_EXP_LNKCTL_ASPMC before calling pci_restore_aspm_l1ss_state(). Move the L1 (and L0s, although that doesn't seem required) disable into pci_restore_aspm_l1ss_state() itself so it's closer to the code that depends on it. Link: https://lore.kernel.org/r/20240223213733.GA115410@bhelgaas Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c198fafa |
|
23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
PCI/ASPM: Call pci_save_ltr_state() from pci_save_pcie_state() ASPM state is saved and restored from pci_save/restore_pcie_state(). Since the LTR Capability is linked with ASPM, move the LTR save and restore calls there as well. No functional change intended. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-6-david.e.box@linux.intel.com Link: https://lore.kernel.org/r/20240223205851.114931-6-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
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>
|
#
c0ef3df8 |
|
30-Jan-2024 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
PM: runtime: Simplify pm_runtime_get_if_active() usage There are two ways to opportunistically increment a device's runtime PM usage count, calling either pm_runtime_get_if_active() or pm_runtime_get_if_in_use(). The former has an argument to tell whether to ignore the usage count or not, and the latter simply calls the former with ign_usage_count set to false. The other users that want to ignore the usage_count will have to explicitly set that argument to true which is a bit cumbersome. To make this function more practical to use, remove the ign_usage_count argument from the function. The main implementation is in a static function called pm_runtime_get_conditional() and implementations of pm_runtime_get_if_active() and pm_runtime_get_if_in_use() are moved to runtime.c. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Takashi Iwai <tiwai@suse.de> # sound/ Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> # drivers/accel/ivpu/ Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> # drivers/gpu/drm/i915/ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1e8cc8e6 |
|
29-Jan-2024 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Place interrupt related code into irq.c Interrupt related code is spread into irq.c, pci.c, and setup-irq.c. Group them into pre-existing irq.c. Link: https://lore.kernel.org/r/20240129113655.3368-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>
|
#
d7bca919 |
|
08-Mar-2024 |
Alexei Starovoitov <ast@kernel.org> |
mm: Introduce vmap_page_range() to map pages in PCI address space ioremap_page_range() should be used for ranges within vmalloc range only. The vmalloc ranges are allocated by get_vm_area(). PCI has "resource" allocator that manages PCI_IOBASE, IO_SPACE_LIMIT address range, hence introduce vmap_page_range() to be used exclusively to map pages in PCI address space. Fixes: 3e49a866c9dc ("mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.") Reported-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/bpf/CANiq72ka4rir+RTN2FQoT=Vvprp_Ao-CvoYEkSNqtSY+RZj+AA@mail.gmail.com
|
#
41044d53 |
|
23-Jan-2024 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Fix active state requirement in PME polling The commit noted in fixes added a bogus requirement that runtime PM managed devices need to be in the RPM_ACTIVE state for PME polling. In fact, only devices in low power states should be polled. However there's still a requirement that the device config space must be accessible, which has implications for both the current state of the polled device and the parent bridge, when present. It's not sufficient to assume the bridge remains in D0 and cases have been observed where the bridge passes the D0 test, but the PM state indicates RPM_SUSPENDING and config space of the polled device becomes inaccessible during pci_pme_wakeup(). Therefore, since the bridge is already effectively required to be in the RPM_ACTIVE state, formalize this in the code and elevate the PM usage count to maintain the state while polling the subordinate device. This resolves a regression reported in the bugzilla below where a Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint downstream of a bridge in a D3hot power state. Link: https://lore.kernel.org/r/20240123185548.1040096-1-alex.williamson@redhat.com Fixes: d3fcd7360338 ("PCI: Fix runtime PM race with PME polling") Reported-by: Sanath S <sanath.s@amd.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218360 Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Sanath S <sanath.s@amd.com> Reviewed-by: Rafael J. Wysocki <rafael@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Cc: Mika Westerberg <mika.westerberg@linux.intel.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
|
#
4d07a053 |
|
21-Dec-2023 |
Dave Jiang <dave.jiang@intel.com> |
cxl: Calculate and store PCI link latency for the downstream ports The latency is calculated by dividing the flit size over the bandwidth. Add support to retrieve the flit size for the CXL switch device and calculate the latency of the PCIe link. Cache the latency number with cxl_dport. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/170319621931.2212653.6800240203604822886.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
#
dc4e6f21 |
|
06-Nov-2021 |
Puranjay Mohan <puranjay12@gmail.com> |
PCI: Use resource names in PCI log messages Use the pci_resource_name() to get the name of the resource and use it while printing log messages. [bhelgaas: rename to match struct resource * names, also use names in other BAR messages] Link: https://lore.kernel.org/r/20211106112606.192563-3-puranjay12@gmail.com Signed-off-by: Puranjay Mohan <puranjay12@gmail.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>
|
#
0a5ef959 |
|
15-Nov-2023 |
Ido Schimmel <idosch@nvidia.com> |
PCI: Add debug print for device ready delay Currently, the time it took a PCI device to become ready after reset is only printed if it was longer than 1000ms ('PCI_RESET_WAIT'). However, for debugging purposes it is useful to know this time even if it was shorter. For example, with the device I am working on, hardware engineers asked to verify that it becomes ready on the first try (no delay). To that end, add a debug level print that can be enabled using dynamic debug. Example: # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset # dmesg -c | grep ready # echo "file drivers/pci/pci.c +p" > /sys/kernel/debug/dynamic_debug/control # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset # dmesg -c | grep ready [ 396.060335] mlxsw_spectrum4 0000:01:00.0: ready 0ms after bus reset # echo "file drivers/pci/pci.c -p" > /sys/kernel/debug/dynamic_debug/control # echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset # dmesg -c | grep ready Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
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>
|
#
04e82fa5 |
|
10-Oct-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use FIELD_GET() in Sapphire RX 5600 XT Pulse quirk Use FIELD_GET() to remove dependences on the field position, i.e., the shift value. No functional change intended. Separate because this isn't as trivial as the other FIELD_GET() changes. See 907830b0fc9e ("PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse") Link: https://lore.kernel.org/r/20231010204436.1000644-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@amd.com>
|
#
e0f0a16f |
|
10-Oct-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use FIELD_GET() Use FIELD_GET() and FIELD_PREP() to remove dependences on the field position, i.e., the shift value. No functional change intended. Link: https://lore.kernel.org/r/20231010204436.1000644-2-helgaas@kernel.org 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>
|
#
d1f9b39d |
|
19-Sep-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Use FIELD_GET() to extract Link Width Use FIELD_GET() to extract PCIe Negotiated and Maximum Link Width fields instead of custom masking and shifting. Link: https://lore.kernel.org/r/20230919125648.1920-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: drop duplicate include of <linux/bitfield.h>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
d15f1805 |
|
11-Sep-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Do error check on own line to split long "if" conditions Placing PCI error code check inside "if" condition usually results in need to split lines. Combined with additional conditions the "if" condition becomes messy. Convert to the usual error handling pattern with an additional variable to improve code readability. In addition, reverse the logic in pci_find_vsec_capability() to get rid of &&. No functional changes intended. Link: https://lore.kernel.org/r/20230911125354.25501-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: PCI_POSSIBLE_ERROR()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
83c08814 |
|
03-Oct-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Use PCI_HEADER_TYPE_* instead of literals Replace literals under drivers/pci/ with PCI_HEADER_TYPE_MASK, PCI_HEADER_TYPE_NORMAL, and PCI_HEADER_TYPE_MFD. Also replace !! boolean conversions with FIELD_GET(). Link: https://lore.kernel.org/r/20231003125300.5541-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # for Renesas R-Car
|
#
5694ba13 |
|
23-Aug-2023 |
Feiyang Chen <chenfeiyang@loongson.cn> |
PCI/PM: Only read PCI_PM_CTRL register when available For a device with no Power Management Capability, pci_power_up() previously returned 0 (success) if the platform was able to put the device in D0, which led to pci_set_full_power_state() trying to read PCI_PM_CTRL, even though it doesn't exist. Since dev->pm_cap == 0 in this case, pci_set_full_power_state() actually read the wrong register, interpreted it as PCI_PM_CTRL, and corrupted dev->current_state. This led to messages like this in some cases: pci 0000:01:00.0: Refused to change power state from D3hot to D0 To prevent this, make pci_power_up() always return a negative failure code if the device lacks a Power Management Capability, even if non-PCI platform power management has been able to put the device in D0. The failure will prevent pci_set_full_power_state() from trying to access PCI_PM_CTRL. Fixes: e200904b275c ("PCI/PM: Split pci_power_up()") Link: https://lore.kernel.org/r/20230824013738.1894965-1-chenfeiyang@loongson.cn Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: "Rafael J. Wysocki" <rafael@kernel.org> Cc: stable@vger.kernel.org # v5.19+
|
#
1856d1a0 |
|
14-Dec-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Tidy config space save/restore messages Update config space save/restore debug messages so they line up better. Previously: nvme 0000:05:00.0: saving config space at offset 0x4 (reading 0x20100006) nvme 0000:05:00.0: saving config space at offset 0x8 (reading 0x1080200) nvme 0000:05:00.0: saving config space at offset 0xc (reading 0x0) nvme 0000:05:00.0: restoring config space at offset 0x4 (was 0x0, writing 0x20100006) Now: nvme 0000:05:00.0: save config 0x04: 0x20100006 nvme 0000:05:00.0: save config 0x08: 0x01080200 nvme 0000:05:00.0: save config 0x0c: 0x00000000 nvme 0000:05:00.0: restore config 0x04: 0x00000000 -> 0x20100006 No functional change intended. Enable these messages by setting CONFIG_DYNAMIC_DEBUG=y and adding 'dyndbg="file drivers/pci/* +p"' to kernel parameters. Link: https://lore.kernel.org/r/20230823191831.476579-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org>
|
#
86b4ad7d |
|
24-Aug-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix typos in docs and comments Fix typos in docs and comments. Link: https://lore.kernel.org/r/20230824193712.542167-11-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
#
2b4af4b3 |
|
23-Aug-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix pci_bus_resetable(), pci_slot_resetable() name typos Fix typos in the pci_bus_resetable() and pci_slot_resetable() function names. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-10-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
#
3b59ca94 |
|
07-Dec-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Simplify pci_pio_to_address() Simplify pci_pio_to_address() by removing an unnecessary local variable. No functional change intended. Link: https://lore.kernel.org/r/20230824193712.542167-8-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
#
d3fcd736 |
|
03-Aug-2023 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Fix runtime PM race with PME polling Testing that a device is not currently in a low power state provides no guarantees that the device is not imminently transitioning to such a state. Increment the PM usage counter before accessing the device. Since we don't wish to wake the device for PME polling, do so only if the device is already active by using pm_runtime_get_if_active(). Link: https://lore.kernel.org/r/20230803171233.3810944-3-alex.williamson@redhat.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fb0171a4 |
|
17-Jul-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Make link retraining use RMW accessors for changing LNKCTL Don't assume that the device is fully under the control of PCI core. Use RMW capability accessors in link retraining which do proper locking to avoid losing concurrent updates to the register values. Suggested-by: Lukas Wunner <lukas@wunner.de> Fixes: 4ec73791a64b ("PCI: Work around Pericom PCIe-to-PCI bridge Retrain Link erratum") Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") Link: https://lore.kernel.org/r/20230717120503.15276-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
|
#
9e30fd26 |
|
14-Jun-2023 |
Ondrej Zary <linux@zary.sk> |
PCI/PM: Avoid putting EloPOS E2/S2/H2 PCIe Ports in D3cold The quirk for Elo i2 introduced in commit 92597f97a40b ("PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold") is also needed by EloPOS E2/S2/H2 which uses the same Continental Z2 board. Change the quirk to match the board instead of system. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215715 Link: https://lore.kernel.org/r/20230614074253.22318-1-linux@zary.sk Signed-off-by: Ondrej Zary <linux@zary.sk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
|
#
08e3ed12 |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Add failed link recovery for device reset events Request failed link recovery with any upstream PCIe bridge where a device has not come back after reset within PCI_RESET_WAIT time. Reset the polling interval if recovery succeeded, otherwise continue as usual. [bhelgaas: inline pcie_parent_link_retrain()] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2306111631050.64925@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
7604bc29 |
|
11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Use pcie_wait_for_link_status() in pcie_wait_for_link_delay() Remove a DLLLA status bit polling loop from pcie_wait_for_link_delay() and call almost identical code in pcie_wait_for_link_status() instead. This reduces the lower bound on the polling interval from 10ms to 1ms, possibly increasing the CPU load on the system in favour to reducing the wait time. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2306111611170.64925@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>
|
#
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>
|
#
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>
|
#
02992064 |
|
04-Apr-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PCI: Make pci_bus_for_each_resource() index optional Refactor pci_bus_for_each_resource() in the same way as pci_dev_for_each_resource(). This allows the index to be hidden inside the implementation so the caller can omit it when it's not used otherwise. No functional changes intended. Link: https://lore.kernel.org/r/20230330162434.35055-6-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
|
#
75cff725 |
|
13-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: bus: mark the struct bus_type for sysfs callbacks as constant struct bus_type should never be modified in a sysfs callback as there is nothing in the structure to modify, and frankly, the structure is almost never used in a sysfs callback, so mark it as constant to allow struct bus_type to be moved to read-only memory. Cc: "David S. Miller" <davem@davemloft.net> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Ben Widawsky <bwidawsk@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Hu Haowen <src.res@email.cn> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Stuart Yoder <stuyoder@gmail.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Yanteng Si <siyanteng@loongson.cn> Acked-by: Ilya Dryomov <idryomov@gmail.com> # rbd Acked-by: Ira Weiny <ira.weiny@intel.com> # cxl Reviewed-by: Alex Shi <alexs@kernel.org> Acked-by: Iwona Winiarska <iwona.winiarska@intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci Acked-by: Wei Liu <wei.liu@kernel.org> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi Link: https://lore.kernel.org/r/20230313182918.1312597-23-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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+
|
#
8ef02172 |
|
15-Jan-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI/PM: Observe reset delay irrespective of bridge_d3 If a PCI bridge is suspended to D3cold upon entering system sleep, resuming it entails a Fundamental Reset per PCIe r6.0 sec 5.8. The delay prescribed after a Fundamental Reset in PCIe r6.0 sec 6.6.1 is sought to be observed by: pci_pm_resume_noirq() pci_pm_bridge_power_up_actions() pci_bridge_wait_for_secondary_bus() However, pci_bridge_wait_for_secondary_bus() bails out if the bridge_d3 flag is not set. That flag indicates whether a bridge is allowed to suspend to D3cold at *runtime*. Hence *no* delay is observed on resume from system sleep if runtime D3cold is forbidden. That doesn't make any sense, so drop the bridge_d3 check from pci_bridge_wait_for_secondary_bus(). The purpose of the bridge_d3 check was probably to avoid delays if a bridge remained in D0 during suspend. However the sole caller of pci_bridge_wait_for_secondary_bus(), pci_pm_bridge_power_up_actions(), is only invoked if the previous power state was D3cold. Hence the additional bridge_d3 check seems superfluous. Fixes: ad9001f2f411 ("PCI/PM: Add missing link delays required by the PCIe spec") Link: https://lore.kernel.org/r/eb37fa345285ec8bacabbf06b020b803f77bdd3d.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> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: stable@vger.kernel.org # v5.5+
|
#
8b3517f8 |
|
31-Jan-2023 |
Huacai Chen <chenhuacai@kernel.org> |
PCI: loongson: Prevent LS7A MRRS increases Except for isochronous-configured devices, software may set Max_Read_Request_Size (MRRS) to any value up to 4096. If a device issues a read request with size greater than the completer's Max_Payload_Size (MPS), the completer is required to break the response into multiple completions. Instead of correctly responding with multiple completions to a large read request, some LS7A Root Ports respond with a Completer Abort. To prevent this, the MRRS must be limited to an implementation-specific value. The OS cannot detect that value, so rely on BIOS to configure MRRS before booting, and quirk the Root Ports so we never set an MRRS larger than that BIOS value for any downstream device. N.B. Hot-added devices are not configured by BIOS, and they power up with MRRS = 512 bytes, so these devices will be limited to 512 bytes. If the LS7A limit is smaller, those hot-added devices may not work correctly, but per [1], hotplug is not supported with this chipset revision. [1] https://lore.kernel.org/r/073638a7-ae68-2847-ac3d-29e5e760d6af@loongson.cn [bhelgaas: commit log] Link: https://bugzilla.kernel.org/show_bug.cgi?id=216884 Link: https://lore.kernel.org/r/20230201043018.778499-3-chenhuacai@loongson.cn Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
98b04dd0 |
|
26-Oct-2022 |
Michael S. Tsirkin <mst@redhat.com> |
PCI: Fix pci_device_is_present() for VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned "false" in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag] Link: https://lore.kernel.org/r/20221026060912.173250-1-mst@redhat.com Reported-by: Wei Gong <gongwei833x@gmail.com> Tested-by: Wei Gong <gongwei833x@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
|
#
c14f7ccc |
|
14-Jul-2022 |
Pali Rohár <pali@kernel.org> |
PCI: Assign PCI domain IDs by ida_alloc() Replace assignment of PCI domain IDs from atomic_inc_return() to ida_alloc(). Use two IDAs, one for static domain allocations (those which are defined in device tree) and second for dynamic allocations (all other). During removal of root bus / host bridge, also release the domain ID. The released ID can be reused again, for example when dynamically loading and unloading native PCI host bridge drivers. This change also allows to mix static device tree assignment and dynamic by kernel as all static allocations are reserved in dynamic pool. [bhelgaas: set "err" if "bus->domain_nr < 0"] Link: https://lore.kernel.org/r/20220714184130.5436-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> 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>
|
#
3e347969 |
|
21-Sep-2022 |
Sajid Dalvi <sdalvi@google.com> |
PCI/PM: Reduce D3hot delay with usleep_range() PCIe r6.0, sec 5.9, requires a 10ms delay between programming a device to change to or from D3hot and the time the device is next accessed (unless Readiness Notifications are used). The 10ms value (PCI_PM_D3HOT_WAIT) doesn't appear directly here because some chipsets require 120ms for devices *below* them (pci_pm_d3hot_delay) and some devices require more or less than 10ms (dev->d3hot_delay). But msleep(10) typically waits about *20*ms, which is more than we need. Switch to usleep_range() to improve the delay accuracy. Based on a commit from Sajid in the Pixel 6 kernel tree [1]. On a Pixel 6, the 10ms delay for the Exynos PCIe device delayed for an average of 19ms. Switching to usleep_range() decreased the resume time by about 9ms. [1] https://android.googlesource.com/kernel/gs/+/18a8cad68d8e6d50f339a716a18295e6d987cee3 [bhelgaas commit log, add timers-howto.rst link] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v5.19#n73 Link: https://lore.kernel.org/r/20220921212735.2131588-1-willmcvicker@google.com Signed-off-by: Sajid Dalvi <sdalvi@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
|
#
c01163db |
|
09-Sep-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Always disable PTM for all devices during suspend We want to disable PTM on Root Ports because that allows some chips, e.g., Intel mobile chips since Coffee Lake, to enter a lower-power PM state. That means we also have to disable PTM on downstream devices. PCIe r6.0, sec 2.2.8, recommends that functions support generation of messages in non-D0 states, so we have to assume Switch Upstream Ports or Endpoints may send PTM Requests while in D1, D2, and D3hot. A PTM message received by a Downstream Port (including a Root Port) with PTM disabled must be treated as an Unsupported Request (sec 6.21.3). PTM was previously disabled only for Root Ports, and it was disabled in pci_prepare_to_sleep(), which is not called at all if a driver supports legacy PM or does its own state saving. Instead, disable PTM early in pci_pm_suspend() and pci_pm_runtime_suspend() so we do it in all cases. Previously PTM was disabled *after* saving device state, so the state restore on resume automatically re-enabled it. Since we now disable PTM *before* saving state, we must explicitly re-enable it in pci_pm_resume() and pci_pm_runtime_resume(). Here's a sample of errors that occur when PTM is disabled only on the Root Port. With this topology: 0000:00:1d.0 Root Port to [bus 08-71] 0000:08:00.0 Switch Upstream Port to [bus 09-71] Kai-Heng reported errors like this: pcieport 0000:00:1d.0: [20] UnsupReq (First) pcieport 0000:00:1d.0: AER: TLP Header: 34000000 08000052 00000000 00000000 Decoding TLP header 0x34...... (0011 0100b) and 0x08000052: Fmt 001b 4 DW header, no data Type 1 0100b Msg (Local - Terminate at Receiver) Requester ID 0x0800 Bus 08 Devfn 00.0 Message Code 0x52 0101 0010b PTM Request The 00:1d.0 Root Port logged an Unsupported Request error when it received a PTM Request with Requester ID 08:00.0. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215453 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216210 Fixes: a697f072f5da ("PCI: Disable PTM during suspend to save power") Link: https://lore.kernel.org/r/20220909202505.314195-10-helgaas@kernel.org Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> 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>
|
#
abb4970a |
|
22-Jul-2022 |
Stafford Horne <shorne@gmail.com> |
PCI: Move isa_dma_bridge_buggy out of asm/dma.h The isa_dma_bridge_buggy symbol is only used for x86_32, and only x86_32 platforms or quirks ever set it. Add a new linux/isa-dma.h header that #defines isa_dma_bridge_buggy to 0 except on x86_32, where we keep it as a variable, and remove all the arch- specific definitions. [bhelgaas: commit log] Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Christoph Hellwig <hch@infradead.org> Link: https://lore.kernel.org/r/20220722214944.831438-3-shorne@gmail.com Signed-off-by: Stafford Horne <shorne@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
#
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>
|
#
12068bb3 |
|
26-May-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Fix bridge_d3_blacklist[] Elo i2 overwrite of Gigabyte X299 92597f97a40b ("PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold") omitted braces around the new Elo i2 entry, so it overwrote the existing Gigabyte X299 entry. Add the appropriate braces. Found by: $ make W=1 drivers/pci/pci.o CC drivers/pci/pci.o drivers/pci/pci.c:2974:12: error: initialized field overwritten [-Werror=override-init] 2974 | .ident = "Elo i2", | ^~~~~~~~ Link: https://lore.kernel.org/r/20220526221258.GA409855@bhelgaas Fixes: 92597f97a40b ("PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.15+
|
#
a91ee0e9 |
|
04-Apr-2022 |
Yicong Yang <yangyicong@hisilicon.com> |
PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] Link: https://lore.kernel.org/linux-pci/1583489997-17156-1-git-send-email-yangyicong@hisilicon.com/ Also-posted-by: Jay Zhou <jianjay.zhou@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3cc2a2b2 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Rearrange pci_set_power_state() The part of pci_set_power_state() related to transitions into low-power states is unnecessary convoluted, so clearly divide it into the D3cold special case and the general case covering all of the other states. Also fix a potential issue with calling pci_bus_set_current_state() to set the current state of all devices on the subordinate bus to D3cold without checking if the power state of the parent bridge has really changed to D3cold. Link: https://lore.kernel.org/r/2139440.Mh6RI2rZIc@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>
|
#
0aacdc95 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Clean up pci_set_low_power_state() Make the following assorted non-essential changes in pci_set_low_power_state(): 1. Drop two redundant checks from it (the caller takes care of these conditions). 2. Change the log level of a messages printed by it to "debug", because it only indicates a programming mistake. Link: https://lore.kernel.org/r/2539071.Lt9SDvczpP@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>
|
#
0ce74a3b |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Do not restore BARs if device is not in D0 Do not attempt to restore the device's BARs in pci_set_full_power_state() if the actual current power state of the device is not D0. Link: https://lore.kernel.org/r/1849718.CQOukoFCf9@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
e200904b |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Split pci_power_up() One of the two callers of pci_power_up() invokes pci_update_current_state() and pci_restore_state() right after calling it, in which case running the part of it happening after the mandatory transition delays is redundant, so move that part out of it into a new function called pci_set_full_power_state() that will be invoked from pci_set_power_state() which is the other caller of pci_power_up(). Link: https://lore.kernel.org/r/1942150.usQuhbGJ8B@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f0881d38 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Write 0 to PMCSR in pci_power_up() in all cases Make pci_power_up() write 0 to the device's PCI_PM_CTRL register in order to put it into D0 regardless of the power state returned by the previous read from that register which should not matter. Link: https://lore.kernel.org/r/5748066.MhkbZ0Pkbq@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0b591935 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Do not call pci_update_current_state() from pci_power_up() Notice that calling pci_update_current_state() from pci_power_up() is redundant and may be harmful in some cases. First, if the device is in a low-power state before pci_power_up() gets called for it and platform_pci_set_power_state() successfully changes its power state to D0, pci_update_current_state() will update current_state to reflect that and pci_power_up() will return success right away without restoring the device's BARs or reconfiguring ASPM which may be necessary. This is arguably incorrect and definitely inconsistent with the case when platform_pci_set_power_state() returns an error (for example, because the device is not power-manageable by the platform firmware). Second, current_state should not be overwritten until the decision whether or not to restore the device's BARs is made, because that decision generally depends on its value. Again, calling pci_update_current_state() in pci_power_up() is not consistent with this observation. Next, pci_power_up() attempts to read from the device's PCI_PM_CTRL register regardless of the current_state value unless it is PCI_D0, including the case when pci_update_current_state() sets current_state to PCI_D3cold to indicate that the device is not accessible. If the register read is not successful, current_state will be set to PCI_D3cold anyway, so that pci_update_current_state() action is redundant. Further, if pci_update_current_state() reads the device's PCI_PM_CTRL register, pci_power_up() will repeat that read going forward and it is not necessary to update current_state in the meantime. Finally, if pm_cap is not set (in which case the PCI_PM_CTRL register is not present), the power state of the device should be determined with the help of the platform firmware or set to D0 if that's not possible and pci_update_current_state() does not do that. Accordingly, rearrange pci_power_up() so as to address the above shortcomings. Link: https://lore.kernel.org/r/3695055.kQq0lBPeGt@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6d8c016a |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Unfold pci_platform_power_transition() in pci_power_up() Some actions carried out by pci_platform_power_transition(() in pci_power_up() are redundant, but before dealing with them, make pci_power_up() call the pci_platform_power_transition() code directly (and avoid a redundant check when pm_cap is unset while at it). Link: https://lore.kernel.org/r/1922486.PYKUYFuaPT@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1aa85bb1 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Set current_state to D3cold if the device is not accessible Make pci_power_up() and pci_set_low_power_state() change current_state to PCI_D3cold when the device is not accessible along the lines of pci_update_current_state(). Link: https://lore.kernel.org/r/10104376.nUPlyArG6x@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7957d201 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Relocate pci_set_low_power_state() Because pci_set_power_state() is the only caller of pci_set_low_power_state(), put the latter next to the former. No functional impact. Link: https://lore.kernel.org/r/3202976.44csPzL39Z@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
10aa5377 |
|
05-May-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Split pci_raw_set_power_state() The transitions from low-power states to D0 and the other way around are unnecessarily tangled in pci_raw_set_power_state() which makes it rather hard to follow. Moreover, the only caller of pci_raw_set_power_state() passing PCI_D0 as its state argument is pci_power_up(), so the code carrying out transitions into D0 can be put directly into that function. Accordingly, move the code handling transitions from low-power states into D0 directly into pci_power_up() and rename the remaining part of pci_raw_set_power_state() to pci_set_low_power_state(), because it only handles transitions into low-power state now. While at it, fix up some white space, update some comments and modify messages printed by pci_power_up() and pci_set_low_power_state() to be less confusing (which is the only expected functional impact of this change). Link: https://lore.kernel.org/r/13038676.uLZWGnKmhe@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9c384ddd |
|
14-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Rearrange pci_update_current_state() Save one config space access in pci_update_current_state() by testing the retrieved PCI_PM_CTRL register value against PCI_POSSIBLE_ERROR() instead of invoking pci_device_is_present() separately. While at it, drop a pair of unnecessary parens. No expected functional impact. Link: https://lore.kernel.org/r/1917095.PYKUYFuaPT@kreacher Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8221ecd4 |
|
14-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Drop the runtime_d3cold device flag The runtime_d3cold flag is not needed any more, so drop it. Link: https://lore.kernel.org/r/8077784.T7Z3S40VBb@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>
|
#
730643d3 |
|
14-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Resume subordinate bus in bus type callbacks Calling pci_resume_bus() on the secondary bus from pci_power_up() as it is done now is questionable, because it depends on the mandatory bridge power-up delays that are only covered by the PCI bus type PM callbacks. For this reason, move the subordinate bus resume to those callbacks too and use the observation that if a bridge is being powered-up during resume from system-wide suspend, it may be still desirable to runtime-resume its subordinate bus after completing the system-wide transition (in case the resume of the devices on that bus is skipped during it). Link: https://lore.kernel.org/r/3190097.aeNJFYEL58@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>
|
#
92597f97 |
|
31-Mar-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold If a Root Port on Elo i2 is put into D3cold and then back into D0, the downstream device becomes permanently inaccessible, so add a bridge D3 DMI quirk for that system. This was exposed by 14858dcc3b35 ("PCI: Use pci_update_current_state() in pci_enable_device_flags()"), but before that commit the Root Port in question had never been put into D3cold for real due to a mismatch between its power state retrieved from the PCI_PM_CTRL register (which was accessible even though the platform firmware indicated that the port was in D3cold) and the state of an ACPI power resource involved in its power management. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215715 Link: https://lore.kernel.org/r/11980172.O9o76ZdvQC@kreacher Reported-by: Stefan Gottwald <gottwald@igel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.15+
|
#
4353594e |
|
21-Dec-2021 |
Rajat Jain <rajatja@google.com> |
PCI: Use DWORD accesses for LTR, L1 SS to avoid erratum Some devices have an erratum such that they only support DWORD accesses to some registers. E.g., this Bayhub O2 device ([VID:DID] = [0x1217:0x8621]) only supports DWORD accesses to LTR latency registers and L1 PM substates control registers: https://github.com/rajatxjain/public_shared/blob/main/OZ711LV2_appnote.pdf The L1 PM substate control registers are DWORD sized, and hence their access in the kernel is already DWORD sized, so we don't need to do anything for them. However, the LTR registers being WORD sized, are in need of a solution. Convert the WORD sized accesses to these registers into DWORD sized accesses while saving and restoring them. Link: https://lore.kernel.org/r/20211222012105.3438916-1-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fa52b644 |
|
18-Nov-2021 |
Naveen Naidu <naveennaidu479@gmail.com> |
PCI/ERR: Use PCI_POSSIBLE_ERROR() to check config reads When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Link: https://lore.kernel.org/r/f4d18d470cb90f9cb52ea155b01528ba2e76e8d6.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3f35d2cf |
|
15-Dec-2021 |
Thomas Gleixner <tglx@linutronix.de> |
PCI/MSI: Decouple MSI[-X] disable from pcim_release() The MSI core will introduce runtime allocation of MSI related data. This data will be devres managed and has to be set up before enabling PCI/MSI[-X]. This would introduce an ordering issue vs. pcim_release(). The setup order is: pcim_enable_device() devres_alloc(pcim_release...); ... pci_irq_alloc() msi_setup_device_data() devres_alloc(msi_device_data_release, ...) and once the device is released these release functions are invoked in the opposite order: msi_device_data_release() ... pcim_release() pci_disable_msi[x]() which is obviously wrong, because pci_disable_msi[x]() requires the MSI data to be available to tear down the MSI[-X] interrupts. Remove the MSI[-X] teardown from pcim_release() and add an explicit action to be installed on the attempt of enabling PCI/MSI[-X]. This allows the MSI core data allocation to be ordered correctly in a subsequent step. Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Michael Kelley <mikelley@microsoft.com> Tested-by: Nishanth Menon <nm@ti.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/87tuf9rdoj.ffs@tglx
|
#
dfd5bb23 |
|
05-May-2021 |
Niklas Schnelle <schnelle@linux.ibm.com> |
PCI: Export pci_dev_lock() Commit e3a9b1212b9d ("PCI: Export pci_dev_trylock() and pci_dev_unlock()") already exported pci_dev_trylock()/pci_dev_unlock() however in some circumstances such as during error recovery it makes sense to block waiting to get full access to the device so also export pci_dev_lock(). Link: https://lore.kernel.org/all/20210928181014.GA713179@bhelgaas/ Acked-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
#
e0217c5b |
|
09-Nov-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI: Use to_pci_driver() instead of pci_dev->driver" This reverts commit 2a4d9408c9e8b6f6fc150c66f3fef755c9e20d4a. Robert reported a NULL pointer dereference caused by the PCI core (local_pci_probe()) calling the i2c_designware_pci driver's .runtime_resume() method before the .probe() method. i2c_dw_pci_resume() depends on initialization done by i2c_dw_pci_probe(). Prior to 2a4d9408c9e8 ("PCI: Use to_pci_driver() instead of pci_dev->driver"), pci_pm_runtime_resume() avoided calling the .runtime_resume() method because pci_dev->driver had not been set yet. 2a4d9408c9e8 and b5f9c644eb1b ("PCI: Remove struct pci_dev->driver"), removed pci_dev->driver, replacing it by device->driver, which *has* been set by this time, so pci_pm_runtime_resume() called the .runtime_resume() method when it previously had not. Fixes: 2a4d9408c9e8 ("PCI: Use to_pci_driver() instead of pci_dev->driver") Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/ Reported-by: Robert Święcki <robert@swiecki.net> Tested-by: Robert Święcki <robert@swiecki.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ee122037 |
|
09-Oct-2021 |
Ben Widawsky <ben.widawsky@intel.com> |
PCI: Add pci_find_dvsec_capability to find designated VSEC Add pci_find_dvsec_capability to locate a Designated Vendor-Specific Extended Capability with the specified Vendor ID and Capability ID. The Designated Vendor-Specific Extended Capability (DVSEC) allows one or more "vendor" specific capabilities that are not tied to the Vendor ID of the PCI component. Where the DVSEC Vendor may be a standards body like CXL. Cc: David E. Box <david.e.box@linux.intel.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linux-pci@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163379787943.692348.6814373487017444007.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
#
5ec0a6fc |
|
11-Sep-2021 |
Selvin Xavier <selvin.xavier@broadcom.com> |
PCI: Do not enable AtomicOps on VFs Host crashes when pci_enable_atomic_ops_to_root() is called for VFs with virtual buses. The virtual buses added to SR-IOV have bus->self set to NULL and host crashes due to this. PID: 4481 TASK: ffff89c6941b0000 CPU: 53 COMMAND: "bash" ... #3 [ffff9a9481713808] oops_end at ffffffffb9025cd6 #4 [ffff9a9481713828] page_fault_oops at ffffffffb906e417 #5 [ffff9a9481713888] exc_page_fault at ffffffffb9a0ad14 #6 [ffff9a94817138b0] asm_exc_page_fault at ffffffffb9c00ace [exception RIP: pcie_capability_read_dword+28] RIP: ffffffffb952fd5c RSP: ffff9a9481713960 RFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff89c6b1096000 RCX: 0000000000000000 RDX: ffff9a9481713990 RSI: 0000000000000024 RDI: 0000000000000000 RBP: 0000000000000080 R8: 0000000000000008 R9: ffff89c64341a2f8 R10: 0000000000000002 R11: 0000000000000000 R12: ffff89c648bab000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff89c648bab0c8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9a9481713988] pci_enable_atomic_ops_to_root at ffffffffb95359a6 #8 [ffff9a94817139c0] bnxt_qplib_determine_atomics at ffffffffc08c1a33 [bnxt_re] #9 [ffff9a94817139d0] bnxt_re_dev_init at ffffffffc08ba2d1 [bnxt_re] Per PCIe r5.0, sec 9.3.5.10, the AtomicOp Requester Enable bit in Device Control 2 is reserved for VFs. The PF value applies to all associated VFs. Return -EINVAL if pci_enable_atomic_ops_to_root() is called for a VF. Link: https://lore.kernel.org/r/1631354585-16597-1-git-send-email-selvin.xavier@broadcom.com Fixes: 35f5ace5dea4 ("RDMA/bnxt_re: Enable global atomic ops if platform supports") Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
|
#
fd1ae23b |
|
12-Oct-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Prefer 'unsigned int' over bare 'unsigned' The bare "unsigned" type implicitly means "unsigned int", but the preferred coding style is to use the complete type name. Update the bare use of "unsigned" to the preferred "unsigned int". No change to functionality intended. See a1ce18e4f941 ("checkpatch: warn on bare unsigned or signed declarations without int"). Link: https://lore.kernel.org/r/20211013014136.1117543-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ff5d3bb6 |
|
10-Sep-2021 |
Colin Ian King <colin.king@canonical.com> |
PCI: Remove redundant 'rc' initialization The variable 'rc' is being initialized with a value that is never read. Remove the redundant assignment. Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210910161417.91001-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.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>
|
#
2a4d9408 |
|
12-Oct-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
PCI: Use to_pci_driver() instead of pci_dev->driver Struct pci_driver contains a struct device_driver, so for PCI devices, it's easy to convert a device_driver * to a pci_driver * with to_pci_driver(). The device_driver * is in struct device, so we don't need to also keep track of the pci_driver * in struct pci_dev. Replace pci_dev->driver with to_pci_driver(). This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-11-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f9a6c8ad |
|
31-Jul-2021 |
Lukas Wunner <lukas@wunner.de> |
PCI/ERR: Reduce compile time for CONFIG_PCIEAER=n The sole non-static function in err.c, pcie_do_recovery(), is only called from: * aer.c (if CONFIG_PCIEAER=y) * dpc.c (if CONFIG_PCIE_DPC=y, which depends on CONFIG_PCIEAER) * edr.c (if CONFIG_PCIE_EDR=y, which depends on CONFIG_PCIE_DPC) Thus, err.c need not be compiled if CONFIG_PCIEAER=n. Also, pci_uevent_ers() and pcie_clear_device_status(), which are called from err.c, can be #ifdef'ed away unless CONFIG_PCIEAER=y. Since x86_64_defconfig doesn't enable CONFIG_PCIEAER, this change may slightly reduce compile time for anyone doing a test build with that config. Link: https://lore.kernel.org/r/98f9041151268c1c035ab64cca320ad86803f64a.1627638184.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
357df2fc |
|
08-Oct-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Use unsigned to match sscanf("%x") in pci_dev_str_match_path() Cppcheck warns that pci_dev_str_match_path() passes pointers to signed ints to sscanf("%x"), which expects pointers to *unsigned* ints: invalidScanfArgType_int drivers/pci/pci.c:312 %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'. Declare the variables as unsigned to avoid this issue. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20211008222732.2868493-3-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
06dc660e |
|
13-Sep-2021 |
Oliver O'Halloran <oohall@gmail.com> |
PCI: Rename pcibios_add_device() to pcibios_device_add() The general convention for pcibios_* hooks is that they're named after the corresponding pci_* function they provide a hook for. The exception is pcibios_add_device() which provides a hook for pci_device_add(). Rename pcibios_add_device() to pcibios_device_add() so it matches pci_device_add(). Also, remove the export of the microblaze version. The only caller must be compiled as a built-in so there's no reason for the export. Link: https://lore.kernel.org/r/20210913152709.48013-1-oohall@gmail.com Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Niklas Schnelle <schnelle@linux.ibm.com> # s390
|
#
7c2584fa |
|
25-Sep-2021 |
Sergio Paracuellos <sergio.paracuellos@gmail.com> |
PCI: Allow architecture-specific pci_remap_iospace() pci_remap_iospace() was originally meant as an architecture specific helper but it moved into generic code after all architectures had the same requirements. MIPS has different requirements so it should not be shared. The way for doing this will be using a macro 'pci_remap_iospace' defined for those architectures that need a special treatment. Hence, put core API function inside preprocesor conditional code for 'pci_remap_iospace' definition. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20210925203224.10419-5-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6f9f0eef |
|
15-Oct-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Fix ordering of operations in pci_back_from_sleep() The ordering of operations in pci_back_from_sleep() is incorrect, because the device may be in D3cold when it runs and pci_enable_wake() needs to access the device's configuration space which cannot be done in D3cold. Fix this by calling pci_set_power_state() to put the device into D0 before calling pci_enable_wake() for it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fa1a25c5 |
|
29-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Do not call platform_pci_power_manageable() unnecessarily Drop two invocations of platform_pci_power_manageable() that are not necessary, because the functions called when it returns 'true' do the requisite "power manageable" checks themselves. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
6407e5ec |
|
29-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Make pci_choose_state() call pci_target_state() The pci_choose_state() and pci_target_state() implementations are somewhat divergent without a good reason, because they are used for similar purposes. Change the pci_choose_state() implementation to use pci_target_state() internally except for transitions to the working state of the system in which case it is expected to return D0. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.com>
|
#
bf39c929 |
|
29-Sep-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Rearrange pci_target_state() Make pci_target_state() return D3cold or D0 without checking PME support if the current power state of the device is D3cold or if it does not support the standard PCI PM, respectively. Next, drop the tergat_state local variable that has become redundant from it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ferry Toth <fntoth@gmail.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>
|
#
7cae7849 |
|
18-Jun-2021 |
Alex Williamson <alex.williamson@redhat.com> |
PCI/ACS: Enforce pci=noats with Transaction Blocking PCIe Address Translation Services (ATS) provides a mechanism for a device to provide an on-device caching translation agent (device IOTLB). We already have a means to disable support for this feature via the pci=noats option. For untrusted and externally facing devices, we not only disable ATS support for the device, but we use Access Control Services (ACS) Transaction Blocking to actively prevent devices from sending TLPs with non-default AT field values. Extend pci=noats to also make use of PCI_ACS_TB so that not only is ATS disabled at the device, but blocked at the downstream ports. This provides a means to further lock-down ATS for cases such as device assignment, where it may not be the hardware configuration of the device that makes it untrusted, but the driver running on the device. Link: https://lore.kernel.org/r/162404966325.2362347.12176138291577486015.stgit@omen Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Rajat Jain <rajatja@google.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>
|
#
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>
|
#
4ec36dfe |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
PCI: Remove reset_fn field from pci_dev "reset_fn" indicates whether the device supports any reset mechanism. Remove the use of reset_fn in favor of the reset_methods array that tracks supported reset mechanisms of a device and their ordering. The octeon driver incorrectly used reset_fn to detect whether the device supports FLR or not. Use pcie_reset_flr() to probe whether it supports FLR. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-5-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: Alex Williamson <alex.williamson@redhat.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>
|
#
56f107d7 |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
PCI: Add pcie_reset_flr() with 'probe' argument Most reset methods are of the form "pci_*_reset(dev, probe)". pcie_flr() was an exception because it relied on a separate pcie_has_flr() function instead of taking a "probe" argument. Add "pcie_reset_flr(dev, probe)" to follow the convention. Remove pcie_has_flr(). Some pcie_flr() callers that did not use pcie_has_flr() remain. [bhelgaas: commit log, rework pcie_reset_flr() to use dev->devcap directly] Link: https://lore.kernel.org/r/20210817180500.1253-3-ameynarkhede03@gmail.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>
|
#
69139244 |
|
17-Aug-2021 |
Amey Narkhede <ameynarkhede03@gmail.com> |
PCI: Cache PCIe Device Capabilities register Add a new member called devcap in struct pci_dev for caching the PCIe Device Capabilities register to avoid reading PCI_EXP_DEVCAP multiple times. Refactor pcie_has_flr() to use cached device capabilities. Link: https://lore.kernel.org/r/20210817180500.1253-2-ameynarkhede03@gmail.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>
|
#
7eb6ea41 |
|
12-Aug-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
PCI: Fix pci_dev_str_match_path() alloc while atomic bug pci_dev_str_match_path() is often called with a spinlock held so the allocation has to be atomic. The call tree is: pci_specified_resource_alignment() <-- takes spin_lock(); pci_dev_str_match() pci_dev_str_match_path() Fixes: 45db33709ccc ("PCI: Allow specifying devices using a base bus and path of devfns") Link: https://lore.kernel.org/r/20210812070004.GC31863@kili Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
|
#
a67462fc |
|
13-Jul-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Refactor pci_ioremap_bar() and pci_ioremap_wc_bar() pci_ioremap_bar() and pci_ioremap_wc_bar() shared similar implementations but differed in unimportant ways. Align them by adding a shared helper, __pci_ioremap_resource(). Upgrade warning message to error level, since it indicates a driver defect. Remove WARN_ON() from WC path in favor of the error message. [bhelgaas: commit log, use ioremap() since pci_iomap_range() doesn't add anything] Link: https://lore.kernel.org/r/20210713102436.304693-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0e00392a |
|
29-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Enable PME if it can be signaled from D3cold PME signaling is only enabled by __pci_enable_wake() if the target device can signal PME from the given target power state (to avoid pointless reconfiguration of the device), but if the hierarchy above the device goes into D3cold, the device itself will end up in D3cold too, so if it can signal PME from D3cold, it should be enabled to do so in __pci_enable_wake(). [Note that if the device does not end up in D3cold and it cannot signal PME from the original target power state, it will not signal PME, so in that case the behavior does not change.] Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/ Fixes: 5bcc2fb4e815 ("PCI PM: Simplify PCI wake-up code") Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com> Reported-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
da9f2150 |
|
29-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Avoid forcing PCI_D0 for wakeup reasons inconsistently It is inconsistent to return PCI_D0 from pci_target_state() instead of the original target state if 'wakeup' is true and the device cannot signal PME from D0. This only happens when the device cannot signal PME from the original target state and any shallower power states (including D0) and that case is effectively equivalent to the one in which PME singaling is not supported at all. Since the original target state is returned in the latter case, make the function do that in the former one too. Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/ Fixes: 666ff6f83e1d ("PCI/PM: Avoid using device_may_wakeup() for runtime PM") Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com> Reported-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
14858dcc |
|
08-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: Use pci_update_current_state() in pci_enable_device_flags() Updating the current_state field of struct pci_dev the way it is done in pci_enable_device_flags() before calling do_pci_enable_device() may not work. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues, make pci_enable_device_flags() call pci_update_current_state() which takes ACPI device power management into account, if present, to retrieve the current power state of the device. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
|
#
381bd3fa |
|
02-Jun-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI/sysfs: Fix 'resource_alignment' newline issues The value of the "resource_alignment" can be specified using a kernel command-line argument ("pci=resource_alignment=") or through the corresponding sysfs attribute under the /sys/bus/pci path. Previously, when the value was set via the kernel command-line argument, and then subsequently accessed through sysfs attribute, the value read back was not correct: # grep -oE 'pci=resource_alignment.+' /proc/cmdline pci=resource_alignment=20@00:1f.2 # cat /sys/bus/pci/resource_alignment 20@00:1f. This was also true when the value was set through the sysfs attribute without including a trailing newline: # echo -n 20@00:1f.2 > /sys/bus/pci/resource_alignment # cat /sys/bus/pci/resource_alignment 20@00:1f. When it was set through the sysfs attribute *including* a newline, reading it back worked as intended: # echo 20@00:1f.2 > /sys/bus/pci/resource_alignment # cat /sys/bus/pci/resource_alignment 20@00:1f.2 To fix this inconsistency, append a trailing newline in the show() function and strip the trailing line in the store() function if one is present. Also, allow for the value previously set using either a command-line argument or through the sysfs object to be cleared at run-time. [bhelgaas: fold in kfree fix from https://lore.kernel.org/linux-pci/20210604133230.983956-4-kw@linux.com] Fixes: e499081da1a2 ("PCI: Force trailing new line to resource_alignment_param in sysfs") Link: https://lore.kernel.org/r/20210603000112.703037-4-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
|
#
f8cf6e51 |
|
02-Jun-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions The sysfs_emit() and sysfs_emit_at() functions were introduced to make it less ambiguous which function is preferred when writing to the output buffer in a device attribute's "show" callback [1]. Convert the PCI sysfs object "show" functions from sprintf(), snprintf() and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the latter is aware of the PAGE_SIZE buffer and correctly returns the number of bytes written into the buffer. No functional change intended. [1] Documentation/filesystems/sysfs.rst Related commit: ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions"). Link: https://lore.kernel.org/r/20210603000112.703037-2-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
|
#
0dad3ce5 |
|
08-Apr-2021 |
Raphael Norwitz <raphael.norwitz@nutanix.com> |
PCI: Add pci_reset_bus_function() Secondary Bus Reset interface pci_parent_bus_reset() resets a device by performing a Secondary Bus Reset on a PCI-to-PCI bridge leading to the device. pci_dev_reset_slot_function() does the same, except that it uses a hotplug driver to keep the reset from looking like a hot-remove followed by a hot-add. Add a pci_reset_bus_function() wrapper, which attempts the hotplug driver slot reset and falls back to the parent bus reset if that fails. This provides a single interface for performing a Secondary Bus Reset. [bhelgaas: commit log, don't expose yet] Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210323100625.0021a943@omen.home.shazbot.org/ Link: https://lore.kernel.org/r/20210408182328.12323-1-raphael.norwitz@nutanix.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
|
#
e3a9b121 |
|
22-Jun-2021 |
Luis Chamberlain <mcgrof@kernel.org> |
PCI: Export pci_dev_trylock() and pci_dev_unlock() Other places in the kernel use this form, and so just provide a common path for it. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Link: https://lore.kernel.org/r/20210623022824.308041-2-mcgrof@kernel.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
#
4d6035f9 |
|
22-Jun-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "PCI: PM: Do not read power state in pci_enable_device_flags()" Revert commit 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") that is reported to cause PCI device initialization issues on some systems. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213481 Link: https://lore.kernel.org/linux-acpi/YNDoGICcg0V8HhpQ@eldamar.lan Reported-by: Michael <phyre@rogers.com> Reported-by: Salvatore Bonaccorso <carnil@debian.org> Fixes: 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9cc74207 |
|
20-Apr-2021 |
Jianjun Wang <jianjun.wang@mediatek.com> |
PCI: Export pci_pio_to_address() for module use This interface will be used by PCI host drivers for PIO translation, export it to support compiling those drivers as kernel modules. Link: https://lore.kernel.org/r/20210420061723.989-3-jianjun.wang@mediatek.com Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1fd3dde5 |
|
29-Mar-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add pci_disable_parity() Add pci_disable_parity() to disable reporting of parity errors for a device by clearing PCI_COMMAND_PARITY. The device will still set PCI_STATUS_DETECTED_PARITY when it detects a parity error or receives a Poisoned TLP, but it will not set PCI_STATUS_PARITY, which means it will not assert PERR# (conventional PCI) or report Poisoned TLPs (PCIe). Based-on: https://lore.kernel.org/linux-arm-kernel/d375987c-ea4f-dd98-4ef8-99b2fbfe7c33@gmail.com/ Based-on-patch-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20210330174318.1289680-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c124fd9a |
|
18-Feb-2021 |
Gustavo Pimentel <Gustavo.Pimentel@synopsys.com> |
PCI: Add pci_find_vsec_capability() to find a specific VSEC Add pci_find_vsec_capability() to locate a Vendor-Specific Extended Capability with the specified VSEC ID. The Vendor-Specific Extended Capability (VSEC) allows one or more proprietary capabilities defined by the vendor which aren't standard or shared between vendors. Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/d89506834fb11c6fa0bd5d515c0dd55b13ac6958.1613674948.git.gustavo.pimentel@synopsys.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
4ad0ae8c |
|
29-Apr-2021 |
Nicholas Piggin <npiggin@gmail.com> |
mm/vmalloc: remove unmap_kernel_range This is a shim around vunmap_range, get rid of it. Move the main API comment from the _noflush variant to the normal variant, and make _noflush internal to mm/. [npiggin@gmail.com: fix nommu builds and a comment bug per sfr] Link: https://lkml.kernel.org/r/1617292598.m6g0knx24s.astroid@bobo.none [akpm@linux-foundation.org: move vunmap_range_noflush() stub inside !CONFIG_MMU, not !CONFIG_NUMA] [npiggin@gmail.com: fix nommu builds] Link: https://lkml.kernel.org/r/1617292497.o1uhq5ipxp.astroid@bobo.none Link: https://lkml.kernel.org/r/20210322021806.892164-5-npiggin@gmail.com Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: Cédric Le Goater <clg@kaod.org> Cc: Uladzislau Rezki <urezki@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
4514d991 |
|
16-Mar-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Do not read power state in pci_enable_device_flags() It should not be necessary to update the current_state field of struct pci_dev in pci_enable_device_flags() before calling do_pci_enable_device() for the device, because none of the code between that point and the pci_set_power_state() call in do_pci_enable_device() invoked later depends on it. Moreover, doing that is actively harmful in some cases. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues it is better to leave the current_state value as is until it is changed to PCI_D0 by do_pci_enable_device() as appropriate. However, the power state of the device is not changed to PCI_D0 if it is already enabled when pci_enable_device_flags() gets called for it, so update its current_state in that case, but use pci_update_current_state() covering platform PM too for that. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz <luzmaximilian@gmail.com> Tested-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
f6bda644 |
|
02-Feb-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
PCI: Fix pci_register_io_range() memory leak Kmemleak reports: unreferenced object 0xc328de40 (size 64): comm "kworker/1:1", pid 21, jiffies 4294938212 (age 1484.670s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 d8 fc eb 00 00 00 00 ................ 00 00 10 fe 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ad758d10>] pci_register_io_range+0x3c/0x80 [<2c7f139e>] of_pci_range_to_resource+0x48/0xc0 [<f079ecc8>] devm_of_pci_get_host_bridge_resources.constprop.0+0x2ac/0x3ac [<e999753b>] devm_of_pci_bridge_init+0x60/0x1b8 [<a895b229>] devm_pci_alloc_host_bridge+0x54/0x64 [<e451ddb0>] rcar_pcie_probe+0x2c/0x644 In case a PCI host driver's probe is deferred, the same I/O range may be allocated again, and be ignored, causing a memory leak. Fix this by (a) letting logic_pio_register_range() return -EEXIST if the passed range already exists, so pci_register_io_range() will free it, and by (b) making pci_register_io_range() not consider -EEXIST an error condition. Link: https://lore.kernel.org/r/20210202100332.829047-1-geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
907830b0 |
|
06-Jan-2021 |
Nirmoy Das <nirmoy.das@amd.com> |
PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse RX 5600 XT Pulse advertises support for BAR 0 being 256MB, 512MB, or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar size quirk so that the BAR 0 is big enough to cover complete VARM. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20210107175017.15893-5-nirmoy.das@amd.com
|
#
192f1bf7 |
|
07-Jan-2021 |
Nirmoy Das <nirmoy.das@amd.com> |
PCI: Add pci_rebar_bytes_to_size() Users of pci_resize_resource() need a way to calculate BAR size from desired bytes. Add a helper function and export it so that modular drivers can use it. Signed-off-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20210107175017.15893-3-nirmoy.das@amd.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>
|
#
0af6e21e |
|
19-Nov-2020 |
Alexander Lobakin <alobakin@pm.me> |
PCI: Keep both device and resource name for config space remaps Follow the rule taken in commit 35bd8c07db2c ("devres: keep both device name and resource name in pretty name") and keep both device and resource names while requesting memory regions for PCI config space to prettify e.g. /proc/iomem output: Before (DWC Host Controller): 18b00000-18b01fff : dbi 18b10000-18b11fff : config 18b20000-18b21fff : dbi 18b30000-18b31fff : config After: 18b00000-18b01fff : 18b00000.pci dbi 18b10000-18b11fff : 18b00000.pci config 18b20000-18b21fff : 18b20000.pci dbi 18b30000-18b31fff : 18b20000.pci config Link: https://lore.kernel.org/r/WbKfdybjZ6xNIUjcC5oC8NcuLqrJfkxQAlnO80ag@cp3-web-020.plabs.ch Signed-off-by: Alexander Lobakin <alobakin@pm.me> 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>
|
#
0aec75a5 |
|
08-Dec-2020 |
Heiner Kallweit <hkallweit1@gmail.com> |
PCI: Reduce pci_set_cacheline_size() message to debug level Drivers like ehci_hcd and xhci_hcd use pci_set_mwi() and emit an annnoying message like the following that results in user questions whether something is broken: xhci_hcd 0000:00:15.0: cache line size of 64 is not supported Root cause of the message is that on several chips the Cache Line Size register is hard-wired to 0. Change this message to debug level; an interested caller can still inform the user (if deemed helpful) based on the return code. Link: https://lore.kernel.org/r/be1ed3a2-98b9-ee1d-20b8-477f3d93961d@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9c2cc571 |
|
24-Nov-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Do not generate wakeup event when runtime resuming device When a PCI bridge is runtime resumed from D3cold, we resume any downstream devices as well. Previously, we also generated a wakeup event for each device even though this is not a wakeup signal coming from the hardware. Normally this does not cause problems but when combined with /sys/power/wakeup_count like using the steps below: # count=$(cat /sys/power/wakeup_count) # echo $count > /sys/power/wakeup_count # echo mem > /sys/power/state The system suspend cycle might fail at this point if a PCI bridge that was runtime suspended (D3cold) was runtime resumed for any reason. The runtime resume calls pci_resume_bus(), which generates a wakeup event and increases wakeup_count. Since this is not a real wakeup event, remove the call to pci_wakeup_event() from pci_resume_one(). [bhelgaas: reorder, commit log] Link: https://lore.kernel.org/r/20201125090733.77782-1-mika.westerberg@linux.intel.com Reported-by: Utkarsh Patel <utkarsh.h.patel@intel.com> 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>
|
#
99efde6c |
|
24-Nov-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Rename pci_wakeup_bus() to pci_resume_bus() A "wakeup" is a signal from a device telling the system that the device or the whole system should be awakened and made active. PCI devices are made active by "resuming" them. pci_wakeup_bus() is not involved with the wakeup signal; it *resumes* devices on a bus (possibly in response to a wakeup signal, but that's at a higher level). Rename pci_wakeup_bus() to pci_resume_bus() to better reflect what it does. No functional change intended. [bhelgaas: commit log, reorder before removal of pci_wakeup_event()] Link: https://lore.kernel.org/r/20201125090733.77782-2-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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ee8b1c47 |
|
04-Dec-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Return u16 from pci_find_ext_capability() and similar PCI Express Extended Capabilities are in config space between offsets 256 and 4K. These offsets all fit in 16 bits. Change the return type of pci_find_ext_capability() and supporting functions from int to u16 to match the specification. Many callers use "int", which is fine, but there's no need to store more than a u16. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f646c2a0 |
|
29-Nov-2020 |
Puranjay Mohan <puranjay12@gmail.com> |
PCI: Return u8 from pci_find_capability() and similar PCI Capabilities are linked in a list that must appear in the first 256 bytes of config space. Each capabilities list pointer is 8 bits. Change the return type of pci_find_capability() and supporting functions from int to u8 to match the specification. [bhelgaas: change other related interfaces, fix HyperTransport typos] Link: https://lore.kernel.org/r/20201129164626.12887-1-puranjay12@gmail.com Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
cc73eb32 |
|
14-Nov-2020 |
Colin Ian King <colin.king@canonical.com> |
PCI: Fix overflow in command-line resource alignment requests The shift of 1 by align_order is evaluated using 32 bit arithmetic and the result is assigned to a resource_size_t type variable that is a 64 bit unsigned integer on 64 bit platforms. Fix an overflow before widening issue by making the 1 a ULL. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 32a9a682bef2 ("PCI: allow assignment of memory resources with a specified alignment") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
|
#
6534aac1 |
|
05-Nov-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Bounds-check command-line resource alignment requests 32-bit BARs are limited to 2GB size (2^31). By extension, I assume 64-bit BARs are limited to 2^63 bytes. Limit the alignment requested by the "pci=resource_alignment=" command-line parameter to 2^63. Link: https://lore.kernel.org/r/20201007123045.GS4282@kadam Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2f0cd59c |
|
23-Oct-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
PCI: Fix kernel-doc markup Update kernel-doc so the names in the doc match the prototypes. Link: https://lore.kernel.org/r/f19caf7a68f8365c8b573a42b4ac89ec21925c73.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.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>
|
#
462b58fb |
|
28-Oct-2020 |
Rajat Jain <rajatja@google.com> |
PCI: Always enable ACS even if no ACS Capability Some devices support ACS functionality even though they don't have a spec-compliant ACS Capability; pci_enable_acs() has a quirk mechanism to handle them. We want to enable ACS whenever possible, but 52fbf5bdeeef ("PCI: Cache ACS capability offset in device") inadvertently broke this by calling pci_enable_acs() only if we find an ACS Capability. This resulted in ACS not being enabled for these non-compliant devices, which means devices can't be separated into different IOMMU groups, which in turn means we may not be able to pass those devices through to VMs, as reported by Boris V: https://lore.kernel.org/r/74aeea93-8a46-5f5a-343c-790d4c655da3@bstnet.org Fixes: 52fbf5bdeeef ("PCI: Cache ACS capability offset in device") Link: https://lore.kernel.org/r/20201028231545.4116866-1-rajatja@google.com Reported-by: Boris V <borisvk@bstnet.org> Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
b0e85c3c |
|
28-Sep-2020 |
Jim Quinlan <james.quinlan@broadcom.com> |
PCI: Add Kconfig options for MPS/MRRS strategy Add Kconfig options for changing the default pcie_bus_config, i.e., the strategy for configuration MPS and MRRS, in the same manner as the CONFIG_PCIEASPM_XXXX choice. The pci_bus_config setting may still be overridden by kernel command-line parameters, e.g., "pci=pcie_bus_tune_off". [bhelgaas: depend on EXPERT, tweak help texts] Link: https://lore.kernel.org/r/20200928194651.5393-2-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <james.quinlan@broadcom.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>
|
#
0a98bb98 |
|
25-Sep-2020 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Simplify bool comparisons Take care about Coccinelle warnings: drivers/pci/pci.c:6008:6-12: WARNING: Comparison to bool drivers/pci/pci.c:6024:7-13: WARNING: Comparison to bool No change to functionality intended. Link: https://lore.kernel.org/r/20200925224555.1752460-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.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>
|
#
10791141 |
|
21-Jul-2020 |
Lukas Wunner <lukas@wunner.de> |
PCI: Simplify pci_dev_reset_slot_function() pci_dev_reset_slot_function() refuses to reset a hotplug slot if it is shared by multiple pci_devs. That's the case if and only if the slot is occupied by a multifunction device. Simplify the function to check the device's multifunction flag instead of iterating over the devices on the bus. (Iterating over the devices requires holding pci_bus_sem, which the function erroneously does not acquire.) Link: https://lore.kernel.org/r/c6aab5af096f7b1b3db57f6335cebba8f0fcca89.1595330431.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Alex Williamson <alex.williamson@redhat.com>
|
#
8a614499 |
|
17-Sep-2020 |
Lukas Wunner <lukas@wunner.de> |
PCI: pciehp: Reduce noisiness on hot removal When a PCIe card is hot-removed, the Presence Detect State and Data Link Layer Link Active bits often do not clear simultaneously. I've seen delays of up to 244 msec between the two events with Thunderbolt. After pciehp has brought down the slot in response to the first event, the other bit may still be set. It's not discernible whether it's set because a new card is already in the slot or if it will soon clear. So pciehp tries to bring up the slot and in the latter case fails with a bunch of messages, some of them at KERN_ERR severity. If the slot is no longer occupied, the messages are false positives and annoy users. Stuart Hayes reports the following splat on hot removal: KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Link Up KERN_INFO pcieport 0000:3c:06.0: pciehp: Timeout waiting for Presence Detect KERN_ERR pcieport 0000:3c:06.0: pciehp: link training error: status 0x0001 KERN_ERR pcieport 0000:3c:06.0: pciehp: Failed to check link status Dongdong Liu complains about a similar splat: KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Link Down KERN_INFO iommu: Removing device 0000:87:00.0 from group 12 KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Card present KERN_INFO pcieport 0000:80:10.0: Data Link Layer Link Active not set in 1000 msec KERN_ERR pciehp 0000:80:10.0:pcie004: Failed to check link status Users are particularly irritated to see a bringup attempt even though the slot was explicitly brought down via sysfs. In a perfect world, we could avoid this by setting Link Disable on slot bringdown and re-enabling it upon a Presence Detect State change. In reality however, there are broken hotplug ports which hardwire Presence Detect to zero, see 80696f991424 ("PCI: pciehp: Tolerate Presence Detect hardwired to zero"). Conversely, PCIe r1.0 hotplug ports hardwire Link Active to zero because Link Active Reporting wasn't specified before PCIe r1.1. On unplug, some ports first clear Presence then Link (see Stuart Hayes' splat) whereas others use the inverse order (see Dongdong Liu's splat). To top it off, there are hotplug ports which flap the Presence and Link bits on slot bringup, see 6c35a1ac3da6 ("PCI: pciehp: Tolerate initially unstable link"). pciehp is designed to work with all of these variants. Surplus attempts at slot bringup are a lesser evil than not being able to bring up slots at all. Although we could try to perfect the behavior for specific hotplug controllers, we'd risk breaking others or increasing code complexity. But we can certainly minimize annoyance by emitting only a single message with KERN_INFO severity if bringup is unsuccessful: * Drop the "Timeout waiting for Presence Detect" message in pcie_wait_for_presence(). The sole caller of that function, pciehp_check_link_status(), ignores the timeout and carries on. It emits error messages of its own and I don't think this particular message adds much value. * There's a single error condition in pciehp_check_link_status() which does not emit a message. Adding one allows dropping the "Failed to check link status" message emitted by board_added() if pciehp_check_link_status() returns a non-zero integer. * Tone down all messages in pciehp_check_link_status() to KERN_INFO severity and rephrase them to look as innocuous as possible. To this end, move the message emitted by pcie_wait_for_link_delay() to its callers. As a result, Stuart Hayes' splat becomes: KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Link Up KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Cannot train link: status 0x0001 Dongdong Liu's splat becomes: KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Card present KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): No link The messages now merely serve as information that presence or link bits were set a little longer than expected. Bringup failures which are not false positives are still reported, albeit no longer at KERN_ERR severity. Link: https://lore.kernel.org/linux-pci/20200310182100.102987-1-stuart.w.hayes@gmail.com/ Link: https://lore.kernel.org/linux-pci/1547649064-19019-1-git-send-email-liudongdong3@huawei.com/ Link: https://lore.kernel.org/r/b45e46fd8a6aa6930aaac9d7718c2e4b787a4e5e.1595935071.git.lukas@wunner.de Reported-by: Stuart Hayes <stuart.w.hayes@gmail.com> Reported-by: Dongdong Liu <liudongdong3@huawei.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>
|
#
76fc8e85 |
|
07-Jul-2020 |
Rajat Jain <rajatja@google.com> |
PCI/ACS: Enable Translation Blocking for external devices Translation Blocking is a required feature for Downstream Ports (Root Ports or Switch Downstream Ports) that implement ACS. When enabled, the Port checks the Address Type (AT) of each upstream Memory Request it receives. The default AT (00b) means "untranslated" and the IOMMU can decide whether to treat the address as I/O virtual or physical. If AT is not the default, i.e., if the Memory Request contains an already-translated (physical) address, the Port blocks the request and reports an ACS error. When enabling ACS, enable Translation Blocking for external-facing ports and untrusted (external) devices. This is to help prevent attacks from external devices that initiate DMA with physical addresses that bypass the IOMMU. [bhelgaas: commit log, simplify setting bit and drop warning; TB is required for Downstream Ports with ACS, so we should never see the warning] Link: https://lore.kernel.org/r/20200707224604.3737893-4-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
e7a7499d |
|
24-Aug-2020 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Use scnprintf(), not snprintf(), in sysfs "show" functions Sysfs "show" methods should return the number of bytes printed into the buffer. This is the return value of scnprintf() [1]. snprintf(buf, size, ...) prints at most "size" bytes into "buf", but returns the number of bytes that *would* be printed if "buf" were large enough. Replace use of snprintf() with scnprintf(). No functional change intended. Related: https://patchwork.kernel.org/patch/9946759/#20969333 https://lwn.net/Articles/69419 [1] Documentation/filesystems/sysfs.rst [bhelgaas: squashed, commit log] Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20200824233918.26306-2-kw@linux.com Link: https://lore.kernel.org/r/20200824233918.26306-3-kw@linux.com Link: https://lore.kernel.org/r/20200824233918.26306-4-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
00da4805 |
|
13-Aug-2020 |
Gustavo Pimentel <Gustavo.Pimentel@synopsys.com> |
PCI: Remove unnecessary header includes Remove unnecessary includes of: linux/of_pci.h linux/pci-ats.h asm/setup.h CoverityScan CID 16442, 16443, 16444 ("Unnecessary header file (HFA)") Link: https://lore.kernel.org/r/eba4c0f2b35b1442773a722f1cf73f7240f818e3.1597325845.git.gustavo.pimentel@synopsys.com Link: https://lore.kernel.org/r/72ade1f5af35b994a7a8216ea5dc32c27cf134cd.1597325845.git.gustavo.pimentel@synopsys.com Link: https://lore.kernel.org/r/715821dc855add2565505ff8dcb9970e87996c5c.1597325845.git.gustavo.pimentel@synopsys.com [bhelgaas: squash] Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Joao Pinto <jpinto@synopsys.com>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
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>
|
#
d08c30d7 |
|
17-Jul-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI/PM: Assume ports without DLL Link Active train links in 100 ms" This reverts commit ec411e02b7a2e785a4ed9ed283207cd14f48699d. Patrick reported that this commit broke hybrid graphics on a ThinkPad X1 Extreme 2nd with Intel UHD Graphics 630 and NVIDIA GeForce GTX 1650 Mobile: nouveau 0000:01:00.0: fifo: PBDMA0: 01000000 [] ch 0 [00ff992000 DRM] subc 0 mthd 0008 data 00000000 Karol reported that this commit broke Nouveau firmware loading on a Lenovo P1G2 with Intel UHD Graphics 630 and NVIDIA TU117GLM [Quadro T1000 Mobile]: nouveau 0000:01:00.0: acr: AHESASC binary failed In both cases, reverting ec411e02b7a2 solved the problem. Unfortunately, this revert will reintroduce the "Thunderbolt bridges take long time to resume from D3cold" problem: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/CAErSpo5sTeK_my1dEhWp7aHD0xOp87+oHYWkTjbL7ALgDbXo-Q@mail.gmail.com Link: https://lore.kernel.org/r/CACO55tsAEa5GXw5oeJPG=mcn+qxNvspXreJYWDJGZBy5v82JDA@mail.gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=208597 Reported-by: Patrick Volkerding <volkerdi@gmail.com> Reported-by: Karol Herbst <kherbst@redhat.com> Fixes: ec411e02b7a2 ("PCI/PM: Assume ports without DLL Link Active train links in 100 ms") 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>
|
#
cbe42036 |
|
07-Jul-2020 |
Rajat Jain <rajatja@google.com> |
PCI: Reorder pci_enable_acs() and dependencies Move pci_enable_acs() and dependencies further up in the source code to avoid having to forward declare it when we make it static in near future. No functional changes intended. Link: https://lore.kernel.org/r/20200707224604.3737893-1-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d20df83b |
|
15-Jun-2020 |
Bolarinwa Olayemi Saheed <refactormyself@gmail.com> |
PCI: Convert PCIe capability PCIBIOS errors to errno The PCI config accessors (pci_read_config_word(), et al) return PCIBIOS_SUCCESSFUL (zero) or positive error values like PCIBIOS_FUNC_NOT_SUPPORTED. The PCIe capability accessors (pcie_capability_read_word(), et al) similarly return PCIBIOS errors, but some callers assume they return generic errno values like -EINVAL. For example, the Myri-10G probe function returns a positive PCIBIOS error if the pcie_capability_clear_and_set_word() in pcie_set_readrq() fails: myri10ge_probe status = pcie_set_readrq return pcie_capability_clear_and_set_word if (status) return status A positive return from a PCI driver probe function would cause a "Driver probe function unexpectedly returned" warning from local_pci_probe() instead of the desired probe failure. Convert PCIBIOS errors to generic errno for all callers of: pcie_capability_read_word pcie_capability_read_dword pcie_capability_write_word pcie_capability_write_dword pcie_capability_set_word pcie_capability_set_dword pcie_capability_clear_word pcie_capability_clear_dword pcie_capability_clear_and_set_word pcie_capability_clear_and_set_dword that check the return code for anything other than zero. [bhelgaas: commit log, squash together] Suggested-by: Bjorn Helgaas <bjorn@helgaas.com> Link: https://lore.kernel.org/r/20200615073225.24061-1-refactormyself@gmail.com Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ec411e02 |
|
14-May-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Assume ports without DLL Link Active train links in 100 ms Kai-Heng Feng reported that it takes a long time (> 1 s) to resume Thunderbolt-connected devices from both runtime suspend and system sleep (s2idle). This was because some Downstream Ports that support > 5 GT/s do not also support Data Link Layer Link Active reporting. Per PCIe r5.0 sec 6.6.1: 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). Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not. Previously we tried to wait for Link training to complete, but since there was no DLL Link Active reporting, all we could do was wait the worst-case 1000 ms, then another 100 ms. Instead of using the supported speeds to determine whether to wait for Link training, check whether the port supports DLL Link Active reporting. The Ports in question do not, so we'll wait only the 100 ms required for Ports that support Link speeds <= 5 GT/s. This of course assumes these Ports always train the Link within 100 ms even if they are operating at > 5 GT/s, which is not required by the spec. [bhelgaas: commit log, comment] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/20200514133043.27429-1-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>
|
#
f044baaf |
|
15-May-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Adjust pcie_wait_for_link_delay() for caller delay The caller of pcie_wait_for_link_delay() specifies the time to wait after the link becomes active. When the downstream port doesn't support link active reporting, obviously we can't tell when the link becomes active, so we waited the worst-case time (1000 ms) plus 100 ms, ignoring the delay from the caller. Instead, wait for 1000 ms + the delay from the caller. Fixes: 4827d63891b6 ("PCI/PM: Add pcie_wait_for_link_delay()") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6ae72bfa |
|
09-May-2020 |
Yicong Yang <yangyicong@hisilicon.com> |
PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port() Previously we used pcie_find_root_port() to find a Root Port from a PCIe device and pci_find_pcie_root_port() to find a Root Port from a Conventional PCI device. Unify the two functions and use pcie_find_root_port() to find a Root Port from either a Conventional PCI device or a PCIe device. Then there is no need to distinguish the type of the device. Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # thunderbolt
|
#
914a1951 |
|
07-May-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
PCI: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these as a flexible array member [1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that dynamic memory allocations won't be affected by this change: Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero. [1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type [1]. There are some instances of code in which the sizeof() operator is being incorrectly/erroneously applied to zero-length arrays, and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507190544.GA15633@embeddedor Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c3aaf086 |
|
07-Apr-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Call .bridge_d3() hook only if non-NULL 26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") added the struct pci_platform_pm_ops.bridge_d3() function pointer and platform_pci_bridge_d3() to use it. The .bridge_d3() op is implemented by acpi_pci_platform_pm, but not by mid_pci_platform_pm. We don't expect platform_pci_bridge_d3() to be called on Intel MID platforms, but nothing in the code itself would prevent that. Check the .bridge_d3() pointer for NULL before calling it. Fixes: 26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.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>
|
#
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>
|
#
70c0923b |
|
02-Mar-2020 |
Jacob Keller <jacob.e.keller@intel.com> |
PCI: Introduce pci_get_dsn Several device drivers read their Device Serial Number from the PCIe extended config space. Introduce a new helper function, pci_get_dsn(). This function reads the eight bytes of the DSN and returns them as a u64. If the capability does not exist for the device, the function returns 0. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Michael Chan <michael.chan@broadcom.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ec5d9e87 |
|
29-Feb-2020 |
Heiner Kallweit <hkallweit1@gmail.com> |
PCI: Add pci_status_get_and_clear_errors Several drivers use the following code sequence: 1. Read PCI_STATUS 2. Mask out non-error bits 3. Action based on error bits set 4. Write back set error bits to clear them As this is a repeated pattern, add a helper to the PCI core. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2856ba60 |
|
21-Jan-2020 |
Jon Derrick <jonathan.derrick@intel.com> |
PCI: Introduce pci_real_dma_dev() The current DMA alias implementation requires the aliased device be on the same PCI bus as the requester ID. Add an arch-specific mechanism to point to another PCI device when doing mapping and PCI DMA alias search. The default case returns the actual device. Link: https://lore.kernel.org/r/1579613871-301529-4-git-send-email-jonathan.derrick@intel.com Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Christoph Hellwig <hch@lst.de>
|
#
47b802d5 |
|
12-Jan-2020 |
Chen Yu <yu.c.chen@intel.com> |
PCI/PM: Print config space of devices before suspend When resuming from hibernation (S4, also known as "suspend to disk") on a VM, we have seen invalid config space, e.g., serial 0000:00:16.3: restoring config space at offset 0x14 (was 0x9104e000, writing 0xffffffff) To help debug problems like this, log the config space being saved before suspend, similar to the log in pci_restore_config_dword() when resuming. Link: https://lore.kernel.org/r/20200113060724.19571-1-yu.c.chen@intel.com [bhelgaas: commit log] Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Len Brown <lenb@kernel.org>
|
#
4bdc0d67 |
|
06-Jan-2020 |
Christoph Hellwig <hch@lst.de> |
remove ioremap_nocache and devm_ioremap_nocache ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
|
#
1a373a78 |
|
18-Dec-2019 |
Will Deacon <will@kernel.org> |
PCI: Export pci_ats_disabled() as a GPL symbol to modules Building drivers for ATS-aware IOMMUs as modules requires access to pci_ats_disabled(). Export it as a GPL symbol to get things working. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
09298542 |
|
10-Dec-2019 |
James Sewart <jamessewart@arista.com> |
PCI: Add nr_devfns parameter to pci_add_dma_alias() Add a "nr_devfns" parameter to pci_add_dma_alias() so it can be used to create DMA aliases for a range of devfns. [bhelgaas: incorporate nr_devfns fix from James, update quirk_pex_vca_alias() and setup_aliases()] Signed-off-by: James Sewart <jamessewart@arista.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>
|
#
bbd8810d |
|
03-Sep-2019 |
Krzysztof Wilczynski <kw@linux.com> |
PCI: Remove unused includes and superfluous struct declaration Remove <linux/pci.h> and <linux/msi.h> from being included directly as part of the include/linux/of_pci.h, and remove superfluous declaration of struct of_phandle_args. Move users of include <linux/of_pci.h> to include <linux/pci.h> and <linux/msi.h> directly rather than rely on both being included transitively through <linux/of_pci.h>. Link: https://lore.kernel.org/r/20190903113059.2901-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
|
#
bae26849 |
|
19-Nov-2019 |
Vidya Sagar <vidyas@nvidia.com> |
PCI/PM: Move pci_dev_wait() definition earlier Move the definition of pci_dev_wait() above pci_power_up() so that it can be called from the latter with no change in functionality. This is a pure code move with no functional change. Link: https://lore.kernel.org/r/20191120051743.23124-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.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>
|
#
4827d638 |
|
11-Nov-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI/PM: Add pcie_wait_for_link_delay() Add pcie_wait_for_link_delay(). Similar to pcie_wait_for_link() but allows passing custom activation delay in milliseconds. Link: https://lore.kernel.org/r/20191112091617.70282-2-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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
327ccbbc |
|
01-Aug-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Return error when changing power state from D3cold pci_raw_set_power_state() uses the Power Management capability to change a device's power state. The capability is in config space, which is accessible in D0, D1, D2, and D3hot, but not in D3cold. If we call pci_raw_set_power_state() on a device that's in D3cold, config reads fail and return ~0 data, which we erroneously interpreted as "the device is in D3hot", leading to messages like this: pcieport 0000:03:00.0: Refused to change power state, currently in D3 The PCI_PM_CTRL has several RsvdP fields, so ~0 is never a valid register value. If we get that value, print a more informative message and return an error. Changing the power state of a device from D3cold must be done by a platform power management method or some other non-config space mechanism. Link: https://lore.kernel.org/r/20190822200551.129039-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
e43f15ea |
|
02-Aug-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Decode D3cold power state correctly Use pci_power_name() to print pci_power_t correctly. This changes: "state 0" or "D0" to "D0" "state 1" or "D1" to "D1" "state 2" or "D2" to "D2" "state 3" or "D3" to "D3hot" "state 4" or "D4" to "D3cold" Changes dmesg logging only, no other functional change intended. Link: https://lore.kernel.org/r/20190822200551.129039-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
9c77e63b |
|
05-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Fold __pci_complete_power_transition() into its caller Because pci_set_power_state() has become the only caller of __pci_complete_power_transition(), there is no need for the latter to be a separate function any more, so fold it into the former, drop a redundant check and reduce the number of lines of code somewhat. Code rearrangement, no intentional functional impact. Link: https://lore.kernel.org/r/15576968.k611qn3UU0@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>
|
#
d6aa37cd |
|
05-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Avoid exporting __pci_complete_power_transition() Notice that radeon_set_suspend(), which is the only caller of __pci_complete_power_transition() outside of pci.c, really only cares about the pci_platform_power_transition() invoked by it, so export the latter instead of it, update the radeon driver to call pci_platform_power_transition() directly and make __pci_complete_power_transition() static. Code rearrangement, no intentional functional impact. Link: https://lore.kernel.org/r/1731661.ykamz2Tiuf@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>
|
#
dc2256b0 |
|
05-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Fold __pci_start_power_transition() into its caller Because pci_power_up() has become the only caller of __pci_start_power_transition(), there is no need for the latter to be a separate function any more, so fold it into the former, drop a redundant check and reduce the number of lines of code somewhat. Code rearrangement, no intentional functional impact. Link: https://lore.kernel.org/r/3458080.lsoDbfkST9@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>
|
#
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>
|
#
81cfa590 |
|
05-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Move power state update away from pci_power_up() Move the invocation of pci_update_current_state() from pci_power_up() to pci_pm_default_resume_early(), which is the only caller of that function. Preparatory change, no functional impact. Link: https://lore.kernel.org/r/37482337.udjOGdOKNb@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>
|
#
baef7f8e |
|
16-Oct-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Simplify pci_set_power_state() Check for the PCI_DEV_FLAGS_NO_D3 quirk early, before calling __pci_start_power_transition(). This way all the cases where we don't need to do anything at all are checked up front. This doesn't fix anything because if the caller requested D3hot or D3cold, __pci_start_power_transition() is a no-op. But calling it is pointless and makes the code harder to analyze. Link: https://lore.kernel.org/r/20191101204558.210235-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
993cc6d1 |
|
28-Oct-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Expand PM reset messages to mention D3hot (not just D3) pci_pm_reset() resets a device by putting it in D3hot and bringing it back to D0. Clarify related messages to mention "D3hot" explicitly instead of just "D3". Link: https://lore.kernel.org/r/20191101204558.210235-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7e24bc34 |
|
23-Oct-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PM: Apply D2 delay as milliseconds, not microseconds PCI_PM_D2_DELAY is defined as 200, which is milliseconds, but previously we used udelay(), which only waited for 200 microseconds. Use msleep() instead so we wait the correct amount of time. See PCIe r5.0, sec 5.9. Link: https://lore.kernel.org/r/20191101204558.210235-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
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>
|
#
52525b7a |
|
18-Oct-2019 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
PCI: Add a helper to check Power Resource Requirements _PR3 existence A driver may want to know the existence of _PR3, to choose different runtime suspend behavior. A user will be add in next patch. This is mostly the same as nouveau_pr3_present(). Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20191018073848.14590-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
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>
|
#
45144d42 |
|
14-Oct-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Fix pci_power_up() There is an arbitrary difference between the system resume and runtime resume code paths for PCI devices regarding the delay to apply when switching the devices from D3cold to D0. Namely, pci_restore_standard_config() used in the runtime resume code path calls pci_set_power_state() which in turn invokes __pci_start_power_transition() to power up the device through the platform firmware and that function applies the transition delay (as per PCI Express Base Specification Revision 2.0, Section 6.6.1). However, pci_pm_default_resume_early() used in the system resume code path calls pci_power_up() which doesn't apply the delay at all and that causes issues to occur during resume from suspend-to-idle on some systems where the delay is required. Since there is no reason for that difference to exist, modify pci_power_up() to follow pci_set_power_state() more closely and invoke __pci_start_power_transition() from there to call the platform firmware to power up the device (in case that's necessary). Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Reported-by: Daniel Drake <drake@endlessm.com> Tested-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
|
#
c9c13ba4 |
|
27-Sep-2019 |
Denis Efremov <efremov@linux.com> |
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
|
#
ca784104 |
|
22-Aug-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Get rid of dev->has_secondary_link flag In some systems, the Device/Port Type in the PCI Express Capabilities register incorrectly identifies upstream ports as downstream ports. d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links") addressed this by adding pci_dev.has_secondary_link, which is set for downstream ports. But this is confusing because pci_pcie_type() sometimes gives the wrong answer, and it's not obvious that we should use pci_dev.has_secondary_link instead. Reduce the confusion by correcting the type of the port itself so that pci_pcie_type() returns the actual type regardless of what the Device/Port Type register claims it is. Update the users to call pci_pcie_type() and pcie_downstream_port() accordingly, and remove pci_dev.has_secondary_link completely. Link: https://lore.kernel.org/linux-pci/20190703133953.GK128603@google.com/ Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20190822085553.62697-2-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>
|
#
e499081d |
|
22-Aug-2019 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Force trailing new line to resource_alignment_param in sysfs When 'pci=resource_alignment=' is specified on the command line, there is no trailing new line. Then, when it's read through the corresponding sysfs attribute, there will be no newline and a cat command will not show correctly in a shell. If the parameter is set through sysfs a new line will be stored and it will 'cat' correctly. To solve this, append a new line character in the show function if one does not already exist. Link: https://lore.kernel.org/r/20190822161013.5481-4-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
273b177c |
|
22-Aug-2019 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Move pci_[get|set]_resource_alignment_param() into their callers Both the functions pci_get_resource_alignment_param() and pci_set_resource_alignment_param() are now only called in one place: resource_alignment_show() and resource_alignment_store() respectively. There is no value in this extra set of functions so move both into their callers respectively. [bhelgaas: fold in "GFP_KERNEL while atomic" fix from Christoph Hellwig <hch@infradead.org> https://lore.kernel.org/r/20190902075006.GB754@infradead.org] Link: https://lore.kernel.org/r/20190822161013.5481-3-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
70aaf61a |
|
22-Aug-2019 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Clean up resource_alignment parameter to not require static buffer Clean up the 'resource_alignment' parameter code to use kstrdup() in the initcall routine instead of a static buffer that wastes memory regardless of whether the feature is used. This allows us to drop 'COMMAND_LINE_SIZE' bytes (typically 256-4096 depending on architecture) of static data. This is similar to what has been done for the 'disable_acs_redir' parameter. Link: https://lore.kernel.org/r/20190822161013.5481-2-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7f1c62c4 |
|
25-Aug-2019 |
Krzysztof Wilczynski <kw@linux.com> |
PCI: Add pci_info_ratelimited() to ratelimit PCI separately Do not use printk_ratelimit() in drivers/pci/pci.c as it shares the rate limiting state with all other callers to the printk_ratelimit(). Add pci_info_ratelimited() (similar to pci_notice_ratelimited() added in the commit a88a7b3eb076 ("vfio: Use dev_printk() when possible")) and use it instead of printk_ratelimit() + pci_info(). Link: https://lore.kernel.org/r/20190825224616.8021-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d2182b2d |
|
25-Jul-2019 |
Sumit Saxena <sumit.saxena@broadcom.com> |
PCI: Restore Resizable BAR size bits correctly for 1MB BARs In a Resizable BAR Control Register, bits 13:8 control the size of the BAR. The encoded values of these bits are as follows (see PCIe r5.0, sec 7.8.6.3): Value BAR size 0 1 MB (2^20 bytes) 1 2 MB (2^21 bytes) 2 4 MB (2^22 bytes) ... 43 8 EB (2^63 bytes) Previously we incorrectly set the BAR size bits for a 1 MB BAR to 0x1f instead of 0, so devices that support that size, e.g., new megaraid_sas and mpt3sas adapters, fail to initialize during resume from S3 sleep. Correctly calculate the BAR size bits for Resizable BAR control registers. Link: https://lore.kernel.org/r/20190725192552.24295-1-sumit.saxena@broadcom.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939 Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume") Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org # v4.19+
|
#
b8074aa2 |
|
29-Jul-2019 |
Denis Efremov <efremov@linux.com> |
PCI: Convert pci_resource_to_user() to a weak function Convert pci_resource_to_user() to a weak function so the existing architecture-specific implementations will automatically override the generic one. This allows us to remove HAVE_ARCH_PCI_RESOURCE_TO_USER definitions and avoid the conditional compilation for this single function. Link: https://lore.kernel.org/r/20190729101401.28068-1-efremov@linux.com Link: https://lore.kernel.org/r/20190729101401.28068-2-efremov@linux.com Link: https://lore.kernel.org/r/20190729101401.28068-3-efremov@linux.com Link: https://lore.kernel.org/r/20190729101401.28068-4-efremov@linux.com Link: https://lore.kernel.org/r/20190729101401.28068-5-efremov@linux.com Link: https://lore.kernel.org/r/20190729101401.28068-6-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> [bhelgaas: squash into one commit] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Paul Burton <paul.burton@mips.com> # MIPS
|
#
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>
|
#
f6b6aefe |
|
30-May-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix typos and whitespace errors Fix typos in drivers/pci. Comment and whitespace changes only. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
|
#
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>
|
#
000dd531 |
|
12-Jun-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Do not poll for PME if the device is in D3cold PME polling does not take into account that a device that is directly connected to the host bridge may go into D3cold as well. This leads to a situation where the PME poll thread reads from a config space of a device that is in D3cold and gets incorrect information because the config space is not accessible. Here is an example from Intel Ice Lake system where two PCIe root ports are in D3cold (I've instrumented the kernel to log the PMCSR register contents): [ 62.971442] pcieport 0000:00:07.1: Check PME status, PMCSR=0xffff [ 62.971504] pcieport 0000:00:07.0: Check PME status, PMCSR=0xffff Since 0xffff is interpreted so that PME is pending, the root ports will be runtime resumed. This repeats over and over again essentially blocking all runtime power management. Prevent this from happening by checking whether the device is in D3cold before its PME status is read. Fixes: 71a83bd727cc ("PCI/PM: add runtime PM support to PCIe port") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Cc: 3.6+ <stable@vger.kernel.org> # v3.6+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@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>
|
#
234f223d |
|
06-Jun-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: PM: Avoid resuming devices in D3hot during system suspend The current code resumes devices in D3hot during system suspend if the target power state for them is D3cold, but that is not necessary in general. It only is necessary to do that if the platform firmware requires the device to be resumed, but that should be covered by the platform_pci_need_resume() check anyway, so rework pci_dev_keep_suspended() to avoid returning 'false' for devices in D3hot which need not be resumed due to platform firmware requirements. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
de76cda2 |
|
04-Jun-2019 |
Gustavo Pimentel <Gustavo.Pimentel@synopsys.com> |
PCI: Decode PCIe 32 GT/s link speed PCIe r5.0, sec 7.5.3.18, defines a new 32.0 GT/s bit in the Supported Link Speeds Vector of Link Capabilities 2. Decode this new speed. This 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. Previously, reading the speed of a link operating at this speed showed "Unknown speed" instead of "32.0 GT/s". Link: https://lore.kernel.org/lkml/92365e3caf0fc559f9ab14bcd053bfc92d4f661c.1559664969.git.gustavo.pimentel@synopsys.com Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
34c6b710 |
|
19-Apr-2019 |
Mohan Kumar <mohankumar718@gmail.com> |
PCI: Replace dev_printk(KERN_DEBUG) with dev_info(), etc Replace dev_printk(KERN_DEBUG) with dev_info(), etc to be more consistent with other logging and avoid checkpatch warnings. The KERN_DEBUG messages could be converted to dev_dbg(), but that depends on CONFIG_DYNAMIC_DEBUG and DEBUG, and we want most of these messages to *always* be in the dmesg log. Link: https://lore.kernel.org/lkml/1555733240-19875-1-git-send-email-mohankumar718@gmail.com Signed-off-by: Mohan Kumar <mohankumar718@gmail.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
25da8dba |
|
19-Apr-2019 |
Mohan Kumar <mohankumar718@gmail.com> |
PCI: Replace printk(KERN_INFO) with pr_info(), etc Replace printk() with pr_*() to be more consistent with other logging and avoid checkpatch warnings. Link: https://lore.kernel.org/lkml/1555733026-19609-1-git-send-email-mohankumar718@gmail.com Link: https://lore.kernel.org/lkml/1555733130-19804-1-git-send-email-mohankumar718@gmail.com Signed-off-by: Mohan Kumar <mohankumar718@gmail.com> [bhelgaas: squash in similar changes from second patch in series] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
804ee5be |
|
17-Apr-2019 |
Johannes Thumshirn <jthumshirn@suse.de> |
PCI: Remove unused pci_request_region_exclusive() pci_request_region_exclusive() was introduced with commit e8de1481fd71 ("resource: allow MMIO exclusivity for device drivers") in 2.6.29 which was released 2008. It never had an in tree user since then, so after 11 years later let's remove it. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
74356add |
|
09-Jan-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix comment typos Fix spelling errors and format function comments consistently. Changes whitespace and comments only; no functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
|
#
d5bc73f3 |
|
10-Apr-2019 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Fix issue with "pci=disable_acs_redir" parameter being ignored In most cases, kmalloc() will not be available early in boot when pci_setup() is called. Thus, the kstrdup() call that was added to fix the __initdata bug with the disable_acs_redir parameter usually returns NULL, so the parameter is discarded and has no effect. To fix this, store the string that's in initdata until an initcall function can allocate the memory appropriately. This way we don't need any additional static memory. Fixes: d2fd6e81912a ("PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ddefc033 |
|
18-Feb-2019 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Fix "try" semantics of bus and slot reset The commit referenced below introduced device locking around save and restore of state for each device during a PCI bus "try" reset, making it decidely non-"try" and prone to deadlock in the event that a device is already locked. Restore __pci_reset_bus() and __pci_reset_slot() to their advertised locking semantics by pushing the save and restore functions into the branch where the entire tree is already locked. Extend the helper function names with "_locked" and update the comment to reflect this calling requirement. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
|
#
dbbfadf2 |
|
09-Jan-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/ASPM: Save LTR Capability for suspend/resume Latency Tolerance Reporting (LTR) allows Endpoints and Switch Upstream Ports to report their latency requirements to upstream components. If ASPM L1 PM substates are enabled, the LTR information helps determine when a Link enters L1.2 [1]. Software must set the maximum latency values in the LTR Capability based on characteristics of the platform, then set LTR Mechanism Enable in the Device Control 2 register in the PCIe Capability. The device can then use LTR to report its latency tolerance. If the device reports a maximum latency value of zero, that means the device requires the highest possible performance and the ASPM L1.2 substate is effectively disabled. We put devices in D3 for suspend, and we assume their internal state is lost. On resume, previously we did not restore the LTR Capability, but we did restore the LTR Mechanism Enable bit, so devices would request the highest possible performance and ASPM L1.2 wouldn't be used. [1] PCIe r4.0, sec 5.5.1 Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
85b0cae8 |
|
31-Jan-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports Gigabyte X299 DESIGNARE EX motherboard has one PCIe root port that is connected to an Alpine Ridge Thunderbolt controller. This port has slot implemented bit set in the config space but other than that it is not hotplug capable in the sense we are expecting in Linux (it has dev->is_hotplug_bridge set to 0): 00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 Bus: primary=00, secondary=05, subordinate=46, sec-latency=0 Memory behind bridge: 78000000-8fffffff [size=384M] Prefetchable memory behind bridge: 00003800f8000000-00003800ffffffff [size=128M] ... Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 ... SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #8, PowerLimit 25.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet+ LinkState+ This system is using ACPI based hotplug to notify the OS that it needs to rescan the PCI bus (ACPI hotplug). If there is nothing connected in any of the Thunderbolt ports the root port will not have any runtime PM active children and is thus automatically runtime suspended pretty soon after boot by PCI PM core. Now, when a device is connected the BIOS SMI handler responsible for enumerating newly added devices is not able to find anything because the port is in D3. Prevent this from happening by blacklisting PCI power management of this particular Gigabyte system. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202031 Reported-by: Kedar A Dongre <kedar.a.dongre@intel.com> 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>
|
#
b2fb5cc5 |
|
16-Oct-2018 |
Honghui Zhang <honghui.zhang@mediatek.com> |
PCI: Rely on config space header type, not class code The PCI configuration space header type tells us whether the device is a bridge, a CardBus bridge, or a normal device, and defines the layout of the rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9). When we rely on the header format, e.g., when we're dealing with bridge windows, we should check the header type, not the class code. The class code is loosely related to the header type, but is often incorrect and the spec doesn't actually require it to be related to the header format. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com> [bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d61dfafc |
|
21-Dec-2018 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
PCI: pci.c: convert to use BUS_ATTR_RW We are trying to get rid of BUS_ATTR() and the usage of that in pci.c can be trivially converted to use BUS_ATTR_RW(), so use that instead. Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d2fd6e81 |
|
17-Jan-2019 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter The disable_acs_redir parameter stores a pointer to the string passed to pci_setup(). However, the string passed to PCI setup is actually a temporary copy allocated in static __initdata memory. After init, once the memory is freed, it is no longer valid to reference this pointer. This bug was noticed in v5.0-rc1 after a change in commit c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions") caused pci_disable_acs_redir() to be called during shutdown which manifested as an unable to handle kernel paging request at: RIP: 0010:pci_enable_acs+0x3f/0x1e0 Call Trace: pci_restore_state.part.44+0x159/0x3c0 pci_restore_standard_config+0x33/0x40 pci_pm_runtime_resume+0x2b/0xd0 ? pci_restore_standard_config+0x40/0x40 __rpm_callback+0xbc/0x1b0 rpm_callback+0x1f/0x70 ? pci_restore_standard_config+0x40/0x40 rpm_resume+0x4f9/0x710 ? pci_conf1_read+0xb6/0xf0 ? pci_conf1_write+0xb2/0xe0 __pm_runtime_resume+0x47/0x70 pci_device_shutdown+0x1e/0x60 device_shutdown+0x14a/0x1f0 kernel_restart+0xe/0x50 __do_sys_reboot+0x1ee/0x210 ? __fput+0x144/0x1d0 do_writev+0x5e/0xf0 ? do_writev+0x5e/0xf0 do_syscall_64+0x48/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It was also likely possible to trigger this bug when hotplugging PCI devices. To fix this, instead of storing a pointer, we use kstrdup() to copy the disable_acs_redir_param to its own buffer which will never be freed. Fixes: aaca43fda742 ("PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support") Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
|
#
1d09d577 |
|
14-Jan-2019 |
Mathieu Malaterre <malat@debian.org> |
PCI: Mark expected switch fall-through There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. Signed-off-by: Mathieu Malaterre <malat@debian.org> [bhelgaas: squash into one patch, drop extra changelog detail] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f1f90e25 |
|
26-Nov-2018 |
Mikulas Patocka <mpatocka@redhat.com> |
PCI: Fix incorrect value returned from pcie_get_speed_cap() The macros PCI_EXP_LNKCAP_SLS_*GB are values, not bit masks. We must mask the register and compare it against them. This fixes errors like this: amdgpu: [powerplay] failed to send message 261 ret is 0 when a PCIe-v3 card is plugged into a PCIe-v1 slot, because the slot is being incorrectly reported as PCIe-v3 capable. 6cf57be0f78e, which appeared in v4.17, added pcie_get_speed_cap() with the incorrect test of PCI_EXP_LNKCAP_SLS as a bitmask. 5d9a63304032, which appeared in v4.19, changed amdgpu to use pcie_get_speed_cap(), so the amdgpu bug reports below are regressions in v4.19. Fixes: 6cf57be0f78e ("PCI: Add pcie_get_speed_cap() to find max supported link speed") Fixes: 5d9a63304032 ("drm/amdgpu: use pcie functions for link width and speed") Link: https://bugs.freedesktop.org/show_bug.cgi?id=108704 Link: https://bugs.freedesktop.org/show_bug.cgi?id=108778 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> [bhelgaas: update comment, remove use of PCI_EXP_LNKCAP_SLS_8_0GB and PCI_EXP_LNKCAP_SLS_16_0GB since those should be covered by PCI_EXP_LNKCAP2, remove test of PCI_EXP_LNKCAP for zero, since that register is required] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # v4.17+
|
#
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>
|
#
ac86e8ee |
|
27-Sep-2018 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Do not skip power-managed bridges in pci_enable_wake() Commit baecc470d5fd ("PCI / PM: Skip bridges in pci_enable_wake()") changed pci_enable_wake() so that all bridges are skipped when wakeup is enabled (or disabled) with the reasoning that bridges can only signal wakeup on behalf of their subordinate devices. However, there are bridges that can signal wakeup themselves. For example PCIe downstream and root ports supporting hotplug may signal wakeup upon hotplug event. For this reason change pci_enable_wake() so that it skips all bridges except those that we power manage (->bridge_d3 is set). Those are the ones that can go into low power states and may need to signal wakeup. 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>
|
#
f0157160 |
|
20-Sep-2018 |
Keith Busch <kbusch@kernel.org> |
PCI: Make link active reporting detection generic The spec has timing requirements when waiting for a link to become active after a conventional reset. Implement those hard delays when waiting for an active link so pciehp and dpc drivers don't need to duplicate this. For devices that don't support data link layer active reporting, wait the fixed time recommended by the PCIe spec. Signed-off-by: Keith Busch <keith.busch@intel.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
|
#
d6112f8d |
|
07-Sep-2018 |
Felipe Balbi <felipe.balbi@linux.intel.com> |
PCI: Add support for Immediate Readiness PCIe r4.0, sec 7.5.1.1.4 defines a new bit in the Status Register: Immediate Readiness – This optional bit, when Set, indicates the Function is guaranteed to be ready to successfully complete valid configuration accesses at any time following any reset that the host is capable of issuing Configuration Requests to this Function. When this bit is Set, for accesses to this Function, software is exempt from all requirements to delay configuration accesses following any type of reset, including but not limited to the timing requirements defined in Section 6.6. This means that all delays after a Conventional or Function Reset can be skipped. This patch reads such bit and caches its value in a flag inside struct pci_dev to be checked later if we should delay or can skip delays after a reset. While at that, also move the explicit msleep(100) call from pcie_flr() and pci_af_flr() to pci_dev_wait(). Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> [bhelgaas: rename PCI_STATUS_IMMEDIATE to PCI_STATUS_IMM_READY] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
08387454 |
|
27-Sep-2018 |
Daniel Drake <drake@endlessm.com> |
PCI: Reprogram bridge prefetch registers on resume On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM] Similarly, the NVIDIA proprietary driver also fails after resume (black screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for diagnosis, and their response indicated that it's a problem with the parent PCI bridge (on the Intel SoC), not the GPU. Runtime suspend/resume works fine, only S3 suspend is affected. We found a workaround: on resume, rewrite the Intel PCI bridge 'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the cases that I checked, this register has value 0 and we just have to rewrite that value. Linux already saves and restores PCI config space during suspend/resume, but this register was being skipped because upon resume, it already has value 0 (the correct, pre-suspend value). Intel appear to have previously acknowledged this behaviour and the requirement to rewrite this register: https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 Based on that, rewrite the prefetch register values even when that appears unnecessary. We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on ASUS X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet patched. I suspect it will also fix the issue that was worked around in commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g"). Thomas Martitz reports that this change also solves an issue where the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3 suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069 Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-By: Peter Wu <peter@lekensteyn.nl> CC: stable@vger.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>
|
#
81c4b5bf |
|
08-Sep-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: hotplug: Constify hotplug_slot_ops Hotplug drivers cannot declare their hotplug_slot_ops const, making them attractive targets for attackers, because upon registration of a hotplug slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members in that struct. Fix by moving these members to struct hotplug_slot and constify every driver's hotplug_slot_ops except for pciehp. pciehp constructs its hotplug_slot_ops at runtime based on the PCIe port's capabilities, hence cannot declare them const. It can be converted to __write_rarely once that's mainlined: http://www.openwall.com/lists/kernel-hardening/2016/11/16/3 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> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
|
#
7eb37025 |
|
02-Sep-2018 |
Randy Dunlap <rdunlap@infradead.org> |
PCI: Fix pci.c kernel-doc parameter warning Fix kernel-doc warning: ../drivers/pci/pci.c:218: warning: Excess function parameter 'p' description in 'pci_dev_str_match_path' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c6635792 |
|
30-Aug-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PCI: Allocate dma_alias_mask with bitmap_zalloc() Switch to bitmap_zalloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type ("unsigned long *") instead of the opaque "void *". Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
bfc45606 |
|
31-Aug-2018 |
Dennis Dalessandro <dennis.dalessandro@intel.com> |
IB/hfi1,PCI: Allow bus reset while probing Calling into the new API to reset the secondary bus results in a deadlock. This occurs because the device/bus is already locked at probe time. Reverting back to the old behavior while the API is improved. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200985 Fixes: c6a44ba950d1 ("PCI: Rename pci_try_reset_bus() to pci_reset_bus()") Fixes: 409888e0966e ("IB/hfi1: Use pci_try_reset_bus() for initiating PCI Secondary Bus Reset") Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Sinan Kaya <okaya@codeaurora.org>
|
#
d8a52810 |
|
05-Sep-2018 |
Dennis Dalessandro <dennis.dalessandro@intel.com> |
PCI: Fix faulty logic in pci_reset_bus() The pci_reset_bus() function calls pci_probe_reset_slot() to determine whether to call the slot or bus reset. The check has faulty logic in that it does not account for pci_probe_reset_slot() being able to return an errno. Fix by only calling the slot reset when the function returns 0. Fixes: 811c5cb37df4 ("PCI: Unify try slot and bus reset API") Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Sinan Kaya <okaya@codeaurora.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>
|
#
aaca43fd |
|
30-Jul-2018 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support To support peer-to-peer traffic on a segment of the PCI hierarchy, we must disable the ACS redirect bits for select PCI bridges. The bridges must be selected before the devices are discovered by the kernel and the IOMMU groups created. Therefore, add a kernel command line parameter to specify devices which must have their ACS bits disabled. The new parameter takes a list of devices separated by a semicolon. Each device specified will have its ACS redirect bits disabled. This is similar to the existing 'resource_alignment' parameter. The ACS Request P2P Request Redirect, P2P Completion Redirect and P2P Egress Control bits are disabled, which is sufficient to always allow passing P2P traffic uninterrupted. The bits are set after the kernel (optionally) enables the ACS bits itself. It is also done regardless of whether the kernel or platform firmware sets the bits. If the user tries to disable the ACS redirect for a device without the ACS capability, print a warning to dmesg. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: reorder to add the generic code first and move the device-specific quirk to subsequent patches] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Stephen Bates <sbates@raithlin.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Christian König <christian.koenig@amd.com>
|
#
45db3370 |
|
30-Jul-2018 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Allow specifying devices using a base bus and path of devfns When specifying PCI devices on the kernel command line using a bus/device/function address, bus numbers can change when adding or replacing a device, changing motherboard firmware, or applying kernel parameters like "pci=assign-buses". When bus numbers change, it's likely the command line tweak will be applied to the wrong device. Therefore, it is useful to be able to specify devices with a base bus number and the path of devfns needed to get to it, similar to the "device scope" structure in the Intel VT-d spec, Section 8.3.1. Thus, we add an option to specify devices in the following format: [<domain>:]<bus>:<device>.<func>[/<device>.<func>]* The path can be any segment within the PCI hierarchy of any length and determined through the use of 'lspci -t'. When specified this way, it is less likely that a renumbered bus will result in a valid device specification and the tweak won't be applied to the wrong device. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: use "device" instead of "slot" in documentation since that's the usual language in the PCI specs] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Stephen Bates <sbates@raithlin.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Christian König <christian.koenig@amd.com>
|
#
07d8d7e5 |
|
30-Jul-2018 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Make specifying PCI devices in kernel parameters reusable Separate out the code to match a PCI device with a string (typically originating from a kernel parameter) from the pci_specified_resource_alignment() function into its own helper function. While we are at it, this change fixes the kernel style of the function (fixing a number of long lines and extra parentheses). Additionally, make the analogous change to the kernel parameter documentation: Separate the description of how to specify a PCI device into its own section at the head of the "pci=" parameter. This patch should have no functional alterations. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: use "device" instead of "slot" in documentation since that's the usual language in the PCI specs] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Stephen Bates <sbates@raithlin.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Christian König <christian.koenig@amd.com>
|
#
2d2917f7 |
|
09-Aug-2018 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Export pcie_has_flr() pcie_flr() suggests pcie_has_flr() to ensure that PCIe FLR support is present prior to calling. pcie_flr() is exported while pcie_has_flr() is not. Resolve this. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ce29af2a |
|
25-Jul-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove unnecessary include of <linux/pci-aspm.h> Several PCI core files include pci-aspm.h even though they don't need anything provided by that file. Remove the unnecessary includes of it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org>
|
#
47a8e237 |
|
19-Jul-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: Whitelist Thunderbolt ports for runtime D3 Thunderbolt controllers can be runtime suspended to D3cold to save ~1.5W. This requires that runtime D3 is allowed on its PCIe ports, so whitelist them. The 2015 BIOS cutoff that we've instituted for runtime D3 on PCIe ports is unnecessary on Thunderbolt because we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine -- specifically including its hotplug ports. And the power saving should be afforded to machines even if their BIOS predates 2015. 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Andreas Noever <andreas.noever@gmail.com>
|
#
eb3b5bf1 |
|
19-Jul-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: Whitelist native hotplug ports for runtime D3 Previously we blacklisted PCIe hotplug ports for runtime D3 because: (a) Ports handled by the firmware must not be transitioned to D3 by the OS behind the firmware's back: https://bugzilla.kernel.org/show_bug.cgi?id=53811 (b) Ports handled natively by the OS lacked runtime D3 support in the pciehp driver. We've just rectified the latter, so allow users to manually enable and test it by passing pcie_port_pm=force on the command line. Vendors are thus put in a position to validate hotplug ports for runtime D3 and perhaps we can someday enable it by default, but with a BIOS cutoff date. Ashok Raj tested runtime D3 on hotplug ports of a SkyLake Xeon-SP in 2017 and encountered Hardware Error NMIs, so this feature clearly cannot be enabled for everyone yet: https://lkml.kernel.org/r/20170503180426.GA4058@otc-nc-03 While at it, remove an erroneous code comment I added with 97a90aee5dab ("PCI: Consolidate conditions to allow runtime PM on PCIe ports") which claims that parents of a hotplug port must stay awake lest interrupts cannot be delivered. That has turned out to be wrong at least for Thunderbolt hotplug ports. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Yinghai Lu <yinghai@kernel.org>
|
#
c6a44ba9 |
|
19-Jul-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Rename pci_try_reset_bus() to pci_reset_bus() Now that the old implementation of pci_reset_bus() is gone, replace pci_try_reset_bus() with pci_reset_bus(). Compared to the old implementation, new code will fail immmediately with -EAGAIN if object lock cannot be obtained. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fe32e2fa |
|
19-Jul-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Deprecate pci_reset_bus() and pci_reset_slot() functions pci_reset_bus() and pci_reset_slot() functions are not being used by any code. Remove them from the kernel in favor of pci_try_reset_bus() and pci_try_reset_slot() functions. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
811c5cb3 |
|
19-Jul-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Unify try slot and bus reset API Drivers are expected to call pci_try_reset_slot() or pci_try_reset_bus() by querying if a system supports hotplug or not. A survey showed that most drivers don't do this and we are leaking hotplug capability to the user. Hide pci_try_slot_reset() from drivers and embed into pci_try_bus_reset(). Change pci_try_reset_bus() parameter from struct pci_bus to struct pci_dev. Signed-off-by: Sinan Kaya <okaya@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>
|
#
18426238 |
|
19-Jul-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Handle error return from pci_reset_bridge_secondary_bus() Commit 01fd61c0b9bd ("PCI: Add a return type for pci_reset_bridge_secondary_bus()") added a return value to the function to return if a device is accessible following a reset. Callers are not checking the value. Pass error code up high in the stack if device is not accessible. Fixes: 01fd61c0b9bd ("PCI: Add a return type for pci_reset_bridge_secondary_bus()") Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a5fb9fb0 |
|
18-Jul-2018 |
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> |
PCI: OF: Fix I/O space page leak When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY driver was left disabled, the kernel crashed with this BUG: kernel BUG at lib/ioremap.c:72! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092 Hardware name: Renesas Condor board based on r8a77980 (DT) Workqueue: events deferred_probe_work_func pstate: 80000005 (Nzcv daif -PAN -UAO) pc : ioremap_page_range+0x370/0x3c8 lr : ioremap_page_range+0x40/0x3c8 sp : ffff000008da39e0 x29: ffff000008da39e0 x28: 00e8000000000f07 x27: ffff7dfffee00000 x26: 0140000000000000 x25: ffff7dfffef00000 x24: 00000000000fe100 x23: ffff80007b906000 x22: ffff000008ab8000 x21: ffff000008bb1d58 x20: ffff7dfffef00000 x19: ffff800009c30fb8 x18: 0000000000000001 x17: 00000000000152d0 x16: 00000000014012d0 x15: 0000000000000000 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0720072007300730 x10: 00000000000000ae x9 : 0000000000000000 x8 : ffff7dffff000000 x7 : 0000000000000000 x6 : 0000000000000100 x5 : 0000000000000000 x4 : 000000007b906000 x3 : ffff80007c61a880 x2 : ffff7dfffeefffff x1 : 0000000040000000 x0 : 00e80000fe100f07 Process kworker/0:1 (pid: 39, stack limit = 0x (ptrval)) Call trace: ioremap_page_range+0x370/0x3c8 pci_remap_iospace+0x7c/0xac pci_parse_request_of_pci_ranges+0x13c/0x190 rcar_pcie_probe+0x4c/0xb04 platform_drv_probe+0x50/0xbc driver_probe_device+0x21c/0x308 __device_attach_driver+0x98/0xc8 bus_for_each_drv+0x54/0x94 __device_attach+0xc4/0x12c device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0xb0/0x150 process_one_work+0x12c/0x29c worker_thread+0x200/0x3fc kthread+0x108/0x134 ret_from_fork+0x10/0x18 Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000) It turned out that pci_remap_iospace() wasn't undone when the driver's probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER, the probe was retried, finally causing the BUG due to trying to remap already remapped pages. Introduce the devm_pci_remap_iospace() managed API and replace the pci_remap_iospace() call with it to fix the bug. Fixes: dbf9826d5797 ("PCI: generic: Convert to DT resource parsing API") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [lorenzo.pieralisi@arm.com: split commit/updated the commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d6488ac1 |
|
05-Jul-2018 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
PCI: Mark fall-through switch cases before enabling -Wimplicit-fallthrough In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 2 was used: -Wimplicit-fallthrough=2 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
576c7218 |
|
25-Jun-2018 |
Alex Deucher <alexander.deucher@amd.com> |
PCI: Export pcie_get_speed_cap and pcie_get_width_cap So drivers can use them. This can be used to replace duplicate code in the drm subsystem. Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
f778a0d2 |
|
30-May-2018 |
Logan Gunthorpe <logang@deltatee.com> |
PCI: Expand documentation for pci_add_dma_alias() Seeing there's been some confusion about the use of pci_add_dma_alias(), expand the comment to describe why it must be called early and how early it must be called. Also, expand on the purpose of this function and common reasons it would be used. [The comment was reworded to some extent by Alex Williamson] Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Doug Meyer <dmeyer@gigaio.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>
|
#
b1277a22 |
|
29-Jun-2018 |
Christian König <ckoenig.leichtzumerken@gmail.com> |
PCI: Cleanup PCI_REBAR_CTRL_BAR_SHIFT handling Cleanup PCI_REBAR_CTRL_BAR_SHIFT handling. That was hard coded instead of properly defined in the header for some reason. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d3252ace |
|
29-Jun-2018 |
Christian König <ckoenig.leichtzumerken@gmail.com> |
PCI: Restore resized BAR state on resume Resize BARs after resume to the expected size again. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959 Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6") Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure") Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.15+
|
#
e5b1db01 |
|
30-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove unused pcie_get_minimum_link() In some cases pcie_get_minimum_link() returned misleading information because it found the slowest link and the narrowest link without considering the total bandwidth of the link. For example, consider a path with these two links: - 16.0 GT/s x1 link (16.0 * 10^9 * 128 / 130) * 1 / 8 = 1969 MB/s - 2.5 GT/s x16 link ( 2.5 * 10^9 * 8 / 10) * 16 / 8 = 4000 MB/s The available bandwidth of the path is limited by the 16 GT/s link to about 1969 MB/s, but pcie_get_minimum_link() returned 2.5 GT/s x1, which corresponds to only 250 MB/s. Callers should use pcie_print_link_status() instead, or pcie_bandwidth_available() if they need more detailed information. Remove pcie_get_minimum_link() since there are no callers left. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
60ee031a |
|
21-May-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Clean up outdated comments in pci_target_state() Two comments in pci_target_state() are outdated, as the function doesn't set the target power state for the device any more, only finds one for it, so fix them accordingly. Reported-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-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>
|
#
ae07b786 |
|
15-May-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Make pci_get_new_domain_nr() static The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr(). Since they are defined in the same file, pci_get_new_domain_nr() can be made static, which also simplifies preprocessor conditionals. No functional change intended. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
cef74409 |
|
10-May-2018 |
Gil Kupfer <gilkup@gmail.com> |
PCI: Add "pci=noats" boot parameter Adds a "pci=noats" boot parameter. When supplied, all ATS related functions fail immediately and the IOMMU is configured to not use device-IOTLB. Any function that checks for ATS capabilities directly against the devices should also check this flag. Currently, such functions exist only in IOMMU drivers, and they are covered by this patch. The motivation behind this patch is the existence of malicious devices. Lots of research has been done about how to use the IOMMU as protection from such devices. When ATS is supported, any I/O device can access any physical address by faking device-IOTLB entries. Adding the ability to ignore these entries lets sysadmins enhance system security. Signed-off-by: Gil Kupfer <gilkup@cs.technion.ac.il> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Joerg Roedel <jroedel@suse.de>
|
#
cfcadfaa |
|
08-May-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Check device_may_wakeup() in pci_enable_wake() Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) went too far and dropped the device_may_wakeup() check from pci_enable_wake() which causes wakeup to be enabled during system suspend, hibernation or shutdown for some PCI devices that are not allowed by user space to wake up the system from sleep (or power off). As a result of this, excessive power is drawn by some of the affected systems while in sleep states or off. Restore the device_may_wakeup() check in pci_enable_wake(), but make sure that the PCI bus type's runtime suspend callback will not call device_may_wakeup() which is about system wakeup from sleep and not about device wakeup from runtime suspend. Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Cc: 4.13+ <stable@vger.kernel.org> # 4.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8feaec33 |
|
07-May-2018 |
Kai Heng Feng <kai.heng.feng@canonical.com> |
PCI / PM: Always check PME wakeup capability for runtime wakeup support USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info). The device in question is not power managed by platform firmware, furthermore, it only supports PME# from D3cold: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Before commit de3ef1eb1cd0, the device never gets runtime suspended. After that commit, the device gets runtime suspended to D3hot, which can not generate any PME#. usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence device_can_wakeup() in pci_dev_run_wake() always returns true. So pci_dev_run_wake() needs to check PME wakeup capability as its first condition. In addition, change wakeup flag passed to pci_target_state() from false to true, because we want to find the deepest state different from D3cold that the device can still generate PME#. In this case, it's D0 for the device in question. Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: 4.13+ <stable@vger.kernel.org> # 4.13+ Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0cf22d6b |
|
19-Apr-2018 |
Jakub Kicinski <kuba@kernel.org> |
PCI: Add "PCIe" to pcie_print_link_status() messages Currently the pcie_print_link_status() will print PCIe bandwidth and link width information but does not mention it is pertaining to the PCIe. Since this and related functions are used exclusively by networking drivers today users may get confused into thinking that it's the NIC bandwidth that is being talked about. Insert a "PCIe" into the messages. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
adf58458 |
|
10-Apr-2018 |
Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com> |
PCI: Remove messages about reassigning resources When reassigning device resources to increase their alignment, e.g., because of a "pci=resource_alignment=" kernel parameter or because the platform aligns resources to its page size, we previously emitted messages like this: pci 0000:00:00.0: Disabling memory decoding and releasing memory resources pci 0000:00:00.0: disabling bridge mem windows These messages don't convey any useful information, so remove them. Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to force PCI devices to be page aligned") Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
|
#
5745392e |
|
14-Mar-2018 |
Zhichang Yuan <yuanzhichang@hisilicon.com> |
PCI: Apply the new generic I/O management on PCI IO hosts After introducing the new generic I/O space management (Logical PIO), the original PCI MMIO relevant helpers need to be updated based on the new interfaces defined in logical PIO. Adapt the corresponding code to match the changes introduced by logical PIO. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> # earlier draft Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
fcfaab30 |
|
14-Mar-2018 |
Gabriele Paoloni <gabriele.paoloni@huawei.com> |
PCI: Add fwnode handler as input param of pci_register_io_range() In preparation for having the PCI MMIO helpers use the new generic I/O space management (logical PIO) we need to add the fwnode handler as an extra input parameter. Changes the signature of pci_register_io_range() and its callers as needed. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
|
#
e2515476 |
|
14-Mar-2018 |
Gabriele Paoloni <gabriele.paoloni@huawei.com> |
PCI: Remove __weak tag from pci_register_io_range() pci_register_io_range() has only one definition, so there is no need for the __weak attribute. Remove it. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
9e506a7b |
|
30-Mar-2018 |
Tal Gilboa <talgi@mellanox.com> |
PCI: Add pcie_print_link_status() to log link speed and whether it's limited Add pcie_print_link_status(). This logs the current settings of the link (speed, width, and total available bandwidth). If the device is capable of more bandwidth but is limited by a slower upstream link, we include information about the link that limits the device's performance. The user may be able to move the device to a different slot for better performance. This provides a unified method for all PCI devices to report status and issues, instead of each device reporting in a different way, using different code. Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: changelog, reword log messages, print device capabilities when not limited, print bandwidth in Gb/s] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6db79a88 |
|
30-Mar-2018 |
Tal Gilboa <talgi@mellanox.com> |
PCI: Add pcie_bandwidth_available() to compute bandwidth available to device Add pcie_bandwidth_available() to compute the bandwidth available to a device. This may be limited by the device itself or by a slower upstream link leading to the device. The available bandwidth at each link along the path is computed as: link_width * 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. Also return the device with the slowest link and the speed and width of that link. Signed-off-by: Tal Gilboa <talgi@mellanox.com> [bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find uppermost limiting device, return speed/width of the limiting device] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
df62ab5e |
|
09-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Tidy comments Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2a4d2c42 |
|
03-Mar-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public There are PCI devices which are power-manageable by a nonstandard means, such as a custom ACPI method. One example are discrete GPUs in hybrid graphics laptops, another are Thunderbolt controllers in Macs. Such devices can't be put into D3cold with pci_set_power_state() because pci_platform_power_transition() fails with -ENODEV. Instead they're put into D3hot by pci_set_power_state() and subsequently into D3cold by invoking the nonstandard means. However as a consequence the cached current_state is incorrectly left at D3hot. What we need to do is walk the hierarchy below such a PCI device on powerdown and update the current_state to D3cold. On powerup the PCI device itself and the hierarchy below it is in D0uninitialized, so we need to walk the hierarchy again and wake all devices, causing them to be put into D0active and then letting them autosuspend as they see fit. To this end make pci_wakeup_bus() & pci_bus_set_current_state() public so PCI drivers don't have to reinvent the wheel. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/2962443259e7faec577274b4ef8c54aad66f9a94.1520068884.git.lukas@wunner.de
|
#
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>
|
#
6b2f1351 |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Wait for device to become ready after secondary bus reset Setting Secondary Bus Reset of a downstream port sends a hot reset. PCIe r4.0, sec 2.3.1, Request Handling Rules, indicates that a device can return CRS Completion Status following such a reset. Wait until the device becomes ready in that situation. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
01fd61c0 |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Add a return type for pci_reset_bridge_secondary_bus() Add a return value to pci_reset_bridge_secondary_bus() so we can return an error if the device doesn't become ready after the reset. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
abbcf0e2 |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Wait for device to become ready after a power management reset PCIe r4.0, sec 2.3.1, Request Handling Rules, indicates that a device can return CRS Completion Status following a D3hot to D0 transition. Wait until the device becomes ready in that situation. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
9df1c6ec |
|
28-Feb-2018 |
Shawn Lin <shawn.lin@rock-chips.com> |
PCI: Fix NULL pointer dereference in of_pci_bus_find_domain_nr() If the "parent" pointer passed to of_pci_bus_find_domain_nr() is NULL, don't dereference it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a2758b6b |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Rename pci_flr_wait() to pci_dev_wait() and make it generic PCIe r4.0, sec 2.3.1, Request Handling Rules, says: Valid reset conditions after which a device is permitted to return CRS are: * Cold, Warm, and Hot Resets, * FLR * A reset initiated in response to a D3hot to D0 uninitialized Try to reuse FLR implementation towards other reset types. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
91295d79 |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Handle FLR failure and allow other reset types pci_flr_wait() and pci_af_flr() functions assume graceful return even though the device is inaccessible under error conditions. Return -ENOTTY in error cases so that __pci_reset_function_locked() can try other reset types if AF_FLR/FLR reset fails. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
cb5e0d06 |
|
27-Feb-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Protect restore with device lock to be consistent Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") added protection around pci_dev_restore() function so a device-specific remove callback does not cause a race condition with hotplug. pci_dev_lock() usage has been forgotten in two places. Add locks for pci_slot_restore() and moving pci_dev_restore() inside the locks for pci_try_reset_function(). Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
|
#
ac95090a |
|
22-Feb-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
pci: Simplify code by using the new dmi_get_bios_year() helper ...instead of open coding its functionality. No changes in functionality. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jean Delvare <jdelvare@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-acpi@vger.kernel.org Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/20180222125923.57385-4-andriy.shevchenko@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
204f4afa |
|
16-Feb-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove redundant probes for device reset support We probe every device for whether it supports reset so we can tell whether to create a sysfs "reset" file for it. We do that probe in pci_init_capabilities() during enumeration and save the result in dev->reset_fn. The result doesn't depend on any other devices on the bus and shouldn't change after boot, so we don't need to do the probe again. Remove the pci_probe_reset_function() calls and rely on the dev->reset_fn we found during enumeration. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7328c8f4 |
|
26-Jan-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add SPDX GPL-2.0 when no license was specified b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") added SPDX GPL-2.0 to several PCI files that previously contained no license information. Add SPDX GPL-2.0 to all other PCI files that did not contain any license information and hence were under the default GPL version 2 license of the kernel. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
430a2368 |
|
04-Jan-2018 |
Jay Cornwall <Jay.Cornwall@amd.com> |
PCI: Add pci_enable_atomic_ops_to_root() The Atomic Operations feature (PCIe r4.0, sec 6.15) allows atomic transctions to be requested by, routed through and completed by PCIe components. Routing and completion do not require software support. Component support for each is detectable via the DEVCAP2 register. A Requester may use AtomicOps only if its PCI_EXP_DEVCTL2_ATOMIC_REQ is set. This should be set only if the Completer and all intermediate routing elements support AtomicOps. A concrete example is the AMD Fiji-class GPU (which is capable of making AtomicOp requests), below a PLX 8747 switch (advertising AtomicOp routing) with a Haswell host bridge (advertising AtomicOp completion support). Add pci_enable_atomic_ops_to_root() for per-device control over AtomicOp requests. This checks to be sure the Root Port supports completion of the desired AtomicOp sizes and the path to the Root Port supports routing the AtomicOps. Signed-off-by: Jay Cornwall <Jay.Cornwall@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> [bhelgaas: changelog, comments, whitespace] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7506dc79 |
|
17-Jan-2018 |
Frederick Lawler <fred@fredlawl.com> |
PCI: Add wrappers for dev_printk() Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by: Frederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fc0f9f4d |
|
11-Dec-2017 |
Heiner Kallweit <hkallweit1@gmail.com> |
PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi() Add pcim_set_mwi(), a device-managed version of pci_set_mwi(). First user is the Realtek r8169 driver. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
505fb746 |
|
29-Oct-2017 |
Randy Dunlap <rdunlap@infradead.org> |
PCI: Fix kernel-doc build warning Fix build error in kernel-doc notation: ../drivers/pci/pci.c:3479: ERROR: Unexpected indentation. "::" tells the kernel-doc "reStructuredText" processor that the following block is a literal block of some blob that should be kept as is. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> [bhelgaas: add hint about "::" meaning] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c2eac4d3 |
|
25-Oct-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Use the NEVER_SKIP driver flag Replace the PCI-specific flag PCI_DEV_FLAGS_NEEDS_RESUME with the PM core's DPM_FLAG_NEVER_SKIP one everywhere and drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
832c418a |
|
25-Oct-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Document reset method return values The pci_reset_function() path may try several different reset methods: device-specific resets, PCIe Function Level Resets, PCI Advanced Features Function Level Reset, etc. Add a comment about what the return values from these methods mean. If one of the methods fails, in some cases we want to continue and try the next one in the list, but sometimes we want to stop trying. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
33ba90aa |
|
08-Sep-2017 |
Jan Glauber <jan.glauber@gmail.com> |
PCI: Avoid slot reset if bridge itself is broken When checking to see if a PCI slot can safely be reset, we previously checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET flag set. Some PCIe root port bridges do not behave well after a slot reset, and may cause the device in the slot to become unusable. Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device to prevent the slot from being reset. Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
35702778 |
|
08-Sep-2017 |
David Daney <david.daney@cavium.com> |
PCI: Avoid bus reset if bridge itself is broken When checking to see if a PCI bus can safely be reset, we previously checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET flag set. Children marked with that flag are known not to behave well after a bus reset. Some PCIe root port bridges also do not behave well after a bus reset, sometimes causing the devices behind the bridge to become unusable. Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device to allow these bridges to be flagged, and prevent their secondary buses from being reset. Signed-off-by: David Daney <david.daney@cavium.com> [jglauber@cavium.com: fixed typo] Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
79e699b6 |
|
05-Sep-2017 |
Jan H. Schönherr <jschoenh@amazon.de> |
PCI: Remove unused function __pci_reset_function() The last caller of __pci_reset_function() has been removed. Remove the function as well. Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0f50a49e |
|
15-Sep-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI: Avoid race while enabling upstream bridges" This reverts commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9. Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon, gen4: iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2 iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2 iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2 iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 ... iwlwifi 0000:04:00.0: Failed to load firmware chunk! iwlwifi 0000:04:00.0: Could not load the [0] uCode section iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110 iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110 He bisected it to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges"). Revert that commit to fix the regression. Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Srinath Mannam <srinath.mannam@broadcom.com> CC: Jens Axboe <axboe@kernel.dk> CC: Luca Coelho <luca@coelho.fi> CC: Johannes Berg <johannes@sipsolutions.net> CC: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
#
821cdad5 |
|
29-Aug-2017 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Wait up to 60 seconds for device to become ready after FLR Sporadic reset issues have been observed with an Intel 750 NVMe drive while assigning the physical function to the guest machine. The sequence of events observed is as follows: - perform a Function Level Reset (FLR) - sleep up to 1000ms total - read ~0 from PCI_COMMAND (CRS completion for config read) - warn that the device didn't return from FLR - touch the device before it's ready - device drops config writes when we restore register settings (there's no mechanism for software to learn about CRS completions for writes) - incomplete register restore leaves device in inconsistent state - device probe fails because device is in inconsistent state After reset, an endpoint may respond to config requests with Configuration Request Retry Status (CRS) to indicate that it is not ready to accept new requests. See PCIe r3.1, sec 2.3.1 and 6.6.2. Increase the timeout value from 1 second to 60 seconds to cover the period where device responds with CRS and also report polling progress. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> [bhelgaas: include the mandatory 100ms in the delays we print] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b63773a8 |
|
18-Jul-2017 |
Rob Herring <robh@kernel.org> |
PCI: Convert to using %pOF instead of full_name() Now that we have a custom printf format specifier, convert users of full_name() to use %pOF instead. This is preparation for removing storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au>
|
#
40f11adc |
|
18-Aug-2017 |
Srinath Mannam <srinath.mannam@broadcom.com> |
PCI: Avoid race while enabling upstream bridges When we enable a device, we first enable any upstream bridges. If a bridge has multiple downstream devices and we enable them simultaneously, the race to enable the upstream bridge may cause problems. Consider this hierarchy: bridge A --+-- device B +-- device C If drivers for B and C call pci_enable_device() simultaneously, both will attempt to enable A, which involves setting PCI_COMMAND_MASTER via pci_set_master() and PCI_COMMAND_MEMORY via pci_enable_resources(). In the following sequence, B's update to set A's PCI_COMMAND_MEMORY is lost, and neither B nor C will work correctly: B C pci_set_master(A) cmd = read(A, PCI_COMMAND) cmd |= PCI_COMMAND_MASTER pci_set_master(A) cmd = read(A, PCI_COMMAND) cmd |= PCI_COMMAND_MASTER write(A, PCI_COMMAND, cmd) pci_enable_device(A) pci_enable_resources(A) cmd = read(A, PCI_COMMAND) cmd |= PCI_COMMAND_MEMORY write(A, PCI_COMMAND, cmd) write(A, PCI_COMMAND, cmd) Avoid this race by holding a new pci_bridge_mutex while enabling a bridge. This ensures that both PCI_COMMAND_MASTER and PCI_COMMAND_MEMORY will be updated before another thread can start enabling the bridge. Note that although pci_enable_bridge() is recursive, it enables any upstream bridges *before* acquiring the mutex. When it acquires the mutex and calls pci_set_master() and pci_enable_device(), any upstream bridges have already been enabled so pci_enable_device() will not deadlock by calling pci_enable_bridge() again. Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> [bhelgaas: changelog, comment] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b6f6d56c |
|
17-Aug-2017 |
Thierry Reding <treding@nvidia.com> |
PCI: Allow PCI express root ports to find themselves If the pci_find_pcie_root_port() function is called on a root port itself, return the root port rather than NULL. This effectively reverts commit 0e405232871d6 ("PCI: fix oops when try to find Root Port for a PCI device") which added an extra check that would now be redundant. Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported") Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum") Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0e405232 |
|
15-Aug-2017 |
dingtianhong <dingtianhong@huawei.com> |
PCI: fix oops when try to find Root Port for a PCI device Eric report a oops when booting the system after applying the commit a99b646afa8a ("PCI: Disable PCIe Relaxed..."): [ 4.241029] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [ 4.247001] IP: pci_find_pcie_root_port+0x62/0x80 [ 4.253011] PGD 0 [ 4.253011] P4D 0 [ 4.253011] [ 4.258013] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 4.262015] Modules linked in: [ 4.265005] CPU: 31 PID: 1 Comm: swapper/0 Not tainted 4.13.0-dbx-DEV #316 [ 4.271002] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0 06/22/2016 [ 4.279002] task: ffffa2ee38cfa040 task.stack: ffffa51ec0004000 [ 4.285001] RIP: 0010:pci_find_pcie_root_port+0x62/0x80 [ 4.290012] RSP: 0000:ffffa51ec0007ab8 EFLAGS: 00010246 [ 4.295003] RAX: 0000000000000000 RBX: ffffa2ee36bae000 RCX: 0000000000000006 [ 4.303002] RDX: 000000000000081c RSI: ffffa2ee38cfa8c8 RDI: ffffa2ee36bae000 [ 4.310013] RBP: ffffa51ec0007b58 R08: 0000000000000001 R09: 0000000000000000 [ 4.317001] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa51ec0007ad0 [ 4.324005] R13: ffffa2ee36bae098 R14: 0000000000000002 R15: ffffa2ee37204818 [ 4.331002] FS: 0000000000000000(0000) GS:ffffa2ee3fcc0000(0000) knlGS:0000000000000000 [ 4.339002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.345001] CR2: 0000000000000050 CR3: 000000401000f000 CR4: 00000000001406e0 [ 4.351002] Call Trace: [ 4.354012] ? pci_configure_device+0x19f/0x570 [ 4.359002] ? pci_conf1_read+0xb8/0xf0 [ 4.363002] ? raw_pci_read+0x23/0x40 [ 4.366011] ? pci_read+0x2c/0x30 [ 4.370014] ? pci_read_config_word+0x67/0x70 [ 4.374012] pci_device_add+0x28/0x230 [ 4.378012] ? pci_vpd_f0_read+0x50/0x80 [ 4.382014] pci_scan_single_device+0x96/0xc0 [ 4.386012] pci_scan_slot+0x79/0xf0 [ 4.389001] pci_scan_child_bus+0x31/0x180 [ 4.394014] acpi_pci_root_create+0x1c6/0x240 [ 4.398013] pci_acpi_scan_root+0x15f/0x1b0 [ 4.402012] acpi_pci_root_add+0x2e6/0x400 [ 4.406012] ? acpi_evaluate_integer+0x37/0x60 [ 4.411002] acpi_bus_attach+0xdf/0x200 [ 4.415002] acpi_bus_attach+0x6a/0x200 [ 4.418014] acpi_bus_attach+0x6a/0x200 [ 4.422013] acpi_bus_scan+0x38/0x70 [ 4.426011] acpi_scan_init+0x10c/0x271 [ 4.429001] acpi_init+0x2fa/0x348 [ 4.433004] ? acpi_sleep_proc_init+0x2d/0x2d [ 4.437001] do_one_initcall+0x43/0x169 [ 4.441001] kernel_init_freeable+0x1d0/0x258 [ 4.445003] ? rest_init+0xe0/0xe0 [ 4.449001] kernel_init+0xe/0x150 ====================== cut here ============================= It looks like the pci_find_pcie_root_port() was trying to find the Root Port for the PCI device which is the Root Port already, it will return NULL and trigger the problem, so check the highest_pcie_bridge to fix thie problem. Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported") Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum") Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ab4b8a47 |
|
02-Aug-2017 |
Piotr Gregor <piotrgregor@rsyncme.org> |
PCI/PM: Expand description of pci_set_power_state() Add two reasons for returning 0 value to the description of pci_set_power_state() to include the cases when: - the transition is to D1 or D2 but D1 and D2 are not supported - the transition is to D3 but D3 is not supported Signed-off-by: Piotr Gregor <piotrgregor@rsyncme.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a477b9cd |
|
01-Aug-2017 |
Marc Zyngier <maz@kernel.org> |
PCI: Add pci_reset_function_locked() The implementation of PCI workarounds may require that the device is reset from its probe function. This implies that the PCI device lock is already held, and makes calling pci_reset_function() impossible (since it will itself try to take that lock). Add pci_reset_function_locked(), which is the equivalent of pci_reset_function(), except that it requires the PCI device lock to be already held by the caller. Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> [bhelgaas: folded in fix for conflict with 52354b9d1f46 ("PCI: Remove __pci_dev_reset() and pci_dev_reset()")] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # 4.11: 52354b9d1f46: PCI: Remove __pci_dev_reset() and pci_dev_reset() Cc: stable@vger.kernel.org # 4.11
|
#
baecc470 |
|
21-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Skip bridges in pci_enable_wake() PCI bridges only have a reason to generate wakeup signals on behalf of devices below them, so avoid preparing bridges for wakeup directly in pci_enable_wake(). Also drop the pci_has_subordinate() check from pci_pm_default_resume() as this will be done by pci_enable_wake() itself now. 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>
|
#
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>
|
#
52354b9d |
|
01-Jun-2017 |
Christoph Hellwig <hch@lst.de> |
PCI: Remove __pci_dev_reset() and pci_dev_reset() Implement the reset probing / reset chain directly in __pci_probe_reset_function() and __pci_reset_function_locked() respectively. Link: http://lkml.kernel.org/r/20170601111039.8913-4-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
775755ed |
|
01-Jun-2017 |
Christoph Hellwig <hch@lst.de> |
PCI: Split ->reset_notify() method into ->reset_prepare() and ->reset_done() The pci_error_handlers->reset_notify() method had a flag to indicate whether to prepare for or clean up after a reset. The prepare and done cases have no shared functionality whatsoever, so split them into separate methods. [bhelgaas: changelog, update locking comments] Link: http://lkml.kernel.org/r/20170601111039.8913-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
666ff6f8 |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Avoid using device_may_wakeup() for runtime PM pci_target_state() calls device_may_wakeup() which checks whether or not the device may wake up the system from sleep states, but pci_target_state() is used for runtime PM too. Since runtime PM is expected to always enable remote wakeup if possible, modify pci_target_state() to take additional argument indicating whether or not it should look for a state from which the device can signal wakeup and pass either the return value of device_can_wakeup(), or "false" (if the device itself is not wakeup-capable) to it from the code related to runtime PM. While at it, fix the comment in pci_dev_run_wake() which is not about sleep states. 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>
|
#
de3ef1eb |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / core: Drop run_wake flag from struct dev_pm_info The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system wakeup signaling has always been rather artificial. The only practical reason for it to exist at the core level was that ACPI and PCI treated those two cases differently, but that's not the case any more after recent changes. For this reason, get rid of the run_wake flag and, when applicable, use device_set_wakeup_capable() and device_can_wakeup() instead of device_set_run_wake() and device_run_wake(), respectively. 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>
|
#
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>
|
#
99b3c58f |
|
26-May-2017 |
Piotr Gregor <piotrgregor@rsyncme.org> |
PCI: Test INTx masking during enumeration, not at run-time The test for INTx masking via PCI_COMMAND_INTX_DISABLE performed in pci_intx_mask_supported() should be done before the device can be used. This is to avoid writing PCI_COMMAND while the driver owns the device, in case that has any effect on MSI/MSI-X interrupts. Move the content of pci_intx_mask_supported() to pci_intx_mask_broken() and call it from pci_setup_device(). The test result can be queried at any time later using the same pci_intx_mask_supported() interface as before (though with changed implementation), so callers (uio, vfio) should be unaffected. Signed-off-by: Piotr Gregor <piotrgregor@rsyncme.org> [bhelgaas: changelog, remove quirk check, remove locking, move dev->broken_intx_masking assignment to caller] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
|
#
b014e96d |
|
01-Jun-2017 |
Christoph Hellwig <hch@lst.de> |
PCI: Protect pci_error_handlers->reset_notify() 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_error_handlers->reset_notify() by holding the device lock while calling it. Note: - pci_dev_lock() calls device_lock() in addition to blocking user-space config accesses. - pci_err_handlers->reset_notify() is used inside pci_dev_save_and_disable() and pci_dev_restore(). We could hold the device lock directly in pci_reset_notify(), but we expand the region since we have several calls following each other. Without this, ->reset_notify() may race with ->remove() calls, which can be easily triggered in NVMe. [bhelgaas: changelog, add pci_reset_notify() comment] [bhelgaas: fold in fix from Dan Carpenter <dan.carpenter@oracle.com>: http://lkml.kernel.org/r/20170701135323.x5vaj4e2wcs2mcro@mwanda] Link: http://lkml.kernel.org/r/20170601111039.8913-2-hch@lst.de Reported-by: Rakesh Pandit <rakesh@tuxera.com> Tested-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
dc15e71e |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Restore PME Enable if skipping wakeup setup The wakeup_prepared PCI device flag is used for preventing subsequent changes of PCI device wakeup settings in the same way (e.g. enabling device wakeup twice in a row). However, in some cases PME Enable may be updated by things like PCI configuration space restoration in the meantime and it may need to be set again even though the rest of the settings need not change, so modify __pci_enable_wake() to do that when it is about to return early. Also, it is reasonable to expect that __pci_enable_wake() will always clear PME Status when invoked to disable device wakeup, so make it do so even if it is going to return early then. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
4ebeb1ec |
|
30-May-2017 |
CQ Tang <cq.tang@intel.com> |
PCI: Restore PRI and PASID state after Function-Level Reset After a Function-Level Reset, PCI states need to be restored. Save PASID features and PRI reqs cached. [bhelgaas: search for capability only if PRI/PASID were enabled] Signed-off-by: CQ Tang <cq.tang@intel.com> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Jean-Phillipe Brucker <jean-philippe.brucker@arm.com> Cc: David Woodhouse <dwmw2@infradead.org>
|
#
4d071c32 |
|
23-May-2017 |
Imre Deak <imre.deak@intel.com> |
PCI/PM: Add needs_resume flag to avoid suspend complete optimization Some drivers - like i915 - may not support the system suspend direct complete optimization due to differences in their runtime and system suspend sequence. Add a flag that when set resumes the device before calling the driver's system suspend handlers which effectively disables the optimization. Needed by a future patch fixing suspend/resume on i915. Suggested by Rafael. Signed-off-by: Imre Deak <imre.deak@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
|
#
31342330 |
|
11-Apr-2017 |
Ard Biesheuvel <ardb@kernel.org> |
PCI: Do not disregard parent resources starting at 0x0 Commit f44116ae8818 ("PCI: Remove pci_find_parent_resource() use for allocation") updated the logic that iterates over all bus resources and compares them to a given resource, in order to decide whether one is the parent of the latter. This change inadvertently causes pci_find_parent_resource() to disregard resources starting at address 0x0, resulting in an error such as the one below on ARM systems whose I/O window starts at 0x0. pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window] pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window] pci_bus 0000:00: root bus resource [bus 00-0f] pci 0000:00:01.0: PCI bridge to [bus 01] pci 0000:00:02.0: PCI bridge to [bus 02] pci 0000:00:03.0: PCI bridge to [bus 03] pci 0000:00:03.0: can't claim BAR 13 [io 0x0000-0x0fff]: no compatible bridge window pci 0000:03:01.0: can't claim BAR 0 [io 0x0000-0x001f]: no compatible bridge window While this never happens on x86, it is perfectly legal in general for a PCI MMIO or IO window to start at address 0x0, and it was supported in the code before commit f44116ae8818. Drop the test for res->start != 0; resource_contains() already checks whether [start, end) completely covers the resource, and so it should be redundant. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
490cb6dd |
|
19-Apr-2017 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
PCI: Implement devm_pci_remap_cfgspace() The introduction of the pci_remap_cfgspace() interface allows PCI host controller drivers to map PCI config space through a dedicated kernel interface. Current PCI host controller drivers use the devm_ioremap_*() devres interfaces to map PCI configuration space regions so in order to update them to the new pci_remap_cfgspace() mapping interface a new set of devres interfaces should be implemented so that PCI host controller drivers can make use of them. Introduce two new functions in the PCI kernel layer and Devres documentation: - devm_pci_remap_cfgspace() - devm_pci_remap_cfg_resource() so that PCI host controller drivers can make use of them to map PCI configuration space regions. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Jonathan Corbet <corbet@lwn.net>
|
#
f90b0875 |
|
09-Mar-2017 |
Brian Norris <briannorris@chromium.org> |
PCI: Export pci_remap_iospace() and pci_unmap_iospace() These are useful for PCIe host drivers, and those drivers can be modules. [bhelgaas: don't remove __weak; it's removed elsewhere] Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
|
#
a60a2b73 |
|
14-Apr-2017 |
Christoph Hellwig <hch@lst.de> |
PCI: Export pcie_flr() Currently we opencode the FLR sequence in lots of place; export a core helper instead. We split out the probing for FLR support as all the non-core callers already know their hardware. Note that in the new pci_has_flr() function the quirk check has been moved before the capability check as there is no point in reading the capability in this case. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7b309aef |
|
19-Apr-2017 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
PCI: Remove __weak tag from pci_remap_iospace() pci_remap_iospace() is marked as a weak symbol even though no architecture is currently overriding it; given that its implementation internals have already code paths that are arch specific (ie PCI_IOBASE and ioremap_page_range() attributes) there is no need to leave the weak symbol in the kernel since the same functionality can be achieved by customizing per-arch the corresponding functionality. Remove the __weak symbol from pci_remap_iospace(). Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
|
#
e3adec72 |
|
10-Apr-2017 |
Yongji Xie <elohimes@gmail.com> |
PCI: Don't resize resources when realigning all devices in system The "pci=resource_alignment" argument aligns BARs of designated devices by artificially increasing their size. Increasing the size increases the alignment and prevents other resources from being assigned in the same alignment region, e.g., in the same page, but it can break drivers that use the BAR size to locate things, e.g., ilo_map_device() does this: off = pci_resource_len(pdev, bar) - 0x2000; The new pcibios_default_alignment() interface allows an arch to request that *all* BARs in the system be aligned to a larger size. In this case, we don't need to artificially increase the resource size because we know every BAR of every device will be realigned, so nothing will share the same alignment region. Use IORESOURCE_STARTALIGN to request realignment of PCI BARs when we know we're realigning all BARs in the system. [bhelgaas: comment, changelog] Signed-off-by: Yongji Xie <elohimes@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0dde1c08 |
|
17-Apr-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Don't reassign resources that are already aligned The "pci=resource_alignment=" kernel argument designates devices for which we want alignment greater than is required by the PCI specs. Previously we set IORESOURCE_UNSET for every MEM resource of those devices, even if the resource was *already* sufficiently aligned. If a resource is already sufficiently aligned, leave it alone and don't try to reassign it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
81a5e70e |
|
14-Apr-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Factor pci_reassigndev_resource_alignment() Pull the BAR size adjustment out into a new function, pci_request_resource_alignment(), and add a comment about how and why we increase the resource size and alignment. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0a701aa6 |
|
10-Apr-2017 |
Yongji Xie <elohimes@gmail.com> |
PCI: Add pcibios_default_alignment() for arch-specific alignment control When VFIO passes through a PCI device to a guest, it does not allow the guest to mmap BARs that are smaller than PAGE_SIZE unless it can reserve the rest of the page (see vfio_pci_probe_mmaps()). This is because a page might contain several small BARs for unrelated devices and a guest should not be able to access all of them. VFIO emulates guest accesses to non-mappable BARs, which is functional but slow. On systems with large page sizes, e.g., PowerNV with 64K pages, BARs are more likely to share a page and performance is more likely to be a problem. Add a weak function to set default alignment for all PCI devices. An arch can override it to force the PCI core to place memory BARs on their own pages. Signed-off-by: Yongji Xie <elohimes@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ea00353f |
|
18-Apr-2017 |
Lukas Wunner <lukas@wunner.de> |
PCI: Freeze PME scan before suspending devices Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790) crashes during suspend tests. Geert Uytterhoeven managed to reproduce the issue on an M2-W Koelsch board (r8a7791): It occurs when the PME scan runs, once per second. During PME scan, the PCI host bridge (rcar-pci) registers are accessed while its module clock has already been disabled, leading to the crash. One reproducer is to configure s2ram to use "s2idle" instead of "deep" suspend: # echo 0 > /sys/module/printk/parameters/console_suspend # echo s2idle > /sys/power/mem_sleep # echo mem > /sys/power/state Another reproducer is to write either "platform" or "processors" to /sys/power/pm_test. It does not (or is less likely) to happen during full system suspend ("core" or "none") because system suspend also disables timers, and thus the workqueue handling PME scans no longer runs. Geert believes the issue may still happen in the small window between disabling module clocks and disabling timers: # echo 0 > /sys/module/printk/parameters/console_suspend # echo platform > /sys/power/pm_test # Or "processors" # echo mem > /sys/power/state (Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.) Rafael Wysocki agrees that PME scans should be suspended before the host bridge registers become inaccessible. To that end, queue the task on a workqueue that gets frozen before devices suspend. Rafael notes however that as a result, some wakeup events may be missed if they are delivered via PME from a device without working IRQ (which hence must be polled) and occur after the workqueue has been frozen. If that turns out to be an issue in practice, it may be possible to solve it by calling pci_pme_list_scan() once directly from one of the host bridge's pm_ops callbacks. Stacktrace for posterity: PM: Syncing filesystems ... [ 38.566237] done. PM: Preparing system for sleep (mem) Freezing user space processes ... [ 38.579813] (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. PM: Suspending system (mem) PM: suspend of devices complete after 152.456 msecs PM: late suspend of devices complete after 2.809 msecs PM: noirq suspend of devices complete after 29.863 msecs suspend debug: Waiting for 5 second(s). Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 pgd = c0003000 [00000000] *pgd=80000040004003, *pmd=00000000 Internal error: : 1211 [#1] SMP ARM Modules linked in: CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 4.9.0-rc1-koelsch-00011-g68db9bc814362e7f #3383 Hardware name: Generic R8A7791 (Flattened Device Tree) Workqueue: events pci_pme_list_scan task: eb56e140 task.stack: eb58e000 PC is at pci_generic_config_read+0x64/0x6c LR is at rcar_pci_cfg_base+0x64/0x84 pc : [<c041d7b4>] lr : [<c04309a0>] psr: 600d0093 sp : eb58fe98 ip : c041d750 fp : 00000008 r10: c0e2283c r9 : 00000000 r8 : 600d0013 r7 : 00000008 r6 : eb58fed6 r5 : 00000002 r4 : eb58feb4 r3 : 00000000 r2 : 00000044 r1 : 00000008 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 6a9f6c80 DAC: 55555555 Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210) Stack: (0xeb58fe98 to 0xeb590000) fe80: 00000002 00000044 fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000 fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830 fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100 ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000 ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380 ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000 ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0 ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd [<c041d7b4>] (pci_generic_config_read) from [<c041d9b0>] (pci_bus_read_config_word+0x58/0x80) [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>] (pci_check_pme_status+0x34/0x78) [<c0424bf0>] (pci_check_pme_status) from [<c0424c5c>] (pci_pme_wakeup+0x28/0x54) [<c0424c5c>] (pci_pme_wakeup) from [<c0424ce0>] (pci_pme_list_scan+0x58/0xb4) [<c0424ce0>] (pci_pme_list_scan) from [<c0235fbc>] (process_one_work+0x1bc/0x308) [<c0235fbc>] (process_one_work) from [<c02366c4>] (worker_thread+0x2a8/0x3e0) [<c02366c4>] (worker_thread) from [<c023a928>] (kthread+0xe4/0xfc) [<c023a928>] (kthread) from [<c0206d68>] (ret_from_fork+0x14/0x2c) Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000) ---[ end trace 667d43ba3aa9e589 ]--- Fixes: df17e62e5bff ("PCI: Add support for polling PME state on suspended legacy PCI devices") Reported-and-tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reported-and-tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: stable@vger.kernel.org # 2.6.37+ Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
|
#
ea629d87 |
|
14-Feb-2017 |
Yongji Xie <xyjxie@linux.vnet.ibm.com> |
PCI: Ignore requested alignment for IOV BARs We would call pci_reassigndev_resource_alignment() before pci_init_capabilities(). So the requested alignment would never work for IOV BARs. Furthermore, it's meaningless to request additional alignment for IOV BARs, the IOV BAR alignment is only determined by the VF BAR size. Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
f65fd1aa |
|
03-Apr-2017 |
Sasha Neftin <sasha.neftin@intel.com> |
PCI: Avoid FLR for Intel 82579 NICs Per Intel Specification Update 335553-002 (see link below), some 82579 network adapters advertise a Function Level Reset (FLR) capability, but they can hang when an FLR is triggered. To reproduce the problem, attach the device to a VM, then detach and try to attach again. Add a quirk to prevent the use of FLR on these devices. [bhelgaas: changelog, comments] Link: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/82579lm-82579v-gigabit-network-connection-spec-update.pdf Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fe2bd75b |
|
29-Mar-2017 |
Keith Busch <kbusch@kernel.org> |
PCI: Short-circuit pci_device_is_present() for disconnected devices If the PCI device is disconnected, return false immediately from pci_device_is_present(). pci_device_is_present() uses the bus accessors, so the early return in the device accessors doesn't help here. 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>
|
#
50b2b540 |
|
14-Mar-2017 |
Adrian Hunter <adrian.hunter@intel.com> |
PCI/PM: Don't sleep at all when d3_delay or d3cold_delay is zero msleep() still sleeps 1 jiffy even when told to sleep for zero milliseconds. That can end up being 1-2 milliseconds or more. In the cases of d3_delay and d3cold_delay, that unnecessarily increases suspend and/or resume latencies. Do not sleep at all for the respective cases if d3_delay is zero or d3cold_delay is zero. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d98e0929 |
|
03-Feb-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI: pciehp: Add runtime PM support for PCIe hotplug ports" This reverts commit 68db9bc814362e7f24371c27d12a4f34477d9356. Yinghai reported that the following manual hotplug sequence: # echo 0 > /sys/bus/pci/slots/8/power # echo 1 > /sys/bus/pci/slots/8/power worked in v4.9, but fails in v4.10-rc1, and that reverting 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe hotplug ports") makes it work again. Fixes: 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe hotplug ports") Link: https://lkml.kernel.org/r/CAE9FiQVCMCa7iVyuwp9z6VrY0cE7V_xghuXip28Ft52=8QmTWw@mail.gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=193951 Reported-by: Yinghai Lu <yinghai@kernel.org> 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>
|
#
63880b23 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Ignore BAR updates on virtual functions VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to restore VF BARs"); this merely restructures it slightly to make it easier to split updates for standard and SR-IOV BARs. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
68db9bc8 |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: pciehp: Add runtime PM support for PCIe hotplug ports Linux 4.8 added support for runtime suspending PCIe ports to D3hot with commit 006d44e49a25 ("PCI: Add runtime PM support for PCIe ports"), but excluded hotplug ports. Those are now afforded runtime PM by the present commit. Hotplug ports require a few extra considerations: - The configuration space of the port remains accessible in D3hot, so all the functions to read or modify the Slot Status and Slot Control registers need not be modified. Even turning on slot power doesn't seem to require the port to be in D0, at least the PCIe spec doesn't say so and I confirmed that by testing with a Thunderbolt controller. - However D0 is required to access devices on the secondary bus. This happens in pciehp_check_link_status() and pciehp_configure_device() (both called from board_added()) and in pciehp_unconfigure_device() (called from remove_board()), so acquire a runtime PM ref for their invocation. - The hotplug port stays active as long as it has active children. If all hotplugged devices below the port runtime suspend, the port is allowed to runtime suspend as well. Plug and unplug detection continues to work in D3hot. - Hotplug interrupts are delivered in-band, so while the hotplug port itself is allowed to go to D3hot, its parent ports must stay in D0 for interrupts to come through. Add a corresponding restriction to pci_dev_check_d3cold(). - Runtime PM may only be allowed if the hotplug port is handled natively by the OS. On ACPI systems, the port may alternatively be handled by the firmware and things break if the OS puts the port into D3 behind the firmware's back: E.g. Thunderbolt hotplug ports on non-Macs are handled by Intel's firmware in System Management Mode and the firmware is known to access devices on the port's secondary bus without checking first if the port is in D0: https://bugzilla.kernel.org/show_bug.cgi?id=53811 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> CC: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
718a0609 |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Unfold conditions to block runtime PM on PCIe ports The conditions to block D3 on parent ports are currently condensed into a single expression in pci_dev_check_d3cold(). Upcoming commits will add further conditions for hotplug ports, making this expression fairly large and impenetrable. Unfold the conditions to maintain readability when they are amended. No functional change intended. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Mika Westerberg <mika.westerberg@linux.intel.com> CC: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
97a90aee |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Consolidate conditions to allow runtime PM on PCIe ports The conditions to allow runtime PM on PCIe ports are currently spread across two different files: The condition relating to hotplug ports is located in portdrv_pci.c whereas all other conditions are located in pci.c. Consolidate all conditions in a single place in pci.c, thus making it easier to follow the logic and amend conditions down the road. Note that the condition relating to hotplug ports is inserted *before* the condition relating to the "pcie_port_pm=force" command line option, so runtime PM is not afforded to hotplug ports even if this option is given. That's exactly how the code behaved up until now. If this is not desired, the ordering of the conditions can simply be reversed. 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>
|
#
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>
|
#
e8559b71 |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Speed up algorithm in pci_bridge_d3_update() After a device has been added, removed or had its D3cold attributes changed, we recheck whether its parent bridge may runtime suspend to D3hot with pci_bridge_d3_update(). The most naive algorithm would be to iterate over the bridge's children and check if any of them are blocking D3. The function already tries to be a bit smarter than that by first checking the device that was changed. If this device already blocks D3 on the bridge, then walking over all the other children can be skipped. A drawback of this approach is that if the device is *not* blocking D3, it will be checked a second time by pci_walk_bus(). But that's cheap and is outweighed by the performance gain of potentially skipping pci_walk_bus() altogether. The algorithm can be optimized further by taking into account if D3 is currently allowed for the bridge, as shown in the following truth table: (a) remove && bridge_d3: D3 is currently allowed for the bridge and removing one of its children won't change that. No action necessary. (b) remove && !bridge_d3: D3 may now be allowed for the bridge if the removed child was the only one blocking it. Check all its siblings to verify that. (c) !remove && bridge_d3: D3 may now be disallowed but this can only be caused by the added/changed child, not any of its siblings. Check only that single device. (d) !remove && !bridge_d3: D3 may now be allowed for the bridge if the changed child was the only one blocking it. Check all its siblings to verify that. By checking beforehand if the changed child is blocking D3, we may be able to skip checking its siblings. Currently we do not special-case option (a) and in case of option (c) we gratuitously call pci_walk_bus(). Speed up the algorithm by adding these optimizations. Reword the comments a bit in an attempt to improve clarity. 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>
|
#
738a7edb |
|
28-Oct-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Don't acquire ref on parent in pci_bridge_d3_update() This function is always called with an existing pci_dev struct, which holds a reference on the pci_bus struct it resides on, which in turn holds a reference on pci_bus->bridge, which is the pci_dev's parent. Hence there's no need to acquire an additional ref on the parent. More specifically, the pci_dev exists until pci_destroy_dev() drops the final reference on it, so all calls to pci_bridge_d3_update() must be finished before that. It is arguably the caller's responsibility to ensure that it doesn't call pci_bridge_d3_update() with a pci_dev that might suddenly disappear, but in any case the existing callers are all safe: - The call in pci_destroy_dev() happens before the call to put_device(). - The call in pci_bus_add_device() is synchronized with pci_destroy_dev() using pci_lock_rescan_remove(). - The calls to pci_d3cold_disable() from the xhci and nouveau drivers are safe because a ref on the pci_dev is held as long as it's bound to a driver. - The calls to pci_d3cold_enable() / pci_d3cold_disable() when modifying the sysfs "d3cold_allowed" entry are also safe because kernfs_drain() waits for existing sysfs users to finish before removing the entry, and pci_destroy_dev() is called way after that. 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>
|
#
6496ebd7 |
|
21-Oct-2016 |
Alan Stern <stern@rowland.harvard.edu> |
PCI: Check for PME in targeted sleep state One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by: Pierre de Villemereuil <flyos@mailoo.org> Tested-by: Pierre de Villemereuil <flyos@mailoo.org> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org CC: Lukas Wunner <lukas@wunner.de>
|
#
62d9a78f |
|
13-Sep-2016 |
Yongji Xie <xyjxie@linux.vnet.ibm.com> |
PCI: Ignore requested alignment for VF BARs Resource allocation for VFs is done via the VF BARx registers in the PF's SR-IOV Capability, and the BARs in the VFs themselves are read-only zeros (see SR-IOV spec r1.1, secs 3.3.14 and 3.4.1.11). Even though the actual VF BARs are read-only zeros, the VF dev->resource[] structs describe the space allocated for the VF (this is a piece of the space described by the VF BARx register in the PF's SR-IOV capability). It's meaningless to request additional alignment for a VF: the VF BAR alignment is completely determined by the alignment of the VF BARx in the PF and the size of the VF BAR. Ignore the user's alignment requests for VF devices. Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f0b99f70 |
|
13-Sep-2016 |
Yongji Xie <xyjxie@linux.vnet.ibm.com> |
PCI: Ignore requested alignment for PROBE_ONLY and fixed resources Users may request additional alignment of PCI resources, e.g., to align BARs on page boundaries so they can be shared with guests via VFIO. This of course may require reallocation if firmware has already assigned the BARs with smaller alignments. If the platform has requested PCI_PROBE_ONLY, we should never change any PCI BARs, so we can't provide any additional alignment. Also, if a BAR is marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the firmware depends on the current BAR value, we can't change the alignment. In these cases, log a message and ignore the user's alignment requests. [bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check] Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a6a64026 |
|
17-Sep-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Recognize D3cold in pci_update_current_state() Whenever a device is resumed or its power state is changed using the platform, its new power state is read from the PM Control & Status Register and cached in pci_dev->current_state by calling pci_update_current_state(). If the device is in D3cold, reading from config space typically results in a fabricated "all ones" response. But if it's in D3hot, the two bits representing the power state in the PMCSR are *also* set to 1. Thus D3hot and D3cold are not discernible by just reading the PMCSR. To account for this, pci_update_current_state() uses two workarounds: - When transitioning to D3cold using pci_platform_power_transition(), the new power state is set blindly by pci_update_current_state(), i.e. without verifying that the device actually *is* in D3cold. This is achieved by setting the "state" argument to PCI_D3cold. The "state" argument was originally intended to convey the new state in case the device doesn't have the PM capability. It is *also* used to convey the device state if the PM capability is present and the new state is D3cold, but this was never explained in the kerneldoc. - Once the current_state is set to D3cold, further invocations of pci_update_current_state() will blindly assume that the device is still in D3cold and leave the current_state unmodified. To get out of this impasse, the current_state has to be set directly, typically by calling pci_raw_set_power_state() or pci_enable_device(). It would be desirable if pci_update_current_state() could reliably detect D3cold by itself. That would allow us to do away with these workarounds, and it would allow for a smarter, more energy conserving runtime resume strategy after system sleep: Currently devices which utilize direct_complete are mandatorily runtime resumed in their ->complete stage. This can be avoided if their power state after system sleep is the same as before, but it requires a mechanism to detect the power state reliably. We've just gained the ability to query the platform firmware for its opinion on the device's power state. On platforms conforming to ACPI 4.0 or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3 and therefore the deepest power state that will ever be reported is D3hot, even though the device may actually be in D3cold. To detect D3cold in those cases, accessibility of the vendor ID in config space is probed using pci_device_is_present(). This also works for devices which are not platform-power-manageable at all, but can be suspended to D3cold using a nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on the Mac). 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>
|
#
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>
|
#
4132a577 |
|
17-Sep-2016 |
Lukas Wunner <lukas@wunner.de> |
PCI: Afford direct-complete to devices with non-standard PM There are devices not power-manageable by the platform, but still able to runtime suspend to D3cold with a non-standard mechanism. One example is laptop hybrid graphics where the discrete GPU and its built-in HDA controller are power-managed either with a _DSM (AMD PowerXpress, Nvidia Optimus) or a separate gmux controller (MacBook Pro). Another example is Thunderbolt on Macs which is power-managed with custom ACPI methods. When putting the system to sleep, we currently handle such devices improperly by transitioning them from D3cold to D3hot (the default power state defined at the top of pci_target_state()). This wastes energy and prolongs the suspend sequence (powering up the Thunderbolt controller takes 2 seconds). Avoid that by assuming that a non-standard PM mechanism is at work if the device is not platform-power-manageable but currently in D3cold. If the device is wakeup enabled, we might still have to wake it up from D3cold if PME cannot be signaled from that power state. The check for devices without PM capability comes before the check for D3cold since such devices could in theory also be powered down by non-standard means and should then be afforded direct-complete as well. 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>
|
#
afd29f90 |
|
15-Sep-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Add pci_find_resource() Add a new helper function pci_find_resource() that can be used to find out whether a given resource (for example from a child device) is contained within given PCI device's standard resources. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e16b4660 |
|
21-Jul-2016 |
Keith Busch <kbusch@kernel.org> |
PCI: Allow additional bus numbers for hotplug bridges A user may hot add a switch requiring more than one bus to enumerate. This previously required a system reboot if BIOS did not sufficiently pad the bus resource, which they frequently don't do. Add a kernel parameter so a user can specify the minimum number of bus numbers to reserve for a hotplug bridge's subordinate buses so rebooting won't be necessary. The default is 1, which is equivalent to previous behavior. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6ec39cf5 |
|
06-Jun-2016 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PCI / PM: check all fields in pci_set_platform_pm() When assign new PCI platform PM operations check for all mandatory fields to prevent NULL pointer dereference. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2a2aca31 |
|
17-Jun-2016 |
Ben Dooks <ben.dooks@codethink.co.uk> |
PCI: Include <asm/dma.h> for isa_dma_bridge_buggy At least on arm, <asm/dma.h> does not get included when building drivers/pci/pci.o. This causes the following build warning which can be fixed by including <asm/dma.h>: drivers/pci/pci.c:37:5: warning: symbol 'isa_dma_bridge_buggy' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
644a544f |
|
07-Jun-2016 |
Koehrer Mathias (ETAS/ESW5) <mathias.koehrer@etas.com> |
PCI: Extending pci=resource_alignment to specify device/vendor IDs Some uio-based PCI drivers, e.g., uio_cif do not work if the assigned PCI memory resources are not page aligned. By using the kernel option "pci=resource_alignment" it is possible to force single PCI boards to use page alignment for their memory resources. However, this is fairly cumbersome if several of these boards are in use as the specification of the cards has to be done via PCI bus/slot/function number which might change, e.g., by adding another board. Extend the kernel option "pci=resource_alignment" to allow specification of relevant devices via PCI device/vendor (and subdevice/subvendor) IDs. The specification of the devices via device/vendor is indicated by a leading string "pci:" as argument to "pci=resource_alignment". The format of the specification is pci:<vendor>:<device>[:<subvendor>:<subdevice>] Signed-off-by: Mathias Koehrer <mathias.koehrer@etas.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>
|
#
21751a9a |
|
09-Jun-2016 |
Ben Dooks <ben.dooks@codethink.co.uk> |
PCI: Make bus_attr_resource_alignment static The symbol bus_attr_resource_alignment is not exported or declared elsewhere, so make it static to fix the following warning: drivers/pci/pci.c:4900:1: warning: symbol 'bus_attr_resource_alignment' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2ab51dde |
|
10-Jun-2016 |
Tomasz Nowicki <tn@semihalf.com> |
ARM64: PCI: Add acpi_pci_bus_find_domain_nr() Extend pci_bus_find_domain_nr() so it can find the domain from either: - ACPI, via the new acpi_pci_bus_find_domain_nr() interface, or - DT, via of_pci_bus_find_domain_nr() Note that this is only used for CONFIG_PCI_DOMAINS_GENERIC=y, so it does not affect x86 or ia64. [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1a4f93f7 |
|
10-Jun-2016 |
Tomasz Nowicki <tn@semihalf.com> |
PCI: Factor DT-specific pci_bus_find_domain_nr() code out pci_bus_find_domain_nr() retrieves the host bridge domain number in a DT-specific way. Rename it to of_pci_bus_find_domain_nr() to reflect that, so we can add a corresponding function for ACPI. [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
9c7cb891 |
|
10-Jun-2016 |
Tomasz Nowicki <tn@semihalf.com> |
PCI: Refactor pci_bus_assign_domain_nr() for CONFIG_PCI_DOMAINS_GENERIC Instead of assigning bus->domain_nr inside pci_bus_assign_domain_nr(), return the domain and let the caller do the assignment. Rename pci_bus_assign_domain_nr() to pci_bus_find_domain_nr() to reflect this. No functional change intended. [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
4d3f1384 |
|
10-Jun-2016 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Add pci_unmap_iospace() to unmap I/O resources Add pci_unmap_iospace() to undo what pci_remap_iospace() did. This is needed to support hotplug removal of host bridges that use pci_remap_iospace(). [bhelgaas: changelog] Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
92efb1bd |
|
16-May-2016 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Identify Enhanced Allocation (EA) BAR Equivalent resources in sysfs Resource flags are exposed to userspace via the sysfs "resource" file. lspci reads the sysfs file to determine resource properties. Add a "BAR Equivalent Indicator" flag so lspci can distinguish between [virtual] and [enhanced] resources. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sean O. Stalley <sean.stalley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c5076cfe |
|
11-May-2016 |
Tomasz Nowicki <tn@semihalf.com> |
PCI, of: Move PCI I/O space management to PCI core code No functional changes in this patch. PCI I/O space mapping code does not depend on OF; therefore it can be moved to PCI core code. This way we will be able to use it, e.g., in ACPI PCI code. Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Liviu Dudau <Liviu.Dudau@arm.com>
|
#
c1d61c9b |
|
31-Mar-2016 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Reverse standard ACS vs device-specific ACS enabling The original thought was that if a device implemented ACS, then surely we want to use that... well, it turns out that devices can make an ACS capability so broken that we still need to fall back to quirks. Reverse the order of ACS enabling to give quirks first shot at it. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
338c3149 |
|
03-Mar-2016 |
Jacek Lawrynowicz <jacek.lawrynowicz@intel.com> |
PCI: Add support for multiple DMA aliases Solve IOMMU support issues with PCIe non-transparent bridges that use Requester ID look-up tables (RID-LUT), e.g., the PEX8733. The NTB connects devices in two independent PCI domains. Devices separated by the NTB are not able to discover each other. A PCI packet being forwared from one domain to another has to have its RID modified so it appears on correct bus and completions are forwarded back to the original domain through the NTB. The RID is translated using a preprogrammed table (LUT) and the PCI packet propagates upstream away from the NTB. If the destination system has IOMMU enabled, the packet will be discarded because the new RID is unknown to the IOMMU. Adding a DMA alias for the new RID allows IOMMU to properly recognize the packet. Each device behind the NTB has a unique RID assigned in the RID-LUT. The current DMA alias implementation supports only a single alias, so it's not possible to support mutiple devices behind the NTB when IOMMU is enabled. Enable all possible aliases on a given bus (256) that are stored in a bitset. Alias devfn is directly translated to a bit number. The bitset is not allocated for devices that have no need for DMA aliases. More details can be found in the following article: http://www.plxtech.com/files/pdf/technical/expresslane/RTC_Enabling%20MulitHostSystemDesigns.pdf Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: David Woodhouse <David.Woodhouse@intel.com> Acked-by: Joerg Roedel <jroedel@suse.de>
|
#
48c83080 |
|
24-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Move informational printk to pci_add_dma_alias() One of the quirks that adds DMA aliases logs an informational message in dmesg. Move that to pci_add_dma_alias() so all users log the message consistently. No functional change intended (except extra message). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
f0af9593 |
|
24-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add pci_add_dma_alias() to abstract implementation Add a pci_add_dma_alias() interface to encapsulate the details of adding an alias. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
|
#
dcbb408a |
|
04-Apr-2016 |
Colin Ian King <colin.king@canonical.com> |
PCI: Fix spelling errors Fix spelling of "initalization". [bhelgaas: also fix pci/pci.c] Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
5adecf81 |
|
22-Feb-2016 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Wait for up to 1000ms after FLR reset Some devices take longer than the spec indicates to return from FLR reset, a notable case of this is Intel integrated graphics (IGD), which can often take an additional 300ms powering down an attached LCD panel as part of the FLR. Allow devices up to 1000ms, testing every 100ms whether the second dword of config space is read as -1. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
54c6e2dd |
|
29-Feb-2016 |
Krzysztof =?utf-8?Q?Ha=C5=82asa?= <khalasa@piap.pl> |
PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr() pci_create_root_bus() passes a "parent" pointer to pci_bus_assign_domain_nr(). When CONFIG_PCI_DOMAINS_GENERIC is defined, pci_bus_assign_domain_nr() dereferences that pointer. Many callers of pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL pointer dereference error. 7c674700098c ("PCI: Move domain assignment from arm64 to generic code") moved the "parent" dereference from arm64 to generic code. Only arm64 used that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it always supplied a valid "parent" pointer. Other arches supplied NULL "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they used a no-op version of pci_bus_assign_domain_nr(). 8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use pci_common_init(), which supplies a NULL "parent" pointer. These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash with a NULL pointer dereference like this while probing PCI: Unable to handle kernel NULL pointer dereference at virtual address 000000a4 PC is at pci_bus_assign_domain_nr+0x10/0x84 LR is at pci_create_root_bus+0x48/0x2e4 Kernel panic - not syncing: Attempted to kill init! [bhelgaas: changelog, add "Reported:" and "Fixes:" tags] Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1 Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains") Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code") Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> CC: stable@vger.kernel.org # v4.0+
|
#
fe537670 |
|
07-Mar-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Consolidate PCI DMA constants and interfaces in linux/pci-dma-compat.h Christoph added a generic include/linux/pci-dma-compat.h, so now there's one place with most of the PCI DMA interfaces. Move more PCI DMA-related things there: - The PCI_DMA_* direction constants from linux/pci.h - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary() CONFIG_PCI implementations from drivers/pci/pci.c - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary() !CONFIG_PCI stubs from linux/pci.h - The pci_set_dma_mask() and pci_set_consistent_dma_mask() !CONFIG_PCI stubs from linux/pci.h Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
5bd28338 |
|
05-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove includes of empty asm-generic/pci-bridge.h include/asm-generic/pci-bridge.h is now empty, so remove every #include of it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Will Deacon <will.deacon@arm.com> (arm64)
|
#
f3d2f165 |
|
07-Jan-2016 |
Geliang Tang <geliangtang@163.com> |
PCI: Use to_pci_dev() instead of open-coding it Use to_pci_dev() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ff3ce480 |
|
27-Dec-2015 |
Bogicevic Sasa <brutallesale@gmail.com> |
PCI: Fix all whitespace issues Fix all whitespace issues (missing or needed whitespace) in all files in drivers/pci. Code is compiled with allyesconfig before and after code changes and objects are recorded and checked with objdiff and they are not changed after this commit. Signed-off-by: Bogicevic Sasa <brutallesale@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.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>
|
#
597becb4 |
|
29-Oct-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Expand Enhanced Allocation BAR output An Enhanced Allocation Capability entry with BEI 0 fills in dev->resource[0] just like a real BAR 0 would, but non-EA experts might not connect "EA - BEI 0" with BAR 0. Decode the EA jargon a little bit, e.g., change this: pci 0002:01:00.0: EA - BEI 0, Prop 0x00: [mem 0x84300000-0x84303fff] to this: pci 0002:01:00.0: BAR 0: [mem 0x84300000-0x84303fff] (from Enhanced Allocation, properties 0x00) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
26635112 |
|
29-Oct-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Make Enhanced Allocation bitmasks more obvious Expand bitmask #defines completely. This puts the shift in the code instead of in the #define, but it makes it more obvious in the header file how fields in the register are laid out. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
11183991 |
|
29-Oct-2015 |
David Daney <david.daney@cavium.com> |
PCI: Handle Enhanced Allocation capability for SR-IOV devices SR-IOV BARs can be specified via EA entries. Extend the EA parser to extract the SRIOV BAR resources, and modify sriov_init() to use resources previously obtained via EA. Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sean O. Stalley <sean.stalley@intel.com>
|
#
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>
|
#
c56d4450 |
|
18-Oct-2015 |
Hariprasad Shenai <hariprasad@chelsio.com> |
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or Unexpected Completion errors in some systems, which may cause device access timeouts. Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values for the Attribute as were supplied in the header of the corresponding Request, except as explicitly allowed when IDO is used." Instead of copying the Attributes from the Request to the Completion, the T5 always generates Completions with zero Attributes. The receiver of a Completion whose Attributes don't match the Request may accept it (which itself seems non-compliant based on sec 2.3.2), or it may handle it as a Malformed TLP or an Unexpected Completion, which will probably lead to a device access timeout. Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root Port so it always generate Requests with zero Attributes. This does affect all other devices which are downstream of that Root Port, but these are performance optimizations that should not make a functional difference. Note that Configuration Space accesses are never supposed to have TLP Attributes, so we're safe waiting till after any Configuration Space accesses to do the Root Port "fixup". Based on original work by Casey Leedom <leedom@chelsio.com> [bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework to use pci_upstream_bridge() and check for Root Port device type, edit diagnostics to clarify intent and devices affected] Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.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>
|
#
b07461a8 |
|
17-Sep-2015 |
Taku Izumi <izumi.taku@jp.fujitsu.com> |
PCI/AER: Clear error status registers during enumeration and restore AER errors might be recorded when powering-on devices. These errors can be ignored, so firmware usually clears them before the OS enumerates devices. However, firmware is not involved when devices are added via hotplug, so the OS may discover power-up errors that should be ignored. The same may happen when powering up devices when resuming after suspend. Clear the AER error status registers during enumeration and resume. [bhelgaas: changelog, remove repetitive comments] Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
70675e0b |
|
29-Jul-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
PCI: Don't try to restore VF BARs VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. Don't update VF BARs in pci_restore_bars(). This avoids spurious "BAR %d: error updating" messages that we see when doing vfio pass-through after 6eb7018705de ("vfio-pci: Move idle devices to D3hot power state"). [bhelgaas: changelog, fix whitespace] Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c43996f4 |
|
24-Aug-2015 |
Luis R. Rodriguez <mcgrof@suse.com> |
PCI: Add pci_ioremap_wc_bar() This lets drivers take advantage of PAT when available. It should help with the transition of converting video drivers over to ioremap_wc() to help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache(), see: de33c442ed2a ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()") Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: <syrjala@sci.fi> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Juergen Gross <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Ville Syrjälä <syrjala@sci.fi> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: airlied@linux.ie Cc: benh@kernel.crashing.org Cc: dan.j.williams@intel.com Cc: konrad.wilk@oracle.com Cc: linux-fbdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: mst@redhat.com Cc: vinod.koul@intel.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcgrof@do-not-panic.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
27d868b5 |
|
24-Aug-2015 |
Keith Busch <kbusch@kernel.org> |
PCI: Set MPS to match upstream bridge Firmware typically configures the PCIe fabric with a consistent Max Payload Size setting based on the devices present at boot. A hot-added device typically has the power-on default MPS setting (128 bytes), which may not match the fabric. The previous Linux default, in the absence of any "pci=pcie_bus_*" options, was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added devices. Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every device's MPS setting matches the upstream bridge. This makes it more likely that a hot-added device will work in a system with optimized MPS configuration. Note that if we hot-add a device that only supports 128-byte MPS, it still likely won't work because we don't reconfigure the rest of the fabric. Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it sets MPS to 128 for everything. [bhelgaas: changelog, new default, rework for pci_configure_device() path] Tested-by: Keith Busch <keith.busch@intel.com> Tested-by: Jordan Hargrave <jharg93@gmail.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
|
#
ccbc175a |
|
07-Jul-2015 |
Alexander Duyck <alexander.h.duyck@redhat.com> |
PCI: Restore ACS configuration as part of pci_restore_state() Previously we did not restore ACS state after a PCIe reset. This meant that we could not reassign interfaces after a system suspend because the D0->D3 transition disabled ACS, and we didn't restore it when going back to D0. Restore ACS configuration in pci_restore_state(). [bhelgaas: changelog] Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Allen Kay <allen.m.kay@intel.com> CC: Chris Wright <chris@sous-sol.org> CC: Alex Williamson <alex.williamson@redhat.com>
|
#
aaed816f |
|
14-Jul-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove useless redundant code Remove redundant code from __pci_bus_find_cap_start(). No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0a1a9b49 |
|
29-Jun-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
PCI: Simplify pci_find_(ext_)capability() return value checks The return value of the pci_find_(ext_)capability() is either zero or the position of a capability. It is never negative. This patch consolidates the form of check from (pos <= 0) to (!pos). Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.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>
|
#
08249651 |
|
13-Apr-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI: Propagate the "ignore hotplug" setting to parent Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by: tiagdtd-lava <tiagdtd-lava@yahoo.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.17+
|
#
c6201cd8 |
|
07-May-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/MSI: Remove unused pci_msi_off() pci_msi_off() is unused, so remove it. Removes the exported symbol pci_msi_off(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
55db3208 |
|
02-Apr-2015 |
Sean O. Stalley <sean.stalley@intel.com> |
PCI: Read capability list as dwords, not bytes Reading both the capability ID and "next" pointer at the same time lets us parse the list with half the number of config reads. Signed-off-by: Sean O. Stalley <sean.stalley@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
e6b29dea |
|
08-Apr-2015 |
Ray Jui <rjui@broadcom.com> |
PCI: Export symbols required for loadable host driver modules Export the following symbols so they can be referenced by a PCI host bridge driver compiled as a kernel loadable module: pci_common_swizzle pci_create_root_bus pci_stop_root_bus pci_remove_root_bus pci_assign_unassigned_bus_resources pci_fixup_irqs Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
|
#
646c0282 |
|
11-Mar-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fail pci_ioremap_bar() on unassigned resources Make pci_ioremap_bar() fail if we're trying to map a BAR that hasn't been assigned. Normally pci_enable_device() will fail if a BAR hasn't been assigned, but a driver can successfully call pci_enable_device_io() even if a memory BAR hasn't been assigned. That driver should not be able to use pci_ioremap_bar() to map that unassigned memory BAR. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1f7bf3bf |
|
11-Mar-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Show driver, BAR#, and resource on pci_ioremap_bar() failure Use dev_warn() to complain about a pci_ioremap_bar() failure so we can include the driver name, BAR number, and the resource itself. We could use dev_WARN() to also get the backtrace as we did previously, but I think that's more information than we need. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
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>
|
#
51e53738 |
|
21-Nov-2014 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add flag for devices that don't reset on D3hot->D0 transition Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-") should perform an internal reset when transitioning from D3hot to D0 via software control. Configuration context is lost and the device requires a full reinitialization sequence. Unfortunately the definition of "internal reset", beyond the application of the configuration context, is largely left to the interpretation of the specific device. Some devices don't seem to perform an "internal reset" even if they report No_Soft_Reset == 0. We still need to honor the PCI specification and restore PCI config context in the event that we do a PM reset, so we don't cache and modify the PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the intention is to reset the device, like pci_reset_function(), we need a mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform any significant "internal reset" of the device. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f331a859 |
|
15-Jan-2015 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add flag for devices where we can't use bus reset Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+
|
#
7c674700 |
|
27-Dec-2014 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
PCI: Move domain assignment from arm64 to generic code The current logic in arm64 pci_bus_assign_domain_nr() is flawed in that depending on the host controller configuration for a platform and the initialization sequence, core code may end up allocating PCI domain numbers from both DT and the generic domain counter, which would result in PCI domain allocation aliases/errors. Fix the logic behind the PCI domain number assignment and move the resulting code to the PCI core so the same domain allocation logic is used on all platforms that select CONFIG_PCI_DOMAINS_GENERIC. [bhelgaas: tidy changelog] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> CC: Rob Herring <robh+dt@kernel.org> CC: Catalin Marinas <catalin.marinas@arm.com>
|
#
98d9b271 |
|
03-Dec-2014 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
PCI: Expose pci_load_saved_state for public consumption. We have the pci_load_and_free_saved_state, and pci_store_saved_state but are missing the functionality to just load the state multiple times in the PCI device without having to free/save the state. This patch makes it possible to use this function. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
#
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>
|
#
bb383e28 |
|
11-Nov-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
PCI: Make FLR and AF FLR reset warning messages different We have same warning message for FLR and AF FLR and users can't know which type of resets the PCI device is taking when there are pending transactions. Print different messages for FLR and AF FLR cases. [bhelgaas: make code structure parallel, add "anyway" to suggest risk] Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
754834b9 |
|
06-Nov-2014 |
Quentin Lambert <lambert.quentin@gmail.com> |
PCI: Simplify if-return sequences Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8b921acf |
|
29-Sep-2014 |
Liviu Dudau <Liviu.Dudau@arm.com> |
PCI: Add pci_remap_iospace() to map bus I/O resources Add pci_remap_iospace() to map bus I/O resources into the CPU virtual address space. Architectures with special needs may provide their own version, but most should be able to use this one. This function is useful for PCI host bridge drivers that need to map the PCI I/O resources into virtual memory space. [bhelgaas: phys_addr description, drop temporary "err" variable] Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> CC: Arnd Bergmann <arnd@arndb.de>
|
#
41e5c0f8 |
|
29-Sep-2014 |
Liviu Dudau <Liviu.Dudau@arm.com> |
of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr() Add pci_get_new_domain_nr() to allocate a new domain number and of_get_pci_domain_nr() to retrieve the PCI domain number of a given device from DT. Host bridge drivers or architecture-specific code can choose to implement their PCI domain number policy using these two functions. Using of_get_pci_domain_nr() guarantees a stable PCI domain number on every boot provided that all host bridge controllers are assigned a number in the device tree using "linux,pci-domain" property. Mixing use of pci_get_new_domain_nr() and of_get_pci_domain_nr() is not recommended as it can lead to potentially conflicting domain numbers being assigned to root buses behind different host bridges. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Catalin Marinas <catalin.marinas@arm.com>
|
#
79e50e72 |
|
07-Sep-2014 |
Quentin Lambert <lambert.quentin@gmail.com> |
PCI: Remove assignment from "if" conditions The following Coccinelle semantic patch was used to find and correct cases of assignments in "if" conditions: @@ expression var, expr; statement S; @@ + var = expr; if( - (var = expr) + var ) S Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
385321e2 |
|
20-Jul-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Allow PCI devices to be put into D3cold during system suspend Commit 448bd857d48e ("PCI/PM: add PCIe runtime D3cold support") added a check to prevent PCI devices from being put into D3cold during system suspend without giving any particular reason. Also the check isn't really necessary, because acpi_pci_set_power_state() maps PCI_D3hot to ACPI_STATE_D3_COLD anyway. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1f6ae47e |
|
16-Jul-2014 |
Vidya Sagar <sagar.tv@gmail.com> |
PCI: Configure ASPM when enabling device We can't do ASPM configuration at enumeration-time because enabling it makes some defective hardware unresponsive, even if ASPM is disabled later (see 41cd766b0659 ("PCI: Don't enable aspm before drivers have had a chance to veto it"). Therefore, we have to do it after a driver claims the device. We previously configured ASPM in pci_set_power_state(), but that's not a very good place because it's not really related to setting the PCI device power state, and doing it there means: - We incorrectly skipped ASPM config when setting a device that's already in D0 to D0. - We unnecessarily configured ASPM when setting a device to a low-power state (the ASPM feature only applies when the device is in D0). - We unnecessarily configured ASPM when called from a .resume() method (ASPM configuration needs to be restored during resume, but pci_restore_pcie_state() should already do this). Move ASPM configuration from pci_set_power_state() to do_pci_enable_device() so we do it when a driver enables a device. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621 Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Vidya Sagar <sagar.tv@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.6+
|
#
9e33002f |
|
19-Jun-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
PCI: Make resetting secondary bus logic common Commit d92a208d086 ("powerpc/pci: Mask linkDown on resetting PCI bus") implemented same logic (resetting PCI secondary bus by bridge's config register PCI_BRIDGE_CTL_BUS_RESET) in PCI core and arch-dependent code. To avoid the duplication, move the logic to pci_reset_secondary_bus(). That commit did not declare the pcibios_reset_secondary_bus() interface in linux/include/pci.h. Add the declaration. No functional change. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d066c946 |
|
17-Jun-2014 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Fix unaligned access in AF transaction pending test pci_wait_for_pending() uses word access, so we shouldn't be passing an offset that is only byte aligned. Use the control register offset instead, shifting the mask to match. Fixes: d0b4cc4e3270 ("PCI: Wrong register used to check pending traffic") Fixes: 157e876ffe0b ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com> CC: stable@vger.kernel.org # v3.14+
|
#
227f0647 |
|
18-Apr-2014 |
Ryan Desfosses <ryan@desfo.org> |
PCI: Merge multi-line quoted strings Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3c78bc61 |
|
18-Apr-2014 |
Ryan Desfosses <ryan@desfo.org> |
PCI: Whitespace cleanup Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b7fe9434 |
|
25-Apr-2014 |
Ryan Desfosses <ryan@desfo.org> |
PCI: Move EXPORT_SYMBOL so it immediately follows function/variable Move EXPORT_SYMBOL so it immediately follows the function or variable. No functional change. [bhelgaas: squash similar changes, fix hotplug, probe, rom, search, too] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a43ae58c |
|
05-May-2014 |
Hanjun Guo <guohanjun@huawei.com> |
PCI: Turn pcibios_penalize_isa_irq() into a weak function pcibios_penalize_isa_irq() is only implemented by x86 now, and legacy ISA is not used by some architectures. Make pcibios_penalize_isa_irq() a __weak function to simplify the code. This removes the need for new platforms to add stub implementations of pcibios_penalize_isa_irq(). [bhelgaas: changelog, comments] Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
|
#
3ebe7f9f |
|
02-May-2014 |
Keith Busch <kbusch@kernel.org> |
PCI: Notify driver before and after device reset Notify a PCI device driver when its device's access is about to be disabled for an impending reset attempt, then after the attempt completes and device access is restored. The notification is via the pci_error_handlers interface. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d0b4cc4e |
|
18-May-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
PCI: Wrong register used to check pending traffic The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Williamson <alex.williamson@gmail.com> CC: stable@vger.kernel.org # v3.14+
|
#
07656d8308 |
|
10-Apr-2014 |
Ryan Desfosses <ryan@desfo.org> |
pci: change "foo* bar" to "foo *bar" change made to resolve following checkpatch message: drivers/pci/pci.c:109: ERROR: "foo* bar" should be "foo *bar" branch: Linux 3.14-rc8 Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d92a208d |
|
24-Apr-2014 |
Gavin Shan <gwshan@linux.vnet.ibm.com> |
powerpc/pci: Mask linkDown on resetting PCI bus The problem was initially reported by Wendy who tried pass through IPR adapter, which was connected to PHB root port directly, to KVM based guest. When doing that, pci_reset_bridge_secondary_bus() was called by VFIO driver and linkDown was detected by the root port. That caused all PEs to be frozen. The patch fixes the issue by routing the reset for the secondary bus of root port to underly firmware. For that, one more weak function pci_reset_secondary_bus() is introduced so that the individual platforms can override that and do specific reset for bridge's secondary bus. Reported-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
67ebd814 |
|
05-Apr-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix incorrect vgaarb conditional in WARN_ON() 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the condition is never true. Replace with logical AND. Found by Coverity (CID 142811). Fixes: 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: David Airlie <airlied@redhat.com>
|
#
8a9d5609 |
|
26-Feb-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add "weak" generic pcibios_enable_device() implementation Many architectures implement pcibios_enable_device() the same way, so provide a default implementation in the core. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3cdeb713 |
|
11-Mar-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left them disabled"), pciehp surprise removal stopped working. This happens because pci_reenable_device() on the hotplug bridge (used in the pciehp_configure_device() path) clears the Interrupt Disable bit, which apparently breaks the bridge's MSI hotplug event reporting. Previously we cleared the Interrupt Disable bit in do_pci_enable_device(), which is used by both pci_enable_device() and pci_reenable_device(). But we use pci_reenable_device() after the driver may have enabled MSI or MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X. This patch clears Interrupt Disable only when MSI/MSI-X has not been enabled. Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691 Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
866d5417 |
|
07-Mar-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left them disabled"), pciehp surprise removal stopped working. This happens because pci_reenable_device() on the hotplug bridge (used in the pciehp_configure_device() path) clears the Interrupt Disable bit, which apparently breaks the bridge's MSI hotplug event reporting. Previously we cleared the Interrupt Disable bit in do_pci_enable_device(), which is used by both pci_enable_device() and pci_reenable_device(). But we use pci_reenable_device() after the driver may have enabled MSI or MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X. This patch clears Interrupt Disable only when MSI/MSI-X has not been enabled. Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691 Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
bd064f0a |
|
26-Feb-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Mark resources as IORESOURCE_UNSET if we can't assign them When assigning addresses to resources, mark them with IORESOURCE_UNSET before we start and clear IORESOURCE_UNSET if assignment is successful. That means that if we print the resource during assignment, we will show the size, not a meaningless address. Also, clear IORESOURCE_UNSET if we do assign an address, so we print the address when it is valid. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f44116ae |
|
26-Feb-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove pci_find_parent_resource() use for allocation If the resource hasn't been allocated yet, pci_find_parent_resource() is documented as returning the region "where it should be allocated from." This is impossible in general because there may be several candidates: a prefetchable BAR can be put in either a prefetchable or non-prefetchable window, a transparent bridge may have overlapping positively- and subtractively-decoded windows, and a root bus may have several windows of the same type. Allocation should be done by pci_bus_alloc_resource(), which iterates through all bus resources and looks for the best match, e.g., one with the desired prefetchability attributes, and falls back to less-desired possibilities. The only valid use of pci_find_parent_resource() is to find the parent of an already-allocated resource so we can claim it via request_resource(), and all we need for that is a bus region of the correct type that contains the resource. Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable resources to non-prefetchable windows"), this depends on pci_bus_for_each_resource() iterating through positively-decoded regions before subtractively-decoded ones. We prefer not to return a subtractively-decoded region because requesting from it will likely conflict with the overlapping positively- decoded window (see Launchpad report below). Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Linus Torvalds <torvalds@linux-foundation.org>
|
#
1e2571a7 |
|
29-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Enable INTx if BIOS left them disabled Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
1f42db78 |
|
14-Feb-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Enable INTx if BIOS left them disabled Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
94e6a9b9 |
|
13-Feb-2014 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Remove pci_bus_b() and use list_for_each_entry() directly Replace list_for_each() with list_for_each_entry(), which means we no longer need pci_bus_b() and can remove it. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2c744244 |
|
03-Feb-2014 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add device-specific PCI ACS enable Some devices support PCI ACS-like features, but don't report it using the standard PCIe capabilities. We already provide hooks for device-specific testing of ACS, but not for device-specific enabling of ACS. This provides that setup hook. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ce300008 |
|
24-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove unnecessary list_empty(&pci_pme_list) check list_for_each_entry() handles empty lists just fine, so there's no need to check whether the list is empty first. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
|
#
ebd50b93 |
|
14-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix pci_check_and_unmask_intx() comment typos Fix typos in pci_check_and_unmask_intx() function comment. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
61cf16d8 |
|
16-Dec-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus() When doing a function/slot/bus reset PCI grabs the device_lock for each device to block things like suspend and driver probes, but call paths exist where this lock may already be held. This creates an opportunity for deadlock. For instance, vfio allows userspace to issue resets so long as it owns the device(s). If a driver unbind .remove callback races with userspace issuing a reset, we have a deadlock as userspace gets stuck waiting on device_lock while another thread has device_lock and waits for .remove to complete. To resolve this, we can make a version of the reset interfaces which use trylock. With this, we can safely attempt a reset and return error to userspace if there is contention. [bhelgaas: the deadlock happens when A (userspace) has a file descriptor for the device, and B waits in this path: driver_detach device_lock # take device_lock __device_release_driver pci_device_remove # pci_bus_type.remove vfio_pci_remove # pci_driver .remove vfio_del_group_dev wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock) Now B is stuck until A gives up the file descriptor. If A tries to acquire device_lock for any reason, we deadlock because A is waiting for B to release the lock, and B is waiting for A to release the file descriptor.] Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
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>
|
#
7c2dd2d7 |
|
10-Jan-2014 |
Stephen Hemminger <stephen@networkplumber.org> |
PCI: Remove unused ID-Based Ordering support My philosophy is unused code is dead code. And dead code is subject to bit rot and is a likely source of bugs. Use it or lose it. This reverts b48d4425b602 ("PCI: add ID-based ordering enable/disable support"), removing these interfaces: pci_enable_ido() pci_disable_ido() [bhelgaas: split to separate patch, also remove prototypes from pci.h] Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ecc86356 |
|
10-Jan-2014 |
Stephen Hemminger <stephen@networkplumber.org> |
PCI: Remove unused Optimized Buffer Flush/Fill support My philosophy is unused code is dead code. And dead code is subject to bit rot and is a likely source of bugs. Use it or lose it. This reverts 48a92a8179b3 ("PCI: add OBFF enable/disable support"), removing these interfaces: pci_enable_obff() pci_disable_obff() [bhelgaas: split to separate patch, also remove prototypes from pci.h] Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
3ea8197e |
|
10-Jan-2014 |
Stephen Hemminger <stephen@networkplumber.org> |
PCI: Remove unused Latency Tolerance Reporting support My philosophy is unused code is dead code. And dead code is subject to bit rot and is a likely source of bugs. Use it or lose it. This reverts 51c2e0a7e5bc ("PCI: add latency tolerance reporting enable/disable support"), removing these interfaces: pci_enable_ltr() pci_disable_ltr() pci_set_ltr() [bhelgaas: split to separate patch, also remove prototypes from pci.h] Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
425c1b22 |
|
17-Dec-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add Virtual Channel to save/restore support While we don't really have any infrastructure for making use of VC support, the system BIOS can configure the topology to non-default VC values prior to boot. This may be due to silicon bugs, desire to reserve traffic classes, or perhaps just BIOS bugs. When we reset devices, the VC configuration may return to default values, which can be incompatible with devices upstream. For instance, Nvidia GRID cards provide a PCIe switch and some number of GPUs, all supporting VC. The power-on default for VC is to support TC0-7 across VC0, however some platforms will only enable TC0/VC0 mapping across the topology. When we do a secondary bus reset on the downstream switch port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end of the link only enables TC0/VC0. If the GPU attempts to use TC1-7, it fails. This patch attempts to provide complete support for VC save/restore, even beyond the minimally required use case above. This includes save/restore and reload of the arbitration table, save/restore and reload of the port arbitration tables, and re-enabling of the channels for VC, VC9, and MFVC capabilities. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fd0f7f73 |
|
17-Dec-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add support for save/restore of extended capabilities Current save/restore is specific to standard capabilities. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
157e876f |
|
17-Dec-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) We currently have two instance of this loop which waits for a pending bit to clear in a status dword. Generalize the function for future users. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8496e85c |
|
30-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / tg3: Give up chip reset and carrier loss handling if PCI device is not present Modify tg3_chip_reset() and tg3_close() to check if the PCI network adapter device is accessible at all in order to skip poking it or trying to handle a carrier loss in vain when that's not the case. Introduce a special PCI helper function pci_device_is_present() for this purpose. Of course, this uncovers the lack of the appropriate RTNL locking in tg3_suspend() and tg3_resume(), so add that locking in there too. These changes prevent tg3 from burning a CPU at 100% load level for solid several seconds after the Thunderbolt link is disconnected from a Matrox DS1 docking station. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f7625980 |
|
14-Nov-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix whitespace, capitalization, and spelling errors Fix whitespace, capitalization, and spelling errors. No functional change. I know "busses" is not an error, but "buses" was more common, so I used it consistently. Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus()) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
79272138 |
|
06-Nov-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Enable upstream bridges even for VFs on virtual buses Previously we enabled the upstream PCI-to-PCI bridge only when "dev->bus->self != NULL". In the case of a VF on a virtual bus, where "bus->self == NULL", we didn't enable the upstream bridge. This fixes that by enabling the upstream bridge of the PF corresponding to the VF. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
|
#
fbeeb822 |
|
05-Nov-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Drop warning about drivers that don't use pci_set_master() f41f064cf4 ("PCI: Workaround missing pci_set_master in pci drivers") made pci_enable_bridge() turn on bus mastering if the driver hadn't done so already. It also added a warning in this case. But there's no reason to warn about it unless it's actually a problem to enable bus mastering here. This patch drops the warning because I'm not aware of any such problem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Paul Bolle <pebolle@tiscali.nl>
|
#
cf3e1feb |
|
05-Nov-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Workaround missing pci_set_master in pci drivers Ben Herrenschmidt found that commit 928bea964827 ("PCI: Delay enabling bridges until they're needed") breaks PCI in some powerpc environments. The reason is that the PCIe port driver will call pci_enable_device() on the bridge, so the device is enabled, but skips pci_set_master because pcie_port_auto and no acpi on powerpc. Because of that, pci_enable_bridge() later on (called as a result of the child device driver doing pci_enable_device) will see the bridge as already enabled and will not call pci_set_master() on it. Fixed by add checking in pci_enable_bridge, and call pci_set_master if driver skip that. That will make the code more robot and wade off problem for missing pci_set_master in drivers. Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0394cb19 |
|
16-Oct-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Report pci_pme_active() kmalloc failure Previously, if kmalloc() failed, we claimed "PME# enabled" in dmesg, even though we didn't add the device to the pci_pme_list. This prints a more correct warning. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f41f064c |
|
28-Sep-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Workaround missing pci_set_master in pci drivers Ben Herrenschmidt found that commit 928bea964827 ("PCI: Delay enabling bridges until they're needed") breaks PCI in some powerpc environments. The reason is that the PCIe port driver will call pci_enable_device() on the bridge, so the device is enabled, but skips pci_set_master because pcie_port_auto and no acpi on powerpc. Because of that, pci_enable_bridge() later on (called as a result of the child device driver doing pci_enable_device) will see the bridge as already enabled and will not call pci_set_master() on it. Fixed by add checking in pci_enable_bridge, and call pci_set_master if driver skip that. That will make the code more robot and wade off problem for missing pci_set_master in drivers. Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a006482b |
|
23-Sep-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Drop "setting latency timer" messages This message isn't useful any more, so drop it. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60636 Reported-by: Oleksil Shevchuk <alxchk@gmail.com> Reference: http://lkml.kernel.org/r/CALCETrWkr53ZjqdN3t7rTTfr=+ZKZXJoYsuBcwPf0kN_33GfAw@mail.gmail.com Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f1c66c46 |
|
24-Sep-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Export pcie_set_mps() and pcie_get_mps() Export pcie_get_mps() and pcie_set_mps() functions so drivers can use them to simplify code. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d2ab1fa6 |
|
27-Aug-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Rename PCIe capability definitions to follow convention All other PCIe capability register fields include "PCI_EXP" + <reg-name> + <field-name>. This renames PCI_EXP_OBFF_MASK, PCI_EXP_IDO_REQ_EN, PCI_EXP_LTR_EN, and related fields using the same convention. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> # for MFD driver
|
#
da27f4b3 |
|
22-Aug-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add comment about needing pci_msi_off() even when CONFIG_PCI_MSI=n Per f5f2b13129 ("msi: sanely support hardware level msi disabling"), we want pci_msi_off() to work even if MSI support is not compiled into the kernel, and there are existing callers that use it when CONFIG_PCI_MSI=n. This adds a comment to that effect. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f6757711 |
|
21-Aug-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Remove unnecessary check for pcie_get_mps() failure After 59875ae489 ("PCI/core: Use PCI Express Capability accessors"), pcie_get_mps() never returns an error, so don't bother to check for it. No functional change. [bhelgaas: changelog, fix pcie_get_mps() doc] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9a3d2b9b |
|
14-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add pci_probe_reset_slot() and pci_probe_reset_bus() Users of pci_reset_bus() and pci_reset_slot() need a way to probe whether the bus or slot supports reset. Add trivial helper functions and export them as vfio-pci will make use of these. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
de0c548c |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Tune secondary bus reset timing The PCI spec indicates that with stable power, reset needs to be asserted for a minimum of 1ms (Trst). We should be able to assume stable power for a Hot Reset, but we add another millisecond as a fudge factor to make sure the reset is seen on the bus for at least a full 1ms. After reset is de-asserted we must wait for devices to complete initialization. The specs refer to this as "recovery time" (Trhfa). For PCI this is 2^25 clock cycles or 2^26 for PCI-X. For minimum bus speeds, both of those come to 1s. PCIe "softens" this requirement with the Configuration Request Retry Status (CRS) completion status. Theoretically we could use CRS to shorten the wait time. We don't make use of that here, using a fixed 1s delay to allow devices to re-initialize. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a6cbaade |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Wake-up devices before saving config space for reset Devices come out of reset in D0. Restoring a device to a different post-reset state takes more smarts than our simple config space restore, which can leave devices in an inconsistent state. For example, if a device is reset in D3, but the restore doesn't successfully return the device to D3, then the actual state of the device and dev->current_state are contradictory. Put everything in D0 going into the reset, then we don't need to do anything special on the way out. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
090a3c53 |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add pci_reset_slot() and pci_reset_bus() Sometimes pci_reset_function() is not sufficient. We have cases where devices do not support any kind of reset, but there might be multiple functions on the bus preventing pci_reset_function() from doing a secondary bus reset. We also have cases where a device will advertise that it supports a PM reset, but really does nothing on D3hot->D0 (graphics cards are notorious for this). These devices often also have more than one function, so even blacklisting PM reset for them wouldn't allow a secondary bus reset through pci_reset_function(). If a driver supports multiple devices it should have the ability to induce a bus reset when it needs to. This patch provides that ability through pci_reset_slot() and pci_reset_bus(). It's the caller's responsibility when using these interfaces to understand that all of the devices in or below the slot (or on or below the bus) will be reset and therefore should be under control of the caller. PCI state of all the affected devices is saved and restored around these resets, but internal state of all of the affected devices is reset (which should be the intention). Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
77cb985a |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Split out pci_dev lock/unlock and save/restore Only cosmetic code changes to existing paths. Expand the comment in the new pci_dev_save_and_disable() function since there's a lot hidden in that Command register write. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
608c3881 |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add slot reset option to pci_dev_reset() If the hotplug controller provides a way to reset a slot, use that before a direct parent bus reset. Like the bus reset option, this is only available when a single pci_dev occupies the slot. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3775a209 |
|
06-Aug-2013 |
Casey Leedom <leedom@chelsio.com> |
PCI: Add pci_wait_for_pending_transaction() New routine to avoid duplication of code to wait for pending PCI transactions to complete. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Vipul Pandya <vipul@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
64e8674f |
|
08-Aug-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add pci_reset_bridge_secondary_bus() Move the secondary bus reset code from pci_parent_bus_reset() into its own function. Export it as we'll later be calling it from hotplug controllers and elsewhere. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ce1be10b |
|
01-Aug-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Fix comment typo for pci_add_cap_save_buffer() Fix trivial comment typo for pci_add_cap_save_buffer(). Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
81377c8d |
|
31-Jul-2013 |
Jacob Keller <jacob.e.keller@intel.com> |
PCI: Add function to obtain minimum link width and speed A PCI Express device can potentially report a link width and speed which it will not properly fulfill due to being plugged into a slower link higher in the chain. This function walks up the PCI bus chain and calculates the minimum link width and speed of this entire chain. This can be useful to enable a device to determine if it has enough bandwidth for optimum functionality. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
#
928bea96 |
|
22-Jul-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Delay enabling bridges until they're needed We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code. This patch changes this so we don't enable a bridge until necessary, i.e., until we enable a PCI device behind the bridge. We do this in the generic pci_enable_device() path, so this also removes the arch-specific code to enable bridges. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
83db7e0b |
|
27-Jun-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Differentiate ACS controllable from enabled We currently misinterpret that in order for an ACS feature to be enabled it must be set in the control field. In reality, this means that the feature is not only enabled, but controllable. Many of the ACS capability bits are not required if the device behaves by default in the way specified when both the capability and control bit are set and does not support or allow the alternate mode. We therefore need to check the capabilities and mask out flags that are enabled but not controllable. Egress control seems to be the only flag which is purely optional. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Donald Dutile <ddutile@redhat.com>
|
#
0a67119f |
|
27-Jun-2013 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Check all ACS features for multifunction downstream ports The multifunction ACS rules do not apply to downstream ports. Those should be tested regardless of whether they are single function or multifunction. The PCIe spec also fully specifies which PCIe types are subject to the multifunction rules and excludes event collectors and PCIe-to-PCI bridges entirely. Document each rule to the section of the PCIe spec and provide overall documentation of the function. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Donald Dutile <ddutile@redhat.com>
|
#
44b9ca47 |
|
05-Jun-2013 |
Sebastian Ott <sebott@linux.vnet.ibm.com> |
pci: add pcibios_release_device Platforms may want to provide architecture-specific functionality when a pci device is released. Add a pcibios_release_device() call that architectures can override to do so. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
#
728cdb75 |
|
18-Jun-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM) PCI PM cap register offset has been saved in pci_pm_init(), so we can use pdev->pm_cap instead of using pci_find_capability(..) here. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6ae32c53 |
|
04-Jun-2013 |
Sebastian Ott <sebott@linux.vnet.ibm.com> |
PCI: Add pcibios_release_device() Platforms may want to provide architecture-specific functionality when a PCI device is released. Add a pcibios_release_device() call that architectures can override to do so. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
bb5c2de2 |
|
27-May-2013 |
Wang Sheng-Hui <shhuiw@gmail.com> |
PCI: Fix INTC comment typo for pci_swizzle_interrupt_pin() The INTx pin should be INIT[ABCD]. Fix the typo "3=INTC". Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ffaddbe8 |
|
10-Apr-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Make pci_pme_active() ignore devices without PME support Make pci_pme_active() ignore devices without PME support, so that it doesn't print the "PME enabled" or "PME disabled" debug messages for devices that don't support PME. So that pci_pme_active() doesn't have to check pm_cap in addition to pme_support, make pci_pm_init() clear pme_support upfront to make sure that it will be 0 for pm_cap equal to 0. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
769ba721 |
|
12-Apr-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI/PM: Fix fallback to PCI_D0 in pci_platform_power_transition() Commit b51306c (PCI: Set device power state to PCI_D0 for device without native PM support) modified pci_platform_power_transition() by adding code causing dev->current_state for devices that don't support native PCI PM but are power-manageable by the platform to be changed to PCI_D0 regardless of the value returned by the preceding platform_pci_set_power_state(). In particular, that also is done if the platform_pci_set_power_state() has been successful, which causes the correct power state of the device set by pci_update_current_state() in that case to be overwritten by PCI_D0. Fix that mistake by making the fallback to PCI_D0 only happen if the platform_pci_set_power_state() has returned an error. [bhelgaas: folded in Yinghai's simplification, added URL & stable info] Reference: http://lkml.kernel.org/r/27806FC4E5928A408B78E88BBC67A2306F466BBA@ORSMSX101.amr.corp.intel.com Reported-by: Chris J. Benenati <chris.j.benenati@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: <stable@vger.kernel.org> # v3.2+
|
#
9738abed |
|
12-Apr-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Make local functions/structs static This fixes "no previous prototype" warnings found via "make W=1". Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b67bfe0d |
|
27-Feb-2013 |
Sasha Levin <sasha.levin@oracle.com> |
hlist: drop the node parameter from iterators I'm not sure why, but the hlist for each entry iterators were conceived list_for_each_entry(pos, head, member) The hlist ones were greedy and wanted an extra parameter: hlist_for_each_entry(tpos, pos, head, member) Why did they need an extra pos parameter? I'm not quite sure. Not only they don't really need it, it also prevents the iterator from looking exactly like the list iterator, which is unfortunate. Besides the semantic patch, there was some manual work required: - Fix up the actual hlist iterators in linux/list.h - Fix up the declaration of other iterators based on the hlist ones. - A very small amount of places were using the 'node' parameter, this was modified to use 'obj->member' instead. - Coccinelle didn't handle the hlist_for_each_entry_safe iterator properly, so those had to be fixed up manually. The semantic patch which is mostly the work of Peter Senna Tschudin is here: @@ iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host; type T; expression a,c,d,e; identifier b; statement S; @@ -T b; <+... when != b ( hlist_for_each_entry(a, - b, c, d) S | hlist_for_each_entry_continue(a, - b, c) S | hlist_for_each_entry_from(a, - b, c) S | hlist_for_each_entry_rcu(a, - b, c, d) S | hlist_for_each_entry_rcu_bh(a, - b, c, d) S | hlist_for_each_entry_continue_rcu_bh(a, - b, c) S | for_each_busy_worker(a, c, - b, d) S | ax25_uid_for_each(a, - b, c) S | ax25_for_each(a, - b, c) S | inet_bind_bucket_for_each(a, - b, c) S | sctp_for_each_hentry(a, - b, c) S | sk_for_each(a, - b, c) S | sk_for_each_rcu(a, - b, c) S | sk_for_each_from -(a, b) +(a) S + sk_for_each_from(a) S | sk_for_each_safe(a, - b, c, d) S | sk_for_each_bound(a, - b, c) S | hlist_for_each_entry_safe(a, - b, c, d, e) S | hlist_for_each_entry_continue_rcu(a, - b, c) S | nr_neigh_for_each(a, - b, c) S | nr_neigh_for_each_safe(a, - b, c, d) S | nr_node_for_each(a, - b, c) S | nr_node_for_each_safe(a, - b, c, d) S | - for_each_gfn_sp(a, c, d, b) S + for_each_gfn_sp(a, c, d) S | - for_each_gfn_indirect_valid_sp(a, c, d, b) S + for_each_gfn_indirect_valid_sp(a, c, d) S | for_each_host(a, - b, c) S | for_each_host_safe(a, - b, c, d) S | for_each_mesh_entry(a, - b, c, d) S ) ...+> [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c] [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c] [akpm@linux-foundation.org: checkpatch fixes] [akpm@linux-foundation.org: fix warnings] [akpm@linux-foudnation.org: redo intrusive kvm changes] Tested-by: Peter Senna Tschudin <peter.senna@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Gleb Natapov <gleb@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
cc7ba39b |
|
11-Feb-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use atomic_inc_return() rather than atomic_add_return() No functional change; just use atomic_inc_return() rather than the general-purpose atomic_add_return(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fd6dceab |
|
04-Feb-2013 |
Konstantin Khlebnikov <khlebnikov@openvz.org> |
PCI: Catch attempts to disable already-disabled devices Warn when disabling a device that has already been disabled. [bhelgaas: message wording] Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.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>
|
#
10c463a7 |
|
18-Mar-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Kill pci_is_reassigndev() pci_reassigndev_resource_alignment() is the only user of pci_is_reassigndev(). If we just use pci_specified_resource_alignment() directly, we only need to call it once instead of twice, and we can get rid of pci_is_reassigndev() altogether. No functional change. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b0cc6020 |
|
14-Jan-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Enable ARI if dev and upstream bridge support it; disable otherwise Currently, we enable ARI in a device's upstream bridge if the bridge and the device support it. But we never disable ARI, even if the device is removed and replaced with a device that doesn't support ARI. This means that if we hot-remove an ARI device and replace it with a non-ARI multi-function device, we find only function 0 of the new device because the upstream bridge still has ARI enabled, and next_ari_fn() only returns function 0 for the new non-ARI device. This patch disables ARI in the upstream bridge if the device doesn't support ARI. See the PCIe spec, r3.0, sec 6.13. [bhelgaas: changelog, function comment] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b4b4fbba |
|
04-Jan-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Drop "__" prefix on __pci_enable_device_flags() Drop the useless "__" prefix on __pci_enable_device_flags(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f7ffe19a |
|
04-Jan-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use "unsigned long" for __pci_enable_device_flags to match ioport.h __pci_enable_device_flags() takes values like IORESOURCE_IO and IORESOURCE_MEM, which are values for struct resource.flags, which is "unsigned long", not "resource_size_t". 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>
|
#
eca0d467 |
|
05-Dec-2012 |
Matthew Garrett <mjg@redhat.com> |
PCI: Add pcibios_add_device Platforms may want to provide architecture-specific functionality during PCI enumeration. Add a pcibios_add_device() call that architectures can override to do so. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Seth Forshee <seth.forshee@canonical.com>
|
#
967577b0 |
|
20-Nov-2012 |
Huang Ying <ying.huang@intel.com> |
PCI/PM: Keep runtime PM enabled for unbound PCI devices For unbound PCI devices, what we need is: - Always in D0 state, because some devices do not work again after being put into D3 by the PCI bus. - In SUSPENDED state if allowed, so that the parent devices can still be put into low power state. To satisfy these requirements, the runtime PM for the unbound PCI devices are disabled and set to SUSPENDED state. One issue of this solution is that the PCI devices will be put into SUSPENDED state even if the SUSPENDED state is forbidden via the sysfs interface (.../power/control) of the device. This is not an issue for most devices, because most PCI devices are not used at all if unbound. But there are exceptions. For example, unbound VGA card can be used for display, but suspending its parents makes it stop working. To fix the issue, we keep the runtime PM enabled when the PCI devices are unbound. But the runtime PM callbacks will do nothing if the PCI devices are unbound. This way, we can put the PCI devices into SUSPENDED state without putting the PCI devices into D3 state. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201 Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+
|
#
15856ad5 |
|
21-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
PCI: Remove __dev* markings CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint, __devinitdata, __devinitconst, and _devexit are no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6e965e0d |
|
25-Oct-2012 |
Huang Ying <ying.huang@intel.com> |
PCI/PM: Add comments for PME poll support for PCIe There are comments on why PME poll support is necessary for PCI devices, but not for PCIe devices. That may lead to misunderstanding that PME poll is only necessary for PCI devices. So add comments related to PCIe PME poll to make it more clear. The content of comments comes from the changelog of commit: 379021d5c0899fcf9410cae4ca7a59a5a94ca769 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>
|
#
642c92da |
|
30-Oct-2012 |
Taku Izumi <izumi.taku@jp.fujitsu.com> |
PCI: Don't pass pci_dev to pci_ext_cfg_avail() pci_ext_cfg_avail() doesn't use the "struct pci_dev *" passed to it, and there's no requirement that a host bridge even be represented by a pci_dev. This drops the pci_ext_cfg_avail() parameter. [bhelgaas: changelog] Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> 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+
|
#
59875ae4 |
|
24-Jul-2012 |
Jiang Liu <jiang.liu@huawei.com> |
PCI/core: Use PCI Express Capability accessors Use PCI Express Capability access functions to simplify core. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
62f87c0e |
|
24-Jul-2012 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Introduce pci_pcie_type(dev) to replace pci_dev->pcie_type Introduce an inline function pci_pcie_type(dev) to extract PCIe device type from pci_dev->pcie_flags_reg field, and prepare for removing pci_dev->pcie_type. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
44a9a36f |
|
13-Jul-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add pci_find_next_ext_capability() Some extended capabilities, e.g., the vendor-specific capability, can occur several times. The existing pci_find_ext_capability() only finds the first occurrence. This adds pci_find_next_ext_capability(), which can iterate through all of them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ceaf5b5f |
|
18-Aug-2012 |
Randy Dunlap <rdunlap@infradead.org> |
PCI: Fix drivers/pci/pci.c kernel-doc warnings Fix kernel-doc warnings in drivers/pci/pci.c: Warning(drivers/pci/pci.c:1550): No description found for parameter 'pci_dev' Warning(drivers/pci/pci.c:1550): Excess function parameter 'dev' description in 'pci_wakeup' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
4f9c1397 |
|
07-Aug-2012 |
Huang Ying <ying.huang@intel.com> |
PCI/PM: Enable D3/D3cold by default for most devices This patch fixes the following bug: http://marc.info/?l=linux-usb&m=134318961120825&w=2 Originally, device lower power states include D1, D2, D3. After that, D3 is further divided into D3hot and D3cold. To support both scenario safely, original D3 is mapped to D3cold. When adding D3cold support, because worry about some device may have broken D3cold support, D3cold is disabled by default. This disable D3 on original platform too. But some original platform may only have working D3, but no working D1, D2. The root cause of the above bug is it too. To deal with this, this patch enables D3/D3cold by default for most devices. This restores the original behavior. For some devices that suspected to have broken D3cold support, such as PCIe port, D3cold is disabled by default. Reported-by: Bjorn Mork <bjorn@mork.no> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
dbf0e4c7 |
|
09-Jul-2012 |
Alan Stern <stern@rowland.harvard.edu> |
PCI: EHCI: fix crash during suspend on ASUS computers Quite a few ASUS computers experience a nasty problem, related to the EHCI controllers, when going into system suspend. It was observed that the problem didn't occur if the controllers were not put into the D3 power state before starting the suspend, and commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers) was created to do this. It turned out this approach messed up other computers that didn't have the problem -- it prevented USB wakeup from working. Consequently commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it reverted the earlier commit and added a whitelist of known good board names. Now we know the actual cause of the problem. Thanks to AceLan Kao for tracking it down. According to him, an engineer at ASUS explained that some of their BIOSes contain a bug that was added in an attempt to work around a problem in early versions of Windows. When the computer goes into S3 suspend, the BIOS tries to verify that the EHCI controllers were first quiesced by the OS. Nothing's wrong with this, but the BIOS does it by checking that the PCI COMMAND registers contain 0 without checking the controllers' power state. If the register isn't 0, the BIOS assumes the controller needs to be quiesced and tries to do so. This involves making various MMIO accesses to the controller, which don't work very well if the controller is already in D3. The end result is a system hang or memory corruption. Since the value in the PCI COMMAND register doesn't matter once the controller has been suspended, and since the value will be restored anyway when the controller is resumed, we can work around the BIOS bug simply by setting the register to 0 during system suspend. This patch (as1590) does so and also reverts the second commit mentioned above, which is now unnecessary. In theory we could do this for every PCI device. However to avoid introducing new problems, the patch restricts itself to EHCI host controllers. Finally the affected systems can suspend with USB wakeup working properly. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728 Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Javier Marcet <jmarcet@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel <bug-track@fisher-privat.net> Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Cc: stable <stable@vger.kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
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>
|
#
2b6f2c35 |
|
25-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: pull pcibios_setup() up into core Currently, all of the architectures implement their own pcibios_setup() routine. Most of the implementations do nothing so this patch introduces a generic (__weak) routine in the core that can be used by all architectures as a default. If necessary, it can be overridden by architecture-specific code. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> 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>
|
#
71a83bd7 |
|
22-Jun-2012 |
Zheng Yan <zheng.z.yan@intel.com> |
PCI/PM: add runtime PM support to PCIe port This patch adds runtime PM support to PCIe port. This is needed by PCIe D3cold support, where PCIe device without ACPI node may be powered on/off by PCIe port. Because runtime suspend is broken for some chipsets, a black list is used to disable runtime PM support for these chipsets. Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-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>
|
#
809a3bf9 |
|
20-Jun-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: remove useless pcix_set_mmrbc() dev->bus check For a valid pci_dev, dev->bus != NULL always, so remove this unnecessary test. Found by Coverity (CID 101680). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8291550f |
|
19-Jun-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: fix upstream P2P bridge checks when enabling OBFF and LTR pci_enable_obff() and pci_enable_ltr() incorrectly check "dev->bus" instead of "dev->bus->self" to determine whether the upstream device is a P2P bridge or a host bridge. For devices on the root bus, the upstream device is a host bridge, "dev->bus != NULL" and "dev->bus->self == NULL", and we panic with a null pointer dereference. These functions should previously have panicked when called on devices supporting OBFF or LTR, so they should be regarded as untested. Found by Coverity (CID 143038 and CID 143039). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d6d88c83 |
|
19-Jun-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: use __weak consistently Use "__weak" instead of the gcc-specific "__attribute__ ((weak))" Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fbebb9fd |
|
16-Jun-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: add infrastructure for devices with broken INTx masking pci_intx_mask_supported() assumes INTx masking is supported if the PCI_COMMAND_INTX_DISABLE bit is writable. But when that bit is set, some devices don't actually mask INTx or update PCI_STATUS_INTERRUPT as we expect. This patch adds a way for quirks to identify these broken devices. [bhelgaas: split out from Chelsio quirk addition] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b918c62e |
|
17-May-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: replace struct pci_bus secondary/subordinate with busn_res Replace the struct pci_bus secondary/subordinate members with the struct resource busn_res. Later we'll build a resource tree of these bus numbers. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c2fb8a3f |
|
13-Jun-2012 |
Alan Stern <stern@rowland.harvard.edu> |
USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2 This patch (as1558) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. A similar patch has already been applied as commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers). The patch supersedes that one and reverts it. There are two differences: The old patch added the flag at the USB level; this patch adds it at the PCI level. The old patch applied to all chipsets with the same vendor, subsystem vendor, and product IDs; this patch makes an exception for a known-good system (based on DMI information). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ad805758 |
|
10-Jun-2012 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: add ACS validation utility In a PCI environment, transactions aren't always required to reach the root bus before being re-routed. Intermediate switches between an endpoint and the root bus can redirect DMA back downstream before things like IOMMUs have a chance to intervene. Legacy PCI is always susceptible to this as it operates on a shared bus. PCIe added a new capability to describe and control this behavior, Access Control Services, or ACS. The utility function pci_acs_enabled() allows us to test the ACS capabilities of an individual devices against a set of flags while pci_acs_path_enabled() tests a complete path from a given downstream device up to the specified upstream device. We also include the ability to add device specific tests as it's likely we'll see devices that do not implement ACS, but want to indicate support for various capabilities in this space. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9cb604ed |
|
01-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: remove redundant capabilities checking in pci_{save, restore}_pcie_state Unlike PCI Express v1's Capabilities Structure, v2's requires the entire structure to be implemented. In v2 structures, register fields that are not implemented are present but hardwired to 0x0. These may include: Link Capabilities, Status, and Control; Slot Capabilities, Status, and Control; Root Capabilities, Status, and Control; and all of the '2' (Device, Link, and Slot) Capabilities, Status, and Control registers. This patch removes the redundant capability checks corresponding to the Link 2's and Slot 2's, Capabilities, Status, and Control registers as they will be present if Device Capabilities 2's registers are (which explains why the macros for each of the three are identical). Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c463b8cb |
|
01-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: add pci_pcie_cap2() check for PCIe feature capabilities >= v2 This patch resolves potential issues when accessing PCI Express Capability structures. The makeup of the capability varies substantially between v1 and v2: Version 1 of the PCI Express Capability (defined by PCI Express 1.0 and 1.1 base) neither requires the endpoint to implement the entire PCIe capability structure nor specifies default values of registers that are not implemented by the device. Version 2 of the PCI Express Capability (defined by PCIe 1.1 Capability Structure Expansion ECN, PCIe 2.0, 2.1, and 3.0) added additional registers to the structure and requires all registers to be either implemented or hardwired to 0. Due to the differences in the capability structures, code dealing with capability features must be careful not to access the additional registers introduced with v2 unless the device is specifically known to be a v2 capable device. Otherwise, attempts to access non-existant registers will occur. This is a subtle issue that is hard to track down when it occurs (and it has - see commit 864d296cf94). To try and help mitigate such occurrences, this patch introduces pci_pcie_cap2() which is similar to pci_pcie_cap() but also checks that the PCIe capability version is >= 2. pci_pcie_cap2() should be used for qualifying PCIe capability features introduced after v1. Suggested by Don Dutile. Acked-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
cb97ae34 |
|
01-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: remove redundant checking in PCI Express capability routines There are a number of redundant pci_is_pcie() checks in various PCI Express capabilities related routines like the following: if (!pci_is_pcie(dev)) return false; pos = pci_pcie_cap(dev); if (!pos) return false; The current pci_is_pcie() implementation is merely: static inline bool pci_is_pcie(struct pci_dev *dev) { return !!pci_pcie_cap(dev); } so we can just drop the pci_is_pcie() test in such cases. Acked-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c32823f8 |
|
01-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: make pci_ltr_supported() static The PCI Express Latency Tolerance Reporting (LTR) feature's pci_ltr_supported() routine is currently only used within drivers/pci/pci.c so make it static. Acked-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
533b6608 |
|
18-May-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: remove pci_max_busnr() (was already commented out) pci_max_busnr() has been commented out for years (since 54c762fe62), and this patch removes it completely. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
109cdbc2 |
|
18-May-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: remove pci_bus_find_ext_capability() (unused) pci_bus_find_ext_capability() is unused, and this patch removes it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
3df425f3 |
|
12-Apr-2012 |
John Crispin <blogic@openwrt.org> |
OF: PCI: const usage needed by MIPS On MIPS we want to call of_irq_map_pci from inside arch/mips/include/asm/pci.h:extern int pcibios_map_irq( const struct pci_dev *dev, u8 slot, u8 pin); For this to work we need to change several functions to const usage. Signed-off-by: John Crispin <blogic@openwrt.org> Cc: linux-pci@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-mips@linux-mips.org Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Patchwork: https://patchwork.linux-mips.org/patch/3710/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
#
977f857c |
|
24-Apr-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
PCI: move mutex locking out of pci_dev_reset function The intent of git commit 6fbf9e7a90862988c278462d85ce9684605a52b2 "PCI: Introduce __pci_reset_function_locked to be used when holding device_lock." was to have a non-locking function that would call pci_dev_reset function. But it fell short of that by just probing and not actually reseting the device. To make that work we need a way to move the lock around device_lock to not be in pci_dev_reset (as the caller of __pci_reset_function_locked already holds said lock). We do this by renaming pci_dev_reset to __pci_dev_reset and bubbling said mutex out of __pci_dev_reset to pci_dev_reset (a wrapper around __pci_dev_reset). The __pci_reset_function_locked can now call __pci_dev_reset without having to worry about the dead-lock. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
284f5f9d |
|
30-Apr-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: work around Stratus ftServer broken PCIe hierarchy A PCIe downstream port is a P2P bridge. Its secondary interface is a link that should lead only to device 0 (unless ARI is enabled)[1], so we don't probe for non-zero device numbers. Some Stratus ftServer systems have a PCIe downstream port (02:00.0) that leads to both an upstream port (03:00.0) and a downstream port (03:01.0), and 03:01.0 has important devices below it: [0000:02]-+-00.0-[03-3c]--+-00.0-[04-09]--... \-01.0-[0a-0d]--+-[USB] +-[NIC] +-... Previously, we didn't enumerate device 03:01.0, so USB and the network didn't work. This patch adds a DMI quirk to scan all device numbers, not just 0, below a downstream port. Based on a patch by Prarit Bhargava. [1] PCIe spec r3.0, sec 7.3.1 CC: Myron Stowe <mstowe@redhat.com> CC: Don Dutile <ddutile@redhat.com> CC: James Paradis <james.paradis@stratus.com> CC: Matthew Wilcox <matthew.r.wilcox@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
a6cb9ee7 |
|
16-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Retry BARs restoration for Type 0 headers only Some shortcomings introduced into pci_restore_state() by commit 26f41062f28d ("PCI: check for pci bar restore completion and retry") have been fixed by recent commit ebfc5b802fa76 ("PCI: Fix regression in pci_restore_state(), v3"), but that commit treats all PCI devices as those with Type 0 configuration headers. That is not entirely correct, because Type 1 and Type 2 headers have different layouts. In particular, the area occupied by BARs in Type 0 config headers contains the secondary status register in Type 1 ones and it doesn't make sense to retry the restoration of that register even if the value read back from it after a write is not the same as the written one (it very well may be different). For this reason, make pci_restore_state() only retry the restoration of BARs for Type 0 config headers. This effectively makes it behave as before commit 26f41062f28d for all header types except for Type 0. Tested-by: Mikko Vinni <mmvinni@yahoo.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ebfc5b80 |
|
15-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Fix regression in pci_restore_state(), v3 Commit 26f41062f28d ("PCI: check for pci bar restore completion and retry") attempted to address problems with PCI BAR restoration on systems where FLR had not been completed before pci_restore_state() was called, but it did that in an utterly wrong way. First off, instead of retrying the writes for the BAR registers only, it did that for all of the PCI config space of the device, including the status register (whose value after the write quite obviously need not be the same as the written one). Second, it added arbitrary delay to pci_restore_state() even for systems where the PCI config space restoration was successful at first attempt. Finally, the mdelay(10) it added to every iteration of the writing loop was way too much of a delay for any reasonable device. All of this actually caused resume failures for some devices on Mikko's system. To fix the regression, make pci_restore_state() only retry the writes for BAR registers and only wait if the first read from the register doesn't return the written value. Additionaly, make it wait for 1 ms, instead of 10 ms, after every failing attempt to write into config space. Reported-by: Mikko Vinni <mmvinni@yahoo.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
6748dcc2 |
|
29-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / PCIe: Introduce command line option to disable ARI There are PCIe devices on the market that report ARI support but then fail to initialize correctly when ARI is actually used. This leads to situations in which kernels 2.6.34 and newer fail to handle systems where the previous kernels worked without any apparent problems. Unfortunately, it is currently unknown how many such devices are there. For this reason, introduce a new kernel command line option, pci=noari, allowing users to disable PCIe ARI altogether if they see problems with PCIe device initialization. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
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>
|
#
34a4876e |
|
11-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: move pci_find_saved_cap out of linux/pci.h Only one user in driver/pci/pci.c, so we don't need to put it in global pci.h Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Yinghai Lu <yinghai@kernel.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>
|
#
26f41062 |
|
26-Jan-2012 |
Kay, Allen M <allen.m.kay@intel.com> |
PCI: check for pci bar restore completion and retry On some OEM systems, pci_restore_state() is called while FLR has not yet completed. As a result, PCI BAR register restore is not successful. This fix reads back the restored value and compares it with saved value and re-tries 10 times before giving up. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> Signed-off-by: Eric Chanudet <eric.chanudet@citrix.com> Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6fbf9e7a |
|
11-Jan-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
PCI: Introduce __pci_reset_function_locked to be used when holding device_lock. The use case of this is when a driver wants to call FLR when a device is attached to it using the SysFS "bind" or "unbind" functionality. The call chain when a user does "bind" looks as so: echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind and ends up calling: driver_bind: device_lock(dev); <=== TAKES LOCK XXXX_probe: .. pci_enable_device() ...__pci_reset_function(), which calls pci_dev_reset(dev, 0): if (!0) { device_lock(dev) <==== DEADLOCK The __pci_reset_function_locked function allows the the drivers 'probe' function to call the "pci_reset_function" while still holding the driver mutex lock. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6e9292c5 |
|
21-Jan-2012 |
Randy Dunlap <rdunlap@infradead.org> |
kernel-doc: fix new warnings in pci Fix new kernel-doc warnings: Warning(drivers/pci/pci.c:2811): No description found for parameter 'dev' Warning(drivers/pci/pci.c:2811): Excess function parameter 'pdev' description in 'pci_intx_mask_supported' Warning(drivers/pci/pci.c:2894): No description found for parameter 'dev' Warning(drivers/pci/pci.c:2894): Excess function parameter 'pdev' description in 'pci_check_and_mask_intx' Warning(drivers/pci/pci.c:2908): No description found for parameter 'dev' Warning(drivers/pci/pci.c:2908): Excess function parameter 'pdev' description in 'pci_check_and_unmask_intx' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a96d627a |
|
04-Jan-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
pci: Introduce __pci_reset_function_locked to be used when holding device_lock. The use case of this is when a driver wants to call FLR when a device is attached to it using the SysFS "bind" or "unbind" functionality. The call chain when a user does "bind" looks as so: echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind and ends up calling: driver_bind: device_lock(dev); <=== TAKES LOCK XXXX_probe: .. pci_enable_device() ...__pci_reset_function(), which calls pci_dev_reset(dev, 0): if (!0) { device_lock(dev) <==== DEADLOCK The __pci_reset_function_locked function allows the the drivers 'probe' function to call the "pci_reset_function" while still holding the driver mutex lock. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
#
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>
|
#
85b8582d |
|
05-Dec-2011 |
Vincent Palatin <vpalatin@chromium.org> |
PCI/PM/Runtime: make PCI traces quieter When the runtime PM is activated on PCI, if a device switches state frequently (e.g. an EHCI controller with autosuspending USB devices connected) the PCI configuration traces might be very verbose in the kernel log. Let's guard those traces with DEBUG condition. Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f676678f |
|
28-Oct-2011 |
Myron Stowe <mstowe@redhat.com> |
PCI: latency timer doesn't apply to PCIe The latency timer is read-only and hardwired to zero for all PCIe devices, both Type 0 and Type 1, so don't bother trying to update it and cluttering the dmesg log with meaningless "setting latency timer to 64" messages. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
96c55900 |
|
28-Oct-2011 |
Myron Stowe <mstowe@redhat.com> |
PCI: Pull PCI 'latency timer' setup up into the core The 'latency timer' of PCI devices, both Type 0 and Type 1, is setup in architecture-specific code [see: 'pcibios_set_master()']. There are two approaches being taken by all the architectures - check if the 'latency timer' is currently set between 16 and 255 and if not bring it within bounds, or, do nothing (and then there is the gratuitously different PA-RISC implementation). There is nothing architecture-specific about PCI's 'latency timer' so this patch pulls its setup functionality up into the PCI core by creating a generic 'pcibios_set_master()' function using the '__weak' attribute which can be used by all architectures as a default which, if necessary, can then be over-ridden by architecture-specific code. No functional change. Signed-off-by: Myron Stowe <myron.stowe@redhat.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>
|
#
fb51ccbf |
|
04-Nov-2011 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Rework config space blocking services pci_block_user_cfg_access was designed for the use case that a single context, the IPR driver, temporarily delays user space accesses to the config space via sysfs. This assumption became invalid by the time pci_dev_reset was added as locking instance. Today, if you run two loops in parallel that reset the same device via sysfs, you end up with a kernel BUG as pci_block_user_cfg_access detect the broken assumption. This reworks the pci_block_user_cfg_access to a sleeping service pci_cfg_access_lock and an atomic-compatible variant called pci_cfg_access_trylock. The former not only blocks user space access as before but also waits if access was already locked. The latter service just returns false in this case, allowing the caller to resolve the conflict instead of raising a BUG. Adaptions of the ipr driver were originally written by Brian King. Acked-by: Brian King <brking@linux.vnet.ibm.com> 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>
|
#
497f16f2 |
|
17-Dec-2011 |
Yinghai Lu <yinghai@kernel.org> |
pci: Fix hotplug of Express Module with pci bridges I noticed that hotplug of one setup does not work with recent change in pci tree. After checking the bridge conf setup, I noticed that the bridges get assigned but do not get enabled. The reason is the following commit, while simply ignores bridge resources when enabling a pci device: | commit bbef98ab0f019f1b0c25c1acdf1683c68933d41b | Author: Ram Pai <linuxram@us.ibm.com> | Date: Sun Nov 6 10:33:10 2011 +0800 | | PCI: defer enablement of SRIOV BARS |... | NOTE: Note, there is subtle change in the pci_enable_device() API. Any | driver that depends on SRIOV BARS to be enabled in pci_enable_device() | can fail. Put back bridge resource and ROM resource checking to fix the problem. That should fix regression like BIOS does not assign correct resource to bridge. Discussion can be found at: http://www.spinics.net/lists/linux-pci/msg12874.html Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b51306c6 |
|
12-Dec-2011 |
Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> |
PCI: Set device power state to PCI_D0 for device without native PM support During test of one IB card with guest VM, found that, msi is not initialized properly. It turns out __write_msi_msg will do nothing if device current_state is not PCI_D0. And, that pci device does not have pm_cap in guest VM. There is an error in setting of power state to PCI_D0 in pci_enable_device(), but error is not returned for this. Following is code flow: pci_enable_device() --> __pci_enable_device_flags() --> do_pci_enable_device() --> pci_set_power_state() --> __pci_start_power_transition() We have following condition inside __pci_start_power_transition(): if (platform_pci_power_manageable(dev)) { error = platform_pci_set_power_state(dev, state); if (!error) pci_update_current_state(dev, state); } else { error = -ENODEV; /* Fall back to PCI_D0 if native PM is not supported */ if (!dev->pm_cap) dev->current_state = PCI_D0; } Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is getting called and that is failing with ENODEV because of following condition: if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp))) return -ENODEV; Because of that, pci_update_current_state() is not getting called. With this patch, if device power state can not be set via platform_pci_set_power_state and that device does not have native pm support, then PCI device power state will be set to PCI_D0. -v2: This also reverts 47e9037ac16637cd7f12b8790ea7ce6680e42168, as it's not needed after this change. Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ajaykumar Hotchandani<ajaykumar.hotchandani@oracle.com> Signed-off-by: Yinghai Lu<yinghai.lu@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
bbef98ab |
|
05-Nov-2011 |
Ram Pai <linuxram@us.ibm.com> |
PCI: defer enablement of SRIOV BARS All the PCI BARs of a device are enabled when the device is enabled using pci_enable_device(). This unnecessarily enables SRIOV BARs of the device. On some platforms, which do not support SRIOV as yet, the pci_enable_device() fails to enable the device if its SRIOV BARs are not allocated resources correctly. The following patch fixes the above problem. The SRIOV BARs are now enabled when IOV capability of the device is enabled in sriov_enable(). NOTE: Note, there is subtle change in the pci_enable_device() API. Any driver that depends on SRIOV BARS to be enabled in pci_enable_device() can fail. The patch has been touch tested on power and x86 platform. Tested-by: Michael Wang <wangyun@linux.vnet.ibm.com> Signed-off-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
a1c473aa |
|
14-Oct-2011 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
pci: Clamp pcie_set_readrq() when using "performance" settings When configuring the PCIe settings for "performance", we allow parents to have a larger Max Payload Size than children and rely on children Max Read Request Size to not be larger than their own MPS to avoid having the host bridge generate responses they can't cope with. However, various drivers in Linux call pci_set_readrq() with arbitrary values, assuming this to be a simple performance tweak. This breaks under our "performance" configuration. Fix that by making sure the value programmed by pcie_set_readrq() is never larger than the configured MPS for that device. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jon Mason <mason@myri.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
379021d5 |
|
03-Oct-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI / PM: Extend PME polling to all PCI devices The land of PCI power management is a land of sorrow and ugliness, especially in the area of signaling events by devices. There are devices that set their PME Status bits, but don't really bother to send a PME message or assert PME#. There are hardware vendors who don't connect PME# lines to the system core logic (they know who they are). There are PCI Express Root Ports that don't bother to trigger interrupts when they receive PME messages from the devices below. There are ACPI BIOSes that forget to provide _PRW methods for devices capable of signaling wakeup. Finally, there are BIOSes that do provide _PRW methods for such devices, but then don't bother to call Notify() for those devices from the corresponding _Lxx/_Exx GPE-handling methods. In all of these cases the kernel doesn't have a chance to receive a proper notification that it should wake up a device, so devices stay in low-power states forever. Worse yet, in some cases they continuously send PME Messages that are silently ignored, because the kernel simply doesn't know that it should clear the device's PME Status bit. This problem was first observed for "parallel" (non-Express) PCI devices on add-on cards and Matthew Garrett addressed it by adding code that polls PME Status bits of such devices, if they are enabled to signal PME, to the kernel. Recently, however, it has turned out that PCI Express devices are also affected by this issue and that it is not limited to add-on devices, so it seems necessary to extend the PME polling to all PCI devices, including PCI Express and planar ones. Still, it would be wasteful to poll the PME Status bits of devices that are known to receive proper PME notifications, so make the kernel (1) poll the PME Status bits of all PCI and PCIe devices enabled to signal PME and (2) disable the PME Status polling for devices for which correct PME notifications are received. Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5f39e670 |
|
03-Oct-2011 |
Jon Mason <mason@myri.com> |
PCI: Disable MPS configuration by default Add the ability to disable PCI-E MPS turning and using the BIOS configured MPS defaults. Due to the number of issues recently discovered on some x86 chipsets, make this the default behavior. Also, add the option for peer to peer DMA MPS configuration. Peer to peer DMA is outside the scope of this patch, but MPS configuration could prevent it from working by having the MPS on one root port different than the MPS on another. To work around this, simply make the system wide MPS the smallest possible value (128B). Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ed2888e9 |
|
08-Sep-2011 |
Jon Mason <mason@myri.com> |
PCI: Remove MRRS modification from MPS setting code Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has massive negative ramifications on some devices. Without knowing which devices have this issue, do not modify from the default value when walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe the default procedure. Tested-by: Sven Schnelle <svens@stackframe.org> Tested-by: Simon Kirby <sim@hostway.ca> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com> Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.de> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162 Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
47c08f31 |
|
20-Aug-2011 |
Randy Dunlap <rdunlap@infradead.org> |
pci: fix new kernel-doc warning in pci.c Fix new kernel-doc warning in pci.c: Warning(drivers/pci/pci.c:3259): No description found for parameter 'mps' Warning(drivers/pci/pci.c:3259): Excess function parameter 'rq' description in 'pcie_set_mps' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b03e7495 |
|
20-Jul-2011 |
Jon Mason <mason@myri.com> |
PCI: Set PCI-E Max Payload Size on fabric On a given PCI-E fabric, each device, bridge, and root port can have a different PCI-E maximum payload size. There is a sizable performance boost for having the largest possible maximum payload size on each PCI-E device. However, if improperly configured, fatal bus errors can occur. Thus, it is important to ensure that PCI-E payloads sends by a device are never larger than the MPS setting of all devices on the way to the destination. This can be achieved two ways: - A conservative approach is to use the smallest common denominator of the entire tree below a root complex for every device on that fabric. This means for example that having a 128 bytes MPS USB controller on one leg of a switch will dramatically reduce performances of a video card or 10GE adapter on another leg of that same switch. It also means that any hierarchy supporting hotplug slots (including expresscard or thunderbolt I suppose, dbl check that) will have to be entirely clamped to 128 bytes since we cannot predict what will be plugged into those slots, and we cannot change the MPS on a "live" system. - A more optimal way is possible, if it falls within a couple of constraints: * The top-level host bridge will never generate packets larger than the smallest TLP (or if it can be controlled independently from its MPS at least) * The device will never generate packets larger than MPS (which can be configured via MRRS) * No support of direct PCI-E <-> PCI-E transfers between devices without some additional code to specifically deal with that case Then we can use an approach that basically ignores downstream requests and focuses exclusively on upstream requests. In that case, all we need to care about is that a device MPS is no larger than its parent MPS, which allows us to keep all switches/bridges to the max MPS supported by their parent and eventually the PHB. In this case, your USB controller would no longer "starve" your 10GE Ethernet and your hotplug slots won't affect your global MPS. Additionally, the hotplugged devices themselves can be configured to a larger MPS up to the value configured in the hotplug bridge. To choose between the two available options, two PCI kernel boot args have been added to the PCI calls. "pcie_bus_safe" will provide the former behavior, while "pcie_bus_perf" will perform the latter behavior. By default, the latter behavior is used. NOTE: due to the location of the enablement, each arch will need to add calls to this function. This patch only enables x86. This patch includes a number of changes recommended by Benjamin Herrenschmidt. Tested-by: Jordan_Hargrave@dell.com Signed-off-by: Jon Mason <mason@myri.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c9b378c7 |
|
28-Jun-2011 |
Jon Mason <jdmason@kudzu.us> |
PCI: correct pcie_set_readrq write size When setting the PCI-E MRRS, pcie_set_readrq queries the current settings via a pci_read_config_word call but writes the modified result via a pci_write_config_dword. This results in writing 16 more bits than were queried. Also, the function description comment is slightly incorrect. Signed-off-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
864d296c |
|
13-Jul-2011 |
Chris Wright <chrisw@sous-sol.org> |
PCI: ARI is a PCIe v2 feature The function pci_enable_ari() may mistakenly set the downstream port of a v1 PCIe switch in ARI Forwarding mode. This is a PCIe v2 feature, and with an SR-IOV device on that switch port believing the switch above is ARI capable it may attempt to use functions 8-255, translating into invalid (non-zero) device numbers for that bus. This has been seen to cause Completion Timeouts and general misbehaviour including hangs and panics. Cc: stable@kernel.org Acked-by: Don Dutile <ddutile@redhat.com> Tested-by: Don Dutile <ddutile@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 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>
|
#
7ad35cf2 |
|
24-May-2011 |
Dave Airlie <airlied@redhat.com> |
x86/uv/x2apic: update for change in pci bridge handling. When I added 3448a19da479b6bd1e28e2a2be9fa16c6a6feb39 I forgot about the special uv handling code for this, so this patch fixes it up. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Ingo Molnar Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3f37d622 |
|
25-May-2011 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: fix new kernel-doc warning Fix pci.c kernel-doc warnings: Warning(drivers/pci/pci.c:3292): No description found for parameter 'flags' Warning(drivers/pci/pci.c:3292): Excess function parameter 'change_bridge_flags' description in 'pci_set_vga_state' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ffbdd3f7 |
|
10-May-2011 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Add interfaces to store and load the device saved state For KVM device assignment, we'd like to save off the state of a device prior to passing it to the guest and restore it later. We also want to allow pci_reset_funciton() to be called while the device is owned by the guest. This however overwrites and invalidates the struct pci_dev buffers, so we can't just manually call save and restore. Add generic interfaces for the saved state to be stored and reloaded back into struct pci_dev at a later time. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
24a4742f |
|
10-May-2011 |
Alex Williamson <alex.williamson@redhat.com> |
PCI: Track the size of each saved capability data area This will allow us to store and load it later. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
51c2e0a7 |
|
14-Jan-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: add latency tolerance reporting enable/disable support Latency tolerance reporting allows devices to send messages to the root complex indicating their latency tolerance for snooped & unsnooped memory transactions. Add support for enabling & disabling this feature, along with a routine to set the max latencies a device should send upstream. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
48a92a81 |
|
10-Jan-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: add OBFF enable/disable support OBFF (optimized buffer flush/fill), where supported, can help improve energy efficiency by giving devices information about when interrupts and other activity will have a reduced power impact. It requires support from both the device and system (i.e. not only does the device need to respond to OBFF messages, but the platform must be capable of generating and routing them to the end point). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b48d4425 |
|
19-Oct-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: add ID-based ordering enable/disable support Add support to allow drivers to enable/disable ID-based ordering. Where supported, ID-based ordering can significantly improve the latency of individual requests by preventing them from queueing up behind unrelated traffic. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
83d74e03 |
|
05-Mar-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI/PM: Add kerneldoc description of pci_pm_reset() The pci_pm_reset() function is not a very nice interface due to its limitations and conditional behavior (e.g. it doesn't affect devices in low-power states), but it cannot be simply dropped, because existing device drivers may depend on it. However, its behavior and limitations should be well documented, so add an appropriate kerneldoc comment to it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
3448a19d |
|
31-May-2010 |
Dave Airlie <airlied@redhat.com> |
vgaarb: use bridges to control VGA routing where possible. So in a lot of modern systems, a GPU will always be below a parent bridge that won't share with any other GPUs. This means VGA arbitration on those GPUs can be controlled by using the bridge routing instead of io/mem decodes. The problem is locating which GPUs share which upstream bridges. This patch attempts to identify all the GPUs which can be controlled via bridges, and ones that can't. This patch endeavours to work out the bridge sharing semantics. When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the io/mem decodes for the gpu. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1a680b7c |
|
20-Mar-2011 |
Naga Chumbalkar <nagananda.chumbalkar@hp.com> |
PCI: PCIe links may not get configured for ASPM under POWERSAVE mode v3 -> v2: Moved ASPM enabling logic to pci_set_power_state() v2 -> v1: Preserved the logic in pci_raw_set_power_state() : Added ASPM enabling logic after scanning Root Bridge : http://marc.info/?l=linux-pci&m=130046996216391&w=2 v1 : http://marc.info/?l=linux-pci&m=130013164703283&w=2 The assumption made in commit 41cd766b065970ff6f6c89dd1cf55fa706c84a3d (PCI: Don't enable aspm before drivers have had a chance to veto it) that pci_enable_device() will result in re-configuring ASPM when aspm_policy is POWERSAVE is no longer valid. This is due to commit 97c145f7c87453cec90e91238fba5fe2c1561b32 (PCI: read current power state at enable time) which resets dev->current_state to D0. Due to this the call to pcie_aspm_pm_state_change() is never made. Note the equality check (below) that returns early: ./drivers/pci/pci.c: pci_raw_set_pci_power_state() 546 /* Check if we're already there */ 547 if (dev->current_state == state) 548 return 0; Therefore OSPM never configures the PCIe links for ASPM to turn them "on". Fix it by configuring ASPM from the pci_enable_device() code path. This also allows a driver such as the e1000e networking driver a chance to disable ASPM (L0s, L1), if need be, prior to enabling the device. A driver may perform this action if the device is known to mis-behave wrt ASPM. Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0f953bf6 |
|
29-Dec-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI/PM: Report wakeup events before resuming devices Make wakeup events be reported by the PCI subsystem before attempting to resume devices or queuing up runtime resume requests for them, because wakeup events should be reported as soon as they have been detected. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> 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>
|
#
1d3c16a8 |
|
30-Nov-2010 |
Jon Mason <jon.mason@exar.com> |
PCI: make pci_restore_state return void pci_restore_state only ever returns 0, thus there is no benefit in having it return any value. Also, a large majority of the callers do not check the return code of pci_restore_state. Make the pci_restore_state a void return and avoid the overhead. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Jon Mason <jon.mason@exar.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
97c145f7 |
|
05-Nov-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: read current power state at enable time When we enable a PCI device, we avoid doing a lot of the initial setup work if the device's enable count is non-zero. If we don't fetch the power state though, we may later fail to set up MSI due to the unknown status. So pick it up before we short circuit the rest due to a pre-existing enable or mismatched enable/disable pair (as happens with VGA devices, which are special in a special way). Tested-by: Jesse Brandeburg <jesse.brandeburg@gmail.com> Reported-by: Dave Airlie <airlied@linux.ie> Tested-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
df17e62e |
|
04-Oct-2010 |
Matthew Garrett <mjg@redhat.com> |
PCI: Add support for polling PME state on suspended legacy PCI devices Not all hardware vendors hook up the PME line for legacy PCI devices, meaning that wakeup events get lost. The only way around this is to poll the devices to see if their state has changed, so add support for doing that on legacy PCI devices that aren't part of the core chipset. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
93e75fab |
|
05-Aug-2010 |
Julia Lawall <julia@diku.dk> |
PCI: Adjust confusing if indentation in pcie_get_readrq Indent the branch of an if. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable braces4@ position p1,p2; statement S1,S2; @@ ( if (...) { ... } | if (...) S1@p1 S2@p2 ) @script:python@ p1 << r.p1; p2 << r.p2; @@ if (p1[0].column == p2[0].column): cocci.print_main("branch",p1) cocci.print_secs("after",p2) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
bfb51cd0 |
|
12-Jul-2010 |
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY} In 2.6.34, we transformed the PCI DMA API into the generic device mode. The PCI DMA API is just the wrapper of the DMA API. So we don't need HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE or HAVE_ARCH_PCI_SET_DMA_SEGMENT_BOUNDARY (which enable architectures to have the own implementations). Both haven't been used anyway. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> 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>
|
#
b03214d5 |
|
23-Jun-2010 |
Michael S. Tsirkin <mst@redhat.com> |
virtio-pci: disable msi at startup virtio-pci resets the device at startup by writing to the status register, but this does not clear the pci config space, specifically msi enable status which affects register layout. This breaks things like kdump when they try to use e.g. virtio-blk. Fix by forcing msi off at startup. Since pci.c already has a routine to do this, we export and use it instead of duplicating code. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: linux-pci@vger.kernel.org Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org
|
#
ee6583f6 |
|
18-May-2010 |
Roman Fietze <roman.fietze@telemotive.de> |
PCI: fix typos pci_device_dis/enable to pci_dis/enable_device in comments This fixes all occurrences of pci_enable_device and pci_disable_device in all comments. There are no code changes involved. Signed-off-by: Roman Fietze <roman.fietze@telemotive.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
52b265a1 |
|
08-Mar-2010 |
Alan Stern <stern@rowland.harvard.edu> |
PCI: clearing wakeup flags not needed This patch (as1353) removes a couple of unnecessary assignments from the PCI core. The should_wakeup flag is naturally initialized to 0; there's no need to clear it. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
cc2893b6 |
|
22-Apr-2010 |
Matthew Garrett <mjg@redhat.com> |
PCI: Ensure we re-enable devices on resume If the firmware puts a device back into D0 state at resume time, we'll update its state in resume_noirq and thus skip the platform resume code. Calling that code twice should be safe and we ought to avoid getting to that point anyway, so remove the check and also allow the platform pci code to be called for D0. Fixes USB not being powered after resume on recent Lenovo machines. Acked-by: Alex Chiang <achiang@canonical.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
7c9e2b1c |
|
09-Mar-2010 |
Dean Nelson <dnelson@redhat.com> |
PCI: cleanup error return for pcix get and set mmrbc functions pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if successful, or an appropriate error value, if not. Distinguishing errors from correct values and understanding the meaning of an error can be somewhat confusing in that: correct values: 512, 1024, 2048, 4096 errors: -EINVAL -22 PCIBIOS_FUNC_NOT_SUPPORTED 0x81 PCIBIOS_BAD_VENDOR_ID 0x83 PCIBIOS_DEVICE_NOT_FOUND 0x86 PCIBIOS_BAD_REGISTER_NUMBER 0x87 PCIBIOS_SET_FAILED 0x88 PCIBIOS_BUFFER_TOO_SMALL 0x89 The PCIBIOS_ errors are returned from the PCI functions generated by the PCI_OP_READ() and PCI_OP_WRITE() macros. In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values returned from pci_read_config_[word|dword]() and pci_write_config_word(). Following pcix_get_max_mmrbc()'s example, the following patch simply returns -EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL or -EIO for those encountered by pcix_set_mmrbc(). This simplification was chosen in light of the fact that none of the current callers of these functions are interested in the specific type of error encountered. In the future, should this change, one could simply create a function that maps each PCIBIOS_ error to a corresponding unique errno value, which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and pcix_set_mmrbc(). Additionally, this patch eliminates some unnecessary variables. Cc: stable@kernel.org Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
bdc2bda7 |
|
09-Mar-2010 |
Dean Nelson <dnelson@redhat.com> |
PCI: fix access of PCI_X_CMD by pcix get and set mmrbc functions An e1000 driver on a system with a PCI-X bus was always being returned a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from pci_bus_read_config_dword(,, cap + PCI_X_CMD,). This is because for a dword, the following portion of the PCI_OP_READ() macro: if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; expands to: if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER; And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).) The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,). In both cases, instead of calling _dword(), _word() should be called. Cc: stable@kernel.org Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ded1d8f2 |
|
11-Mar-2010 |
Paul Mundt <lethal@linux-sh.org> |
PCI: kill off pci_register_set_vga_state() symbol export. When pci_register_set_vga_state() was made __init, the EXPORT_SYMBOL() was retained, which now leaves us with a section mismatch. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Cc: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
25daeb55 |
|
09-Mar-2010 |
Dean Nelson <dnelson@redhat.com> |
PCI: fix return value from pcix_get_max_mmrbc() For the PCI_X_STATUS register, pcix_get_max_mmrbc() is returning an incorrect value, which is based on: (stat & PCI_X_STATUS_MAX_READ) >> 12 Valid return values are 512, 1024, 2048, 4096, which correspond to a 'stat' (masked and right shifted by 21) of 0, 1, 2, 3, respectively. A right shift by 11 would generate the correct return value when 'stat' (masked and right shifted by 21) has a value of 1 or 2. But for a value of 0 or 3 it's not possible to generate the correct return value by only right shifting. Fix is based on pcix_get_mmrbc()'s similar dealings with the PCI_X_CMD register. Cc: stable@kernel.org Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
88393161 |
|
16-Mar-2010 |
Thomas Weber <swirl@gmx.li> |
Fix typos in comments [Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: Thomas Weber <swirl@gmx.li> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5f3cd1e0 |
|
10-Mar-2010 |
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
dma-mapping: pci: move pci_set_dma_mask and pci_set_consistent_dma_mask to pci-dma-compat.h We can use pci-dma-compat.h to implement pci_set_dma_mask and pci_set_consistent_dma_mask as we do with the other PCI DMA API. We can remove HAVE_ARCH_PCI_SET_DMA_MASK too. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
6a1961f4 |
|
10-Mar-2010 |
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
dma-mapping: dma-mapping.h: add dma_set_coherent_mask dma_set_coherent_mask corresponds to pci_set_consistent_dma_mask. This is necessary to move to the generic device model DMA API from the PCI bus specific API in the long term. dma_set_coherent_mask works in the exact same way that pci_set_consistent_dma_mask does. So this patch also changes pci_set_consistent_dma_mask to call dma_set_coherent_mask. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: James Bottomley <James.Bottomley@suse.de> Cc: David S. Miller <davem@davemloft.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e3c4bcca |
|
10-Mar-2010 |
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
dma-mapping: pci: convert pci_set_dma_mask to call dma_set_mask This changes pci_set_dma_mask to call the generic DMA API, dma_set_mask. pci_set_dma_mask (in drivers/pci/pci.c) does the same things that dma_set_mask does on all the architectures that use pci_set_dma_mask; calls dma_supprted and sets dev->dma_mask. So we safely change pci_set_dma_mask to simply call dma_set_mask. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: James Bottomley <James.Bottomley@suse.de> Cc: David S. Miller <davem@davemloft.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8e9394ce |
|
17-Feb-2010 |
Greg Kroah-Hartman <gregkh@suse.de> |
Driver core: create lock/unlock functions for struct device In the future, we are going to be changing the lock type for struct device (once we get the lockdep infrastructure properly worked out) To make that changeover easier, and to possibly burry the lock in a different part of struct device, let's create some functions to lock and unlock a device so that no out-of-core code needs to be changed in the future. This patch creates the device_lock/unlock/trylock() functions, and converts all in-tree users to them. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jean Delvare <khali@linux-fr.org> Cc: Dave Young <hidave.darkstar@gmail.com> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Phil Carmody <ext-phil.2.carmody@nokia.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Cc: Magnus Damm <damm@igel.co.jp> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Alex Chiang <achiang@hp.com> Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrew Patterson <andrew.patterson@hp.com> Cc: Yu Zhao <yu.zhao@intel.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: CHENG Renquan <rqcheng@smu.edu.sg> Cc: Oliver Neukum <oliver@neukum.org> Cc: Frans Pop <elendil@planet.nl> Cc: David Vrabel <david.vrabel@csr.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
bb910a70 |
|
27-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI/PM Runtime: Make runtime PM of PCI devices inactive by default Make the run-time power management of PCI devices be inactive by default by calling pm_runtime_forbid() for each PCI device during its initialization. This setting may be overriden by the user space with the help of the /sys/devices/.../power/control interface. That's necessary to avoid breakage on systems where ACPI-based wake-up is known to fail for some devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
a1e4d72c |
|
08-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Allow PCI devices to suspend/resume asynchronously Set power.async_suspend for all PCI devices and PCIe port services, so that they can be suspended and resumed in parallel with other devices they don't depend on in a known way (i.e. devices which are not their parents or children). This only affects the "regular" suspend and resume stages, which means in particular that the restoration of the PCI devices' standard configuration registers during resume will still be carried out synchronously (at the "early" resume stage). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
89a74ecc |
|
23-Feb-2010 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refs No functional change; this converts loops that iterate from 0 to PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the pci_bus_for_each_resource() iterator instead. This doesn't change the way resources are stored; it merely removes dependencies on the fact that they're in a table. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
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>
|
#
cf4c43dd |
|
15-Jul-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: Add pci_bus_find_ext_capability For use by code that needs to walk extended capability lists before pci_dev structures are set up. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80CFD@orsmsx508.amr.corp.intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
#
95a8b6ef |
|
02-Feb-2010 |
Mike Travis <travis@sgi.com> |
pci: Update pci_set_vga_state() to call arch functions Update pci_set_vga_state to call arch dependent functions to enable Legacy VGA I/O transactions to be redirected to correct target. [akpm@linux-foundation.org: make pci_register_set_vga_state() __init] Signed-off-by: Mike Travis <travis@sgi.com> LKML-Reference: <201002022238.o12McE1J018723@imap1.linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Robin Holt <holt@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
#
1ae861e6 |
|
30-Dec-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI/PM: Use per-device D3 delays It turns out that some PCI devices require extra delays when changing power state from D3 to D0 (and the other way around). Although this is against the PCI specification, we can handle it quite easily by allowing drivers to define arbitrary D3 delays for devices known to require extra time for switching power states. Introduce additional field d3_delay in struct pci_dev and use it to store the value of the device's D0->D3 delay, in miliseconds. Make the PCI PM core code use the per-device d3_delay unless pci_pm_d3_delay is greater (in which case the latter is used). [This also allows the driver to specify d3_delay shorter than the 10 ms required by the PCI standard if the device is known to be able to handle that.] Make the sky2 driver set d3_delay to 150 for devices handled by it. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14730 which is a listed regression from 2.6.30. 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>
|
#
2d1c8618 |
|
08-Dec-2009 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
PCI/cardbus: Add a fixup hook and fix powerpc The cardbus code creates PCI devices without ever going through the necessary fixup bits and pieces that normal PCI devices go through. There's in fact a commented out call to pcibios_fixup_bus() in there, it's commented because ... it doesn't work. I could make pcibios_fixup_bus() do the right thing on powerpc easily but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus for which a weak empty implementation is provided by the PCI core. This fixes cardbus on powerbooks and probably all other PowerPC platforms which was broken completely for ever on some platforms and since 2.6.31 on others such as PowerBooks when we made the DMA ops mandatory (since those are setup by the fixups). Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
45e829ea |
|
03-Dec-2009 |
Stefan Assmann <sassmann@redhat.com> |
PCI: change PCI nomenclature in drivers/pci/ (comment changes) Changing occurrences of variants of PCI-X and PCIe to the PCI-SIG terms listed in the "Trademark and Logo Usage Guidelines". http://www.pcisig.com/developers/procedures/logos/Trademark_and_Logo_Usage_Guidelines_updated_112206.pdf Patch is limited to drivers/pci/ and changes concern comments only. Signed-off-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.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>
|
#
9e0b5b2c |
|
24-Nov-2009 |
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> |
PCI: fix coding style issue in pci_save_state() Remove a stray space in pci_save_state(). Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5d990b62 |
|
04-Dec-2009 |
Chris Wright <chrisw@sous-sol.org> |
PCI: add pci_request_acs Commit ae21ee65e8bc228416bbcc8a1da01c56a847a60c "PCI: acs p2p upsteram forwarding enabling" doesn't actually enable ACS. Add a function to pci core to allow an IOMMU to request that ACS be enabled. The existing mechanism of using iommu_found() in the pci core to know when ACS should be enabled doesn't actually work due to initialization order; iommu has only been detected not initialized. Have Intel and AMD IOMMUs request ACS, and Xen does as well during early init of dom0. Cc: Allen Kay <allen.m.kay@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
04b55c47 |
|
03-Dec-2009 |
Shmulik Ravid <shmulikr@broadcom.com> |
PCI: read-modify-write the pcie device control register when initiating pcie flr The pcie_flr routine writes the device control register with the FLR bit set clearing all other fields for the FLR duration. Among other fields, the Max_Payload_Size is also cleared which can cause errors if there are transactions lurking in the HW pipeline. The patch replaces the blank write with read-modify-write of the control register keeping the other fields intact. Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c6a41576 |
|
25-Nov-2009 |
Yinghai Lu <yinghai@kernel.org> |
PCI: add debug output for DMA mask info This allows us to find out what DMA mask is used for each PCI device at boot time; useful for debugging. After the patch: ehci_hcd 0000:00:02.1: using 31bit consistent DMA mask e1000 0000:0b:01.0: using 64bit DMA mask e1000 0000:0b:01.0: using 64bit consistent DMA mask e1000e 0000:04:00.0: using 64bit DMA mask e1000e 0000:04:00.0: using 64bit consistent DMA mask ixgb 0000:0c:01.0: using 64bit DMA mask ixgb 0000:0c:01.0: using 64bit consistent DMA mask aacraid 0000:86:00.0: using 32bit DMA mask aacraid 0000:86:00.0: using 32bit consistent DMA mask aacraid 0000:86:00.0: using 64bit DMA mask aacraid 0000:86:00.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.1: using 64bit consistent DMA mask lpfc 0000:06:00.0: using 64bit DMA mask lpfc 0000:06:00.1: using 64bit DMA mask pata_amd 0000:00:06.0: using 32bit DMA mask pata_amd 0000:00:06.0: using 32bit consistent DMA mask mptsas 0000:0c:04.0: using 64bit DMA mask mptsas 0000:0c:04.0: using 64bit consistent DMA mask forcedeth 0000:00:08.0: using 39bit DMA mask forcedeth 0000:00:08.0: using 39bit consistent DMA mask niu 0000:02:00.0: using 44bit DMA mask niu 0000:02:00.0: using 44bit consistent DMA mask sata_nv 0000:00:05.0: using 32bit DMA mask sata_nv 0000:00:05.0: using 32bit consistent DMA mask ib_mthca 0000:03:00.0: using 64bit DMA mask ib_mthca 0000:03:00.0: using 64bit consistent DMA mask Reviewed-by: Grant Grundler <grundler@google.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5f4d91a1 |
|
10-Nov-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: use pci_is_pcie() in pci core Change for PCI core to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
06a1cbaf |
|
10-Nov-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: use pci_pcie_cap() in pci core Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI core code. This avoids unnecessary search in PCI configuration space. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8c8def26 |
|
09-Nov-2009 |
Linus Torvalds <torvalds@linux-foundation.org> |
PCI: allow matching of prefetchable resources to non-prefetchable windows I'm not entirely sure it needs to go into 32, but it's probably the right thing to do. Another way of explaining the patch is: - we currently pick the _first_ exactly matching bus resource entry, but the _last_ inexactly matching one. Normally first/last shouldn't matter, but bus resource entries aren't actually all created equal: in a transparent bus, the last resources will be the parent resources, which we should generally try to avoid unless we have no choice. So "first matching" is the thing we should always aim for. - the patch is a bit bigger than it needs to be, because I simplified the logic at the same time. It used to be a fairly incomprehensible if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH)) best = r; /* Approximating prefetchable by non-prefetchable */ and technically, all the patch did was to make that complex choice be even more complex (it basically added a "&& !best" to say that if we already gound a non-prefetchable window for the prefetchable resource, then we won't override an earlier one with that later one: remember "first matching"). - So instead of that complex one with three separate conditionals in one, I split it up a bit, and am taking advantage of the fact that we already handled the exact case, so if 'res->flags' has the PREFETCH bit, then we already know that 'r->flags' will _not_ have it. So the simplified code drops the redundant test, and does the new '!best' test separately. It also uses 'continue' as a way to ignore the bus resource we know doesn't work (ie a prefetchable bus resource is _not_ acceptable for anything but an exact match), so it turns into: /* We can't insert a non-prefetch resource inside a prefetchable parent .. */ if (r->flags & IORESOURCE_PREFETCH) continue; /* .. but we can put a prefetchable resource inside a non-prefetchable one */ if (!best) best = r; instead. With the comments, it's now six lines instead of two, but it's conceptually simpler, and I _could_ have written it as two lines: if ((res->flags & IORESOURCE_PREFETCH) && !best) best = r; /* Approximating prefetchable by non-prefetchable */ but I thought that was too damn subtle. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e9d1e492 |
|
06-Nov-2009 |
Thomas Gleixner <tglx@linutronix.de> |
PCI: Replace old style lock initializer SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead. Make the lock static while at it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
865df576 |
|
04-Nov-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: improve discovery/configuration messages This makes PCI resource management messages more consistent and adds a few new messages to aid debugging. Whenever we assign resources to a device, update a BAR, or change a bridge aperture, it's worth noting it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
10c3d71d |
|
04-Nov-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: make PME# messages KERN_DEBUG Messages about PME# being supported and enabled/disabled are probably useful for debug, but maybe don't need to be on the console. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c7dabef8 |
|
27-Oct-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
vsprintf: use %pR, %pr instead of %pRt, %pRf Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This is the diff between v1 and v2. The changes in this patch are: - tidied vsprintf stack buffer to shrink and compute size more accurately - use %pR for decoding and %pr for "raw" (with type and flags) instead of adding %pRt and %pRf [1] http://lkml.org/lkml/2009/10/6/491 [2] http://lkml.org/lkml/2009/10/13/441 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.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>
|
#
a369c791 |
|
06-Oct-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: print resources consistently with %pRt This uses %pRt to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
98e724c7 |
|
08-Oct-2009 |
Tejun Heo <tj@kernel.org> |
PCI: pci_dfl_cache_line_size is __devinitdata pci_dfl_cache_line_size is marked as __initdata but referenced by pci_init() which is __devinit. Make it __devinitdata instead of __initdata. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
15ea76d4 |
|
22-Sep-2009 |
Tejun Heo <tj@kernel.org> |
pccard: configure CLS on attach For non hotplug PCI devices, the system firmware usually configures CLS correctly. For pccard devices system firmware can't do it and Linux PCI layer doesn't do it either. Unfortunately this leads to poor performance for certain devices (sata_sil). Unless MWI, which requires separate configuration, is to be used, CLS doesn't affect correctness, so the configuration should be harmless. This patch makes pci_set_cacheline_size() always built and export it and make pccard call it during attach. Please note that some other PCI hotplug drivers (shpchp and pciehp) also configure CLS on hotplug. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Greg KH <greg@kroah.com> Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Cc: Axel Birndt <towerlexa@gmx.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
4c0eec7a |
|
22-Sep-2009 |
Tejun Heo <tj@kernel.org> |
sparc64/PCI: drop PCI_CACHE_LINE_BYTES sparc64 is now the only user of PCI_CACHE_LINE_BYTES. Drop it and set pci_dfl_cache_line_size from pcibios_init() instead and drop PCI_CACHE_LINE_BYTES handling from generic pci code. Orignally-From: David Miller <davem@davemloft.net> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ac1aa47b |
|
26-Oct-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: determine CLS more intelligently Till now, CLS has been determined either by arch code or as L1_CACHE_BYTES. Only x86 and ia64 set CLS explicitly and x86 doesn't always get it right. On most configurations, the chance is that firmware configures the correct value during boot. This patch makes pci_init() determine CLS by looking at what firmware has configured. It scans all devices and if all non-zero values agree, the value is used. If none is configured or there is a disagreement, pci_dfl_cache_line_size is used. arch can set the dfl value (via PCI_CACHE_LINE_BYTES or pci_dfl_cache_line_size) or override the actual one. ia64, x86 and sparc64 updated to set the default cls instead of the actual one. While at it, declare pci_cache_line_size and pci_dfl_cache_line_size in pci.h and drop private declarations from arch code. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: David Miller <davem@davemloft.net> Acked-by: Greg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8d86fb2c |
|
11-Oct-2009 |
David Woodhouse <David.Woodhouse@intel.com> |
Rename pci_init() to pci_apply_final_quirks(), move it to quirks.c This function may have done more in the past, but all it does now is apply the PCI_FIXUP_FINAL quirks. So name it sensibly and put it where it belongs. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
#
19eea630 |
|
17-Sep-2009 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: pci.c: fix kernel-doc notation Fix kernel-doc notation (& warnings) in pci/pci.c. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e13cdbd7 |
|
04-Oct-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Read device power state from register after updating it After attempting to change the power state of a PCI device pci_raw_set_power_state() doesn't check if the value it wrote into the device's PCI_PM_CTRL register has been stored in there, but unconditionally modifies the device's current_state field to reflect the change. This may cause problems to happen if the power state of the device hasn't been changed in fact, because it will make the PCI PM core make a wrong assumption. To prevent such situations from happening modify pci_raw_set_power_state() so that it reads the device's PCI_PM_CTRL register after writing into it and uses the value read from the register to update the device's current_state field. Also make it print a message saying that the device refused to change its power state as requested (returning an error code in such cases would cause suspend regressions to appear on some systems, where device drivers' suspend routines return error codes if pci_set_power_state() fails). Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
4b77b0a2 |
|
09-Sep-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Clear saved_state after the state has been restored Some PCI devices fail if their standard configuration registers are restored twice in a row. Prevent this from happening by making pci_restore_state() clear the saved_state flag of the device right after the device's standard configuration registers have been populated with the previously saved values. Simplify PCI PM callbacks by removing the direct clearing of state_saved from them, as it shouldn't be necessary any more (except in pci_pm_thaw(), where it has to be cleared, so that the values saved during the "freeze" phase of hibernation are not used later by mistake). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e80bb09d |
|
08-Sep-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Introduce device flag wakeup_prepared Introduce a new PCI device flag, wakeup_prepared, to prevent PCI wake-up preparation code from being executed twice in a row for the same device and for the same purpose. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5bcc2fb4 |
|
08-Sep-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Simplify PCI wake-up code Rework the PCI wake-up code so that it's easier to read without changing the functionality. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
28760489 |
|
09-Sep-2009 |
Eric W. Biederman <ebiederm@aristanetworks.com> |
PCI: pcie: Ensure hotplug ports have a minimum number of resources In general a BIOS may goof or we may hotplug in a hotplug controller. In either case the kernel needs to reserve resources for plugging in more devices in the future instead of creating a minimal resource assignment. We already do this for cardbus bridges I am just adding a variant for pcie bridges. v2: Make testing for pcie hotplug bridges based on a flag. So far we only set the flag for pcie but a header_quirk could easily be added for the non-standard pci hotplug bridges. Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
deb2d2ec |
|
10-Aug-2009 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
PCI/GPU: implement VGA arbitration on Linux Background: Graphic devices are accessed through ranges in I/O or memory space. While most modern devices allow relocation of such ranges, some "Legacy" VGA devices implemented on PCI will typically have the same "hard-decoded" addresses as they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware Revision 2.1" Section 7, Legacy Devices. The Resource Access Control (RAC) module inside the X server currently does the task of arbitration when more than one legacy device co-exists on the same machine. But the problem happens when these devices are trying to be accessed by different userspace clients (e.g. two server in parallel). Their address assignments conflict. Therefore an arbitration scheme _outside_ of the X server is needed to control the sharing of these resources. This document introduces the operation of the VGA arbiter implemented for Linux kernel. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com> Signed-off-by: Dave Airlie <airlied@redhat.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>
|
#
c82f63e4 |
|
07-Aug-2009 |
Alek Du <alek.du@intel.com> |
PCI: check saved state before restore Without the check, the config space may be filled with zeros. Though the driver should try to avoid call restoring before saving, but the pci layer also should check this. Also removes the existing check in pci_restore_standard_config, since it's superfluous with the new check in restore_state. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Alek Du <alek.du@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
46b952a3 |
|
01-Jul-2009 |
Matthew Wilcox <willy@infradead.org> |
PCI: Fix IRQ swizzling for ARI-enabled devices For many purposes, including interrupt-swizzling, devices with ARI enabled behave as if they have one device (number 0) and 256 functions. This probably hasn't bitten us in practice because all ARI devices I've seen are also IOV devices, and IOV devices are required to use MSI. This isn't guaranteed, and there are legitimate reasons to use ARI without IOV, and hence potentially use pin-based interrupts. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
654b75e0 |
|
26-Jun-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: check if bus has a proper bridge device before triggering SBR For devices attached to the root bus, we can't trigger Secondary Bus Reset because there is no bridge device associated with the bus. So need to check bus->self again NULL first before using it. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
7d9a73f6 |
|
16-Jun-2009 |
Frans Pop <elendil@planet.nl> |
PCI PM: consistently use type bool for wake enable variable Other functions use type bool, so use that for pci_enable_wake as well. Signed-off-by: Frans Pop <elendil@planet.nl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d2abdf62 |
|
14-Jun-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Fix handling of devices without PM support by pci_target_state() If a PCI device is not power-manageable either by the platform, or with the help of the native PCI PM interface, pci_target_state() will return either PCI_D3hot, or PCI_POWER_ERROR for it, depending on whether or not the device is configured to wake up the system. Alas, none of these return values is correct, because each of them causes pci_prepare_to_sleep() to return error code, although it should complete successfully in such a case. Fix this problem by making pci_target_state() always return PCI_D0 for devices that cannot be power managed. Cc: stable@kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c12ff1df |
|
13-Jun-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: support Secondary Bus Reset PCI-to-PCI Bridge 1.2 specifies that the Secondary Bus Reset bit can force the assertion of RST# on the secondary interface, which can be used to reset all devices including subordinates under this bus. This can be used to reset a function if this function is the only device under this bus. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f85876ba |
|
13-Jun-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: support PM D0hot->D3 transition reset PCI PM 1.2 specifies that the device will perform an internal reset upon transitioning from D3hot to D0 when the NO_SOFT_RESET bit is clear. This method can be used to reset a function if neither PCIe FLR nor PCI AF FLR are supported. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8c1c699f |
|
13-Jun-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: cleanup Function Level Reset This patch enhances the FLR functions: 1) remove disable_irq() so the shared IRQ won't be disabled. 2) replace the 1s wait with 100, 200 and 400ms wait intervals for the Pending Transaction. 3) replace mdelay() with msleep(). 4) add might_sleep(). 5) lock the device to prevent PM suspend from accessing the CSRs during the reset. 6) coding style fixes. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
1eb39487 |
|
26-May-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: use pci_is_root_bus() in pci_common_swizzle() Use pci_is_root_bus() in pci_common_swizzle() for checking if the pci bus is root, for code consistency. Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8784fd4d |
|
26-May-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: use pci_is_root_bus() in pci_get_interrupt_pin() Use pci_is_root_bus() in pci_get_interrupt_pin() for checking if the pci bus is root, for code consistency. Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
00240c38 |
|
27-Apr-2009 |
Alan Stern <stern@rowland.harvard.edu> |
PCI: add power-state name strings This patch (as1235) adds an array of PCI power-state names, together with a simple inline accessor routine. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
43c16408 |
|
22-Apr-2009 |
Andrew Patterson <andrew.patterson@hp.com> |
PCI: Add support for turning PCIe ECRC on or off Adds support for PCI Express transaction layer end-to-end CRC checking (ECRC). This patch will enable/disable ECRC checking by setting/clearing the ECRC Check Enable and/or ECRC Generation Enable bits for devices that support ECRC. The ECRC setting is controlled by the "pci=ecrc=<policy>" command-line option. If this option is not set or is set to 'bios", the enable and generation bits are left in whatever state that firmware/BIOS set them to. The "off" setting turns them off, and the "on" option turns them on (if the device supports it). Turning ECRC on or off can be a data integrity versus performance tradeoff. In theory, turning it on will catch more data errors, turning it off means possibly better performance since CRC does not need to be calculated by the PCIe hardware and packet sizes are reduced. Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f62795f1 |
|
18-May-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3 According to the PCI PM specification (PCI Bus Power Management Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during all transitions from PCI_D3hot to PCI_D0, but we only do it if the device's current_state field is equal to PCI_UNKNOWN. This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET unset is put into PCI_D3hot at run time by its driver and pci_set_power_state() is used to put it back into PCI_D0, because in that case the device will remain uninitialized after pci_set_power_state() has returned. Prevent that from happening by modifying pci_raw_set_power_state() to reinitialize devices with PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0. Cc: stable@kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b3bad72e |
|
17-May-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Fix initialization and kexec breakage for some devices Recent PCI PM changes introduced a bug that causes some devices to be mishandled after kexec and during early initialization. The failure scenario in the kexec case is the following: * Assume a PCI device is not power-manageable by the platform and has PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR. * The device is put into D3 before kexec (using the native PCI PM). * After kexec, pci_setup_device() sets the device's power state to PCI_UNKNOWN. * pci_set_power_state(dev, PCI_D0) is called by the device's driver. * __pci_start_power_transition(dev, PCI_D0) is called and since the device is not power-manageable by the platform, it causes pci_update_current_state(dev, PCI_D0) to be called. As a result the device's current_state field is updated to PCI_D3, in accordance with the contents of its PCI PM registers. * pci_raw_set_power_state() is called and it changes the device power state to D0. *However*, it should also call pci_restore_bars() to reinitialize the device, but it doesn't, because the device's current_state field has been modified earlier. To prevent this from happening, modify pci_platform_power_transition() so that it doesn't use pci_update_current_state() to update the current_state field for devices that aren't power-manageable by the platform. Instead, this field should be updated directly for devices that don't support the native PCI PM. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
1b6b8ce2 |
|
09-Apr-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: only save/restore existent registers in the PCIe capability PCIe 1.1 base neither requires the endpoint to implement the entire PCIe capability structure nor specifies default values of registers that are not implemented by the device. So we only save and restore registers that must be implemented by different device types if the device PCIe capability version is 1. PCIe 1.1 Capability Structure Expansion ECN and PCIe 2.0 requires all registers in the PCIe capability to be either implemented or hardwired to 0. Their PCIe capability version is 2. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
296ccb08 |
|
03-Apr-2009 |
Yuji Shimada <shimada-yxb@necst.nec.co.jp> |
PCI: Setup disabled bridges even if buses are added This patch sets up disabled bridges even if buses have already been added. pci_assign_unassigned_resources is called after buses are added. pci_assign_unassigned_resources calls pci_bus_assign_resources. pci_bus_assign_resources calls pci_setup_bridge to configure BARs of bridges. Currently pci_setup_bridge returns immediately if the bus have already been added. So pci_assign_unassigned_resources can't configure BARs of bridges that were added in a disabled state; this patch fixes the issue. On logical hot-add, we need to prevent the kernel from re-initializing bridges that have already been initialized. To achieve this, pci_setup_bridge returns immediately if the bridge have already been enabled. We don't need to check whether the specified bus is a root bus or not. pci_setup_bridge is not called on a root bus, because a root bus does not have a bridge. The patch adds a new helper function, pci_is_enabled. I made the function name similar to pci_is_managed. The codes which use enable_cnt directly are changed to use pci_is_enabled. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8efb8c76 |
|
30-Mar-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Make pci_prepare_to_sleep() disable wake-up if needed If the device is not supposed to wake up the system, ie. when device_may_wakeup(&dev->dev) returns 'false', pci_prepare_to_sleep() should pass 'false' to pci_enable_wake() so that it calls the platform to disable the wake-up capability of the device. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0e5dd46b |
|
26-Mar-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Introduce __pci_[start|complete]_power_transition() (rev. 2) The radeonfb driver needs to program the device's PMCSR directly due to some quirky hardware it has to handle (see http://bugzilla.kernel.org/show_bug.cgi?id=12846 for details) and after doing that it needs to call the platform (usually ACPI) to finish the power transition of the device. Currently it uses pci_set_power_state() for this purpose, however making a specific assumption about the internal behavior of this function, which has changed recently so that this assumption is no longer satisfied. For this reason, introduce __pci_complete_power_transition() that may be called by the radeonfb driver to complete the power transition of the device. For symmetry, introduce __pci_start_power_transition(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
4a865905 |
|
16-Mar-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Make pci_set_power_state() handle devices with no PM support There is a problem with PCI devices without any PM support (either native or through the platform) that pci_set_power_state() always returns error code for them, even if they are being put into D0. However, such devices are always in D0, so pci_set_power_state() should return success when attempting to put such a device into D0. It also should update the current_state field for these devices as appropriate. This modification is necessary so that the standard configuration registers of these devices are successfully restored by pci_restore_standard_config() during the "early" phase of resume. In addition, pci_set_power_state() should check the value of current_state before calling the platform to change the power state of the device to avoid doing that unnecessarily. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
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>
|
#
f00a20ef |
|
16-Mar-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Use pci_set_power_state during early resume Once we have allowed timer interrupts to be enabled during the early phase of resuming devices, we are now able to use the generic pci_set_power_state() to put PCI devices into D0 at that time. Then, the platform-specific PM code will have a chance to handle devices that don't implement the native PCI PM or that require some additional, platform-specific operations to be carried out to power them up. Also, by doing this we can simplify the code quite a bit. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
877d0310 |
|
26-Jan-2009 |
Nick Andrew <nick@nick-andrew.net> |
trivial: Fix misspelling of firmware Fix misspelling of firmware. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
89858517 |
|
15-Feb-2009 |
Yu Zhao <yu.zhao@intel.com> |
PCI: save and restore PCIe 2.0 registers PCIe 2.0 defines several new registers (Device Control 2, Link Control 2, and Slot Control 2). Save and retore them in pci_save_pcie_state() and pci_restore_pcie_state(). 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>
|
#
c74d7244 |
|
16-Feb-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: fix wrong assumption in pci_common_swizzle Current pci_common_swizzle() seems to have a assumption that pci_bus->self is NULL on the pci root bus. But it might not be true on some platforms. Because of this wrong assumption, pci_common_swizzle() might cause endless loop. We must check pci_bus->parent instead. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c2a3072e |
|
16-Feb-2009 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
PCI: fix wrong assumption in pci_get_interrupt_pin Current pci_get_interrupt_pin() seems to have an assumption that pci_bus->self is NULL on the root pci bus. But it might not be true on some platforms. Because of this wrong assumption, current pci_get_interrupt_pin() might cause endless loop. We must check pci_bus->parent instead. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5fe5db05 |
|
08-Feb-2009 |
Sheng Yang <sheng@linux.intel.com> |
PCI: Speed up device reset function For all devices need to do function level reset, currently we need wait for at least 200ms, which can be too long if we have lots of devices... The patch checked pending bit before msleep() to skip some unnecessary sleeping interval. Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e496b617 |
|
07-Jan-2009 |
Harvey Harrison <harvey.harrison@gmail.com> |
PCI: __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f5ddcac4 |
|
09-Jan-2009 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: fix missing kernel-doc and typos Fix pci kernel-doc parameter missing notation, correct function name, and fix typo: Warning(linux-2.6.28-git10//drivers/pci/pci.c:1511): No description found for parameter 'exclusive' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
49c96811 |
|
03-Feb-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Read power state from device after trying to change it on resume pci_restore_standard_config() unconditionally changes current_state to PCI_D0 after attempting to change the device's power state, but it should rather read the actual current power state from the device. 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>
|
#
144a76bc |
|
03-Feb-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Check if the state has been saved before trying to restore it Check if the standard configuration registers of a PCI device have been saved during suspend before trying to restore them during resume. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-By: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
476e7fae |
|
22-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Do not wait for buses in B2 or B3 during resume pci_restore_standard_config() adds extra delay for PCI buses in low power states (B2 or B3), but this is only correct for buses in B2, because the buses in B3 are reset when they are put back into B0. Thus we should wait for such buses to settle after the reset, but it's not a good idea to wait that long (1.1 s) with interrupts off. On the other hand, we have never waited for buses in B2 and B3 during resume and it seems reasonable to go back to this well tested behaviour. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
48f67f54 |
|
22-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Power up devices before restoring their state Devices that have MSI-X enabled before suspend to RAM or hibernation and that are in a low power state during resume will not be handled correctly by pci_restore_standard_config(). Namely, it first calls pci_restore_state() which calls pci_restore_msi_state(), which in turn executes __pci_restore_msix_state() that accesses the device's memory space to restore the contents of the MSI-X table. However, if the device is in a low power state at this point, it's memory space is not accessible. The easiest way to fix this potential problem is to make pci_restore_standard_config() call pci_restore_state() after it has put the device into the full power state, D0. Fortunately, all of this is done with interrupts off, so the change of ordering should not cause any trouble. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> 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>
|
#
50246dd4 |
|
16-Jan-2009 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "PCI PM: Register power state of devices during initialization" This reverts commit 98e6e286d7b01deb7453b717aa38ebb69d6cefc0, as Yinghai Lu reports that it breaks kexec with at least the e1000 and e1000e drivers. The reason is that the shutdown sequence puts the hardware into D3 sleep, and the commit causes us to claim that it then is in D0 (running) state just because we don't understand the PM capabilities. Which then later makes "pci_set_power_state()" not do anything, and the device never wakes up properly and just returns 0xff to everything. Reported-by: Yinghai Lu <yinghai@kernel.org> Acked-by: From: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
98e6e286 |
|
07-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Register power state of devices during initialization Use the observation that the power state of a PCI device can be loaded into its pci_dev structure as soon as pci_pm_init() is run for it and make that happen. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> 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>
|
#
6a479079 |
|
22-Dec-2008 |
Ben Hutchings <bhutchings@solarflare.com> |
PCI: Add pci_clear_master() as opposite of pci_set_master() During an online device reset it may be useful to disable bus-mastering. pci_disable_device() does that, and far more besides, so is not suitable for an online reset. Add pci_clear_master() which does just this. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
68feac87 |
|
16-Dec-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: add pci_common_swizzle() for INTx swizzling This patch adds pci_common_swizzle(), which swizzles INTx values all the way up to a root bridge. This common implementation can replace several architecture-specific ones. This should someday be combined with pci_get_interrupt_pin(), but I left it separate for now to make reviewing easier. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f06fc0b6 |
|
27-Dec-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Fix pci_update_current_state Currently, PCI devices without the PM capability that are power manageable by the platform (eg. ACPI) are not handled correctly by pci_set_power_state(), because their current_state field is not updated to reflect the new power state of the device. Fix this by making pci_update_current_state() accept additional argument representing the power state of the device as set by the platform. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> 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>
|
#
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>
|
#
bc5f5a82 |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: remove unnecessary condition check in pci_restore_bars() Remove the unnecessary number of resources condition checks because the pci_update_resource() will check availability of the resources. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
14add80b |
|
21-Nov-2008 |
Yu Zhao <yu.zhao@intel.com> |
PCI: remove unnecessary arg of pci_update_resource() This cleanup removes unnecessary argument 'struct resource *res' in pci_update_resource(), so it takes same arguments as other companion functions (pci_assign_resource(), etc.). Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
1684f5dd |
|
01-Dec-2008 |
Andrew Morton <akpm@linux-foundation.org> |
PCI: uninline pci_ioremap_bar() It's too large to be inlined. Acked-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
bebd590c |
|
16-Dec-2008 |
Alan Stern <stern@rowland.harvard.edu> |
PCI: fix incorrect error return in pci_enable_wake This patch (as1186) fixes a minor mistake in pci_enable_wake(). When the routine is asked to disable remote wakeup, it should not return an error merely because the device is not allowed to do wakeups! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
57c2cf71 |
|
11-Dec-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: add pci_swizzle_interrupt_pin() This patch adds pci_swizzle_interrupt_pin(), which implements the INTx swizzling algorithm specified in Table 9-1 of the "PCI-to-PCI Bridge Architecture Specification," revision 1.2. There are many architecture-specific implementations of this swizzle that can be replaced by this common one. Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
878f2e50 |
|
09-Dec-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: use config space encoding in pci_get_interrupt_pin() This patch makes pci_get_interrupt_pin() return values encoded the same way as the "Interrupt Pin" value in PCI config space, i.e., 1=INTA, ..., 4=INTD. pirq_bios_set() is the only in-tree caller of pci_get_interrupt_pin() and pci_get_interrupt_pin() is not exported. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: hpa@zytor.com Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.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>
|
#
e8de1481 |
|
22-Oct-2008 |
Arjan van de Ven <arjan@linux.intel.com> |
resource: allow MMIO exclusivity for device drivers Device drivers that use pci_request_regions() (and similar APIs) have a reasonable expectation that they are the only ones accessing their device. As part of the e1000e hunt, we were afraid that some userland (X or some bootsplash stuff) was mapping the MMIO region that the driver thought it had exclusively via /dev/mem or via various sysfs resource mappings. This patch adds the option for device drivers to cause their reserved regions to the "banned from /dev/mem use" list, so now both kernel memory and device-exclusive MMIO regions are banned. NOTE: This is only active when CONFIG_STRICT_DEVMEM is set. In addition to the config option, a kernel parameter iomem=relaxed is provided for the cases where developers want to diagnose, in the field, drivers issues from userspace. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> 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>
|
#
0ef5f8f6 |
|
10-Nov-2008 |
Andrew Patterson <andrew.patterson@hp.com> |
ACPI/PCI: PCI extended config _OSC support called when root bridge added The _OSC capability OSC_EXT_PCI_CONFIG_SUPPORT is set when the root bridge is added with pci_acpi_osc_support() if we can access PCI extended config space. This adds the function pci_ext_cfg_avail which returns true if we can access PCI extended config space (offset greater than 0xff). It currently only returns false if arch=x86 and raw_pci_ext_ops is not set (which might happen if pci=nommcfg is set on the kernel command-line). Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
1ca88797 |
|
11-Nov-2008 |
Sheng Yang <sheng@linux.intel.com> |
PCI: Extend pci_reset_function() to support PCI Advanced Features Some PCI devices implement PCI Advanced Features, which means they support Function Level Reset(FLR). Implement support for that in pci_reset_function. Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d91cdc74 |
|
11-Nov-2008 |
Sheng Yang <sheng@linux.intel.com> |
PCI: Refactor pci_reset_function() Separate out function level reset so that pci_reset_function can be more easily extended. Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ad04d31e |
|
22-Nov-2008 |
Al Viro <viro@ftp.linux.org.uk> |
pci_setup() is init, not devinit for fsck sake, it's used only when parsing kernel command line... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
1df8fb3d |
|
11-Nov-2008 |
Sheng Yang <sheng@linux.intel.com> |
PCI: Fix disable IRQ 0 in pci_reset_function() Before initialization, dev->irq may be zero. Make sure we don't disable it at reset time in that case. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8113587c |
|
22-Oct-2008 |
Zhao, Yu <yu.zhao@intel.com> |
PCI: fix ARI code to be compatible with mixed ARI/non-ARI systems The original ARI support code has a compatibility problem with non-ARI devices. If a device doesn't support ARI, turning on ARI forwarding on its upper level bridge will cause undefined behavior. This fix turns on ARI forwarding only when the subordinate devices support it. Tested-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8dd7f803 |
|
21-Oct-2008 |
Sheng Yang <sheng@linux.intel.com> |
PCI: add support for function level reset Sometimes, it's necessary to enable software's ability to quiesce and reset endpoint hardware with function-level granularity, so provide support for it. The patch implement Function Level Reset(FLR) feature following PCI-e spec. And this is the first step. We would add more generic method, like D0/D3, to allow more devices support this function. The patch contains two functions. pcie_reset_function() is the new driver API, and, contains some action to quiesce a device. The other function is a helper: pcie_execute_reset_function() just executes the reset for a particular device function. Current the usage model is in KVM. Function reset is necessary for assigning device to a guest, or moving it between partitions. For Function Level Reset(FLR), please refer to PCI Express spec chapter 6.6.2. Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> 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>
|
#
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>
|
#
ec84f126 |
|
23-Sep-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: fix -Wakpm warnings in pci_pm_init debug output Checkpatch would have complained about this but neither Bjorn nor myself ran it prior to pushing. Fixup the issues Andrew pointed out. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c9ed77ee |
|
22-Aug-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: tidy PME support messages This patch changes these two messages: pci 0000:00:03.0: supports D1 pci 0000:00:03.0: supports D2 to this: pci 0000:00:03.0: supports D1 D2 It also trivially converts a "dev_printk(KERN_INFO, ...)" to "dev_info(...)". Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0235c4fc |
|
18-Aug-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Introduce function pci_wake_from_d3 Many device drivers use the following sequence of statements to enable the device to wake up the system while being in the D3_hot or D3_cold low power state: pci_enable_wake(pdev, PCI_D3hot, 1); pci_enable_wake(pdev, PCI_D3cold, 1); However, the second call is not necessary if the first one succeeds (the ordering of the statements above doesn't matter here) and it may even be harmful, because we are not supposed to enable PME# after the wake-up power has been enabled for the device. To allow drivers to overcome this problem, introduce function pci_wake_from_d3() that will enable the device to wake up the system from any of D3_hot and D3_cold as long as the wake-up from at least one of them is supported. Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
096e6f67 |
|
19-Oct-2008 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
pci: Use new %pR to print resource ranges This converts things in drivers/pci to use %pR to printout the content of a struct resource instead of hand-casted %llx or other variants. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
5a6c9b60 |
|
07-Aug-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Export pci_pme_active to drivers Export pci_pme_active() to drivers, so that they can clear the PME_status bit and disable PME# for their devices without involving ACPI. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
979b1791 |
|
24-Jul-2008 |
Alan Cox <alan@lxorguk.ukuu.org.uk> |
PCI: add D3 power state avoidance quirk Libata has some hacks to deal with certain controllers going silly in D3 state. The right way to handle this is to keep a PCI device flag for such devices. That can then be generalised for no ATA devices with power problems. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
37139074 |
|
28-Jul-2008 |
Jesse Barnes <jbarnes@hobbes.lan> |
PCI: document pci_target_state The empty kdoc was causing warnings, so provide some actual documentation. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e5899e1b |
|
19-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: make more PCI PM core functionality available to drivers Make more PCI PM core functionality available to drivers * Export pci_pme_capable() so that it can be called directly by drivers (for example, tg3 needs that). * Move the state choosing part of pci_prepare_to_sleep() to a separate function, pci_target_state(), that can be called directly by drivers (for example, tg3 needs that). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
443bd1c4 |
|
21-Jul-2008 |
Randy Dunlap <randy.dunlap@oracle.com> |
pci kernel-doc fatal error Fix kernel-doc comments so that they don't produce errors. Also cut some extraneous copy-paste text. Error(linhead//drivers/pci/pci.c:1133): duplicate section name 'Description' Error(linhead//drivers/pci/pci.c:1189): duplicate section name 'Description' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
|
#
c300bd2fb |
|
09-Jul-2008 |
Stephen Rothwell <sfr@canb.auug.org.au> |
PCI: include linux/pm_wakeup.h for device_set_wakeup_capable drivers/pci/pci.c needs pm_wakeup.h since it uses device_set_wakup_capable(). The latter also needs to be stubbed out for !CONFIG_PM. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c157dfa3 |
|
13-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Fix pci_prepare_to_sleep The recently introduced pci_prepare_to_sleep() needs the following fix, because there are systems which are not power manageable by ACPI (ie. ACPI doesn't provide methods to put the device into low power states and back), but require ACPI hooks to be executed for wake-up to work. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
337001b6 |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: Simplify PCI device PM code If the offset of PCI device's PM capability in its configuration space, the mask of states that the device supports PME# from and the D1 and D2 support bits are cached in the corresponding struct pci_dev, the PCI device PM code can be simplified quite a bit. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
404cc2d8 |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: Introduce pci_prepare_to_sleep and pci_back_from_sleep Introduce functions pci_prepare_to_sleep() and pci_back_from_sleep(), to be used by the PCI drivers that want to place their devices into the lowest power state appropiate for them (PCI_D3hot, if the device is not supposed to wake up the system, or the deepest state from which the wake-up is possible, otherwise) while the system is being prepared to go into a sleeping state and to put them back into D0 during the subsequent transition to the working state. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
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>
|
#
44e4e66e |
|
06-Jul-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI: rework pci_set_power_state function to call platform first Rework pci_set_power_state() so that the platform callback is invoked before the native mechanism, if necessary. Also, make the function check if the device is power manageable by the platform before invoking the platform callback. This may matter if the device dependent on additional power resources controlled by the platform is being put into D0, in which case those power resources must be turned on before we attempt to handle the device itself. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> 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>
|
#
e4ec7a00 |
|
25-Jun-2008 |
Jesse Barnes <jbarnes@hobbes.(none)> |
PCI: correct resource number in debug output If pci_request_region fails, make the warning include the resource number, not the resource number + 1.
|
#
80ccba11 |
|
13-Jun-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: use dev_printk when possible Convert printks to use dev_printk(). I converted pr_debug() to dev_dbg(). Both use KERN_DEBUG and are enabled only when DEBUG is defined. I converted printk(KERN_DEBUG) to dev_printk(KERN_DEBUG), not to dev_dbg(), because dev_dbg() is only enabled when DEBUG is defined. I converted DBG(KERN_INFO) (only in setup-bus.c) to dev_info(). The DBG() name makes it sound like debug, but it's been enabled forever, so dev_info() preserves the previous behavior. I tried to make the resource assignment formats more consistent, e.g., "BAR %d: got res [%#llx-%#llx] bus [%#llx-%#llx] flags %#lx\n" instead of sometimes using "start-end" and sometimes using "size@start". I'm not attached to one or the other; I'd just like them consistent. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.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>
|
#
cf35e4ad |
|
19-May-2008 |
Adrian Bunk <bunk@kernel.org> |
PCI: remove CVS keywords This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
66bef8c0 |
|
03-Mar-2008 |
Harvey Harrison <harvey.harrison@gmail.com> |
PCI: replace remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
7d715a6c |
|
24-Feb-2008 |
Shaohua Li <shaohua.li@intel.com> |
PCI: add PCI Express ASPM support PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: -default, BIOS default setting -powersave, highest power saving mode, enable all available ASPM state and clock power management -performance, highest performance, disable ASPM and clock power management By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. Note: some devices might not work well with aspm, either because chipset issue or device issue. The patch provide API (pci_disable_link_state), driver can disable ASPM for specific device. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
49741c4d |
|
17-Mar-2008 |
Andrew Morton <akpm@linux-foundation.org> |
PCI: revert "pcie: utilize pcie transaction pending bit" Revert as it is reported to cause problems for people. commit 4348a2dc49f9baecd34a9b0904245488c6189398 Author: Shaohua Li <shaohua.li@intel.com> Date: Wed Oct 24 10:45:08 2007 +0800 pcie: utilize pcie transaction pending bit PCIE has a mechanism to wait for Non-Posted request to complete. I think pci_disable_device is a good place to do this. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Due to the regression reported at http://bugzilla.kernel.org/show_bug.cgi?id=10065 Cc: Shaohua Li <shaohua.li@intel.com> Cc: Soeren Sonnenburg <kernel@nn7.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3a2d5b70 |
|
23-Feb-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Introduce PM_EVENT_HIBERNATE callback state During the last step of hibernation in the "platform" mode (with the help of ACPI) we use the suspend code, including the devices' ->suspend() methods, to prepare the system for entering the ACPI S4 system sleep state. But at least for some devices the operations performed by the ->suspend() callback in that case must be different from its operations during regular suspend. For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and pass it to the device drivers' ->suspend() methods during the last phase of hibernation, so that they can distinguish this case and handle it as appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a special way and need to handle PM_EVENT_HIBERNATE in the same way. These changes are necessary to fix a hibernation regression related to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Tested-by: Jeff Chua <jeff.chua.linux@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
59fc67de |
|
04-Feb-2008 |
FUJITA Tomonori <tomof@acm.org> |
iommu sg merging: PCI: add dma segment boundary support This adds PCI's accessor for segment_boundary_mask in device_dma_parameters. The default segment_boundary is set to 0xffffffff, same to the block layer's default value (and the scsi mid layer uses the same value). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Greg KH <greg@kroah.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
4d57cdfa |
|
04-Feb-2008 |
FUJITA Tomonori <tomof@acm.org> |
iommu sg merging: PCI: add device_dma_parameters support This adds struct device_dma_parameters in struct pci_dev and properly sets up a pointer in struct device. The default max_segment_size is set to 64K, same to the block layer's default value. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Mostly-acked-by: Jeff Garzik <jeff@garzik.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
cc3a1378 |
|
02-Feb-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
Revert "PCI: PCIE ASPM support" This reverts commit 6c723d5bd89f03fc3ef627d50f89ade054d2ee3b. It caused build errors on non-x86 platforms, config file confusion, and even some boot errors on some x86-64 boxes. All around, not quite ready for prime-time :( Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6c723d5b |
|
23-Jan-2008 |
Shaohua Li <shaohua.li@intel.com> |
PCI: PCIE ASPM support PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: -default, BIOS default setting -powersave, highest power saving mode, enable all available ASPM state and clock power management -performance, highest performance, disable ASPM and clock power management By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
7cbe5b60 |
|
19-Dec-2007 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
PCI: Remove pci_enable_device_bars() Now that all in-tree users are gone, this removes pci_enable_device_bars() completely. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b718989d |
|
19-Dec-2007 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
PCI: Add pci_enable_device_{io,mem} intefaces The pci_enable_device_bars() interface isn't well suited to PCI because you can't actually enable/disable BARs individually on a device. So for example, if a device has 2 memory BARs 0 and 1, and one of them (let's say 1) has not been successfully allocated by the firmware or the kernel, then enabling memory decoding shouldn't be permitted for the entire device since it will decode whatever random address is still in that BAR 1. So a device must be either fully enabled for IO, for Memory, or for both. Not on a per-BAR basis. This provides two new functions, pci_enable_device_io() and pci_enable_device_mem() to replace pci_enable_device_bars(). The implementation internally builds a BAR mask in order to be able to use existing arch infrastructure. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
017fc480 |
|
17-Dec-2007 |
Shaohua Li <shaohua.li@intel.com> |
PCI: avoid save the same type of cap multiple times Avoid adding the same type of cap multiple times, otherwise we will see dead loop. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ec0a3a27 |
|
17-Dec-2007 |
Shaohua Li <shaohua.li@intel.com> |
PCI: correctly initialize a structure for pcie_save_pcix_state() save_state->cap_nr should be correctly set, otherwise we can't find the saved cap at resume. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f34303de |
|
17-Dec-2007 |
Shaohua Li <shaohua.li@intel.com> |
PCI: fix typo in pci_save_pcix_state pci_save/store_state has multiple bugs, which will cause cap can't be saved/restored correctly. Below 3 patches fix them. fix the typo in pci_save_pcix_state Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4348a2dc |
|
23-Oct-2007 |
Shaohua Li <shaohua.li@intel.com> |
pcie: utilize pcie transaction pending bit PCIE has a mechanism to wait for Non-Posted request to complete. I think pci_disable_device is a good place to do this. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ad668599 |
|
26-Oct-2007 |
Adrian Bunk <bunk@kernel.org> |
PCI: make pci_restore_bars() static This patch makes the needlessly global pci_restore_bars() static. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b95d58ea |
|
30-Jan-2008 |
Tejun Heo <htejun@gmail.com> |
pci: allow multiple calls to pcim_enable_device() There's no reason not to allow multiple calls to pcim_enable_device(). Calls after the first one can simply be noop. All PCI resources will be released when the initial pcim_enable_device() resource is released. This allows more flexibility to managed PCI users. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
#
b4482a4b |
|
14-Oct-2007 |
Al Viro <viro@ftp.linux.org.uk> |
more trivial signedness fixes in drivers Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
32a2eea7 |
|
11-Oct-2007 |
Jeff Garzik <jeff@garzik.org> |
PCI: Add 'nodomains' boot option, and pci_domains_supported global * Introduce pci_domains_supported global, hardcoded to zero if !CONFIG_PCI_DOMAINS. * Introduce 'nodomains' boot option, which clears pci_domains_supported on platforms that enable it by default (x86, x86-64, and others when they are converted to use this). Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
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>
|
#
229f5afd |
|
13-Aug-2007 |
vignesh babu <vignesh.babu@wipro.com> |
PCI: is_power_of_2 in drivers/pci/pci.c Replacing n & (n - 1) for power of 2 check by is_power_of_2(n) Signed-off-by: vignesh babu <vignesh.babu@wipro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
0b62e13b |
|
26-Jul-2007 |
Tejun Heo <htejun@gmail.com> |
pci: rename __pci_reenable_device() to pci_reenable_device() Rename __pci_reenable_device() to pci_reenable_device(). Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
#
42e61f4a |
|
23-Jul-2007 |
Randy Dunlap <randy.dunlap@oracle.com> |
kernel-doc fixes for PCI and drivers/base/ Fix undocumented function parameters in PCI and drivers/base. Warning(linux-2.6.23-rc1//drivers/pci/pci.c:1526): No description found for parameter 'rq' Warning(linux-2.6.23-rc1//drivers/base/firmware_class.c:245): No description found for parameter 'bin_attr' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> 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>
|
#
cca03dec |
|
09-Jul-2007 |
Andrew Lunn <andrew.lunn@ascom.ch> |
PCI: pci_set_power_state(): check for PM capabilities earlier Check for PCI_CAP_ID_PM before checking the device state. Apparently fixes some log spam via the 3c59x driver. Signed-off-by: Andrew Lunn <andrew.lunn@ascom.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
694625c0 |
|
09-Jul-2007 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: add pci_try_set_mwi As suggested by Andrew, add pci_try_set_mwi(), which does not require return-value checking. - add pci_try_set_mwi() without __must_check - make it return 0 on success, errno if the "try" failed or error - review callers Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b7b095c1 |
|
09-Jul-2007 |
Andrew Morton <akpm@linux-foundation.org> |
PCI: pci-x-pci-express-read-control-interfaces cleanups - remove unneeded local - 80-col fix Cc: Peter Oruba <peter.oruba@amd.com> Cc: Roland Dreier <rolandd@cisco.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
d556ad4b |
|
15-May-2007 |
Peter Oruba <peter.oruba@amd.com> |
PCI: add PCI-X/PCI-Express read control interfaces This patch introduces an interface to read and write PCI-X / PCI-Express maximum read byte count values from PCI config space. There is a second function that returns the maximum _designed_ read byte count, which marks the maximum value for a device, since some drivers try to set MMRBC to the highest allowed value and rely on such a function. Based on patch set by Stephen Hemminger <shemminger@linux-foundation.org> Cc: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Peter Oruba <peter.oruba@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
96bde06a |
|
26-Mar-2007 |
Sam Ravnborg <sam@ravnborg.org> |
pci: do not mark exported functions as __devinit Functions marked __devinit will be removed after kernel init. But being exported they are potentially called by a module much later. So the safer choice seems to be to keep the function even in the non CONFIG_HOTPLUG case. This silence the follwoing section mismatch warnings: WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus' Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
8d7d86e9 |
|
16-Mar-2007 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI: kernel-doc fix Warning(linux-2621-rc3g7/drivers/pci/pci.c:1283): No description found for parameter 'dev' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f7bdd12d |
|
06-Apr-2007 |
Brian King <brking@linux.vnet.ibm.com> |
pci: New PCI-E reset API Adds a new API which can be used to issue various types of PCI-E reset, including PCI-E warm reset and PCI-E hot reset. This is needed for an ipr PCI-E adapter which does not properly implement BIST. Running BIST on this adapter results in PCI-E errors. The only reliable reset mechanism that exists on this hardware is PCI Fundamental reset (warm reset). Since driving this type of reset is architecture unique, this provides the necessary hooks for architectures to add this support. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Acked-by: Linas Vepstas <linas@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
075c1771 |
|
26-Apr-2007 |
David Brownell <david-b@pacbell.net> |
define platform wakeup hook, use in pci_enable_wake() This defines a platform hook to enable/disable a device as a wakeup event source. It's initially for use with ACPI, but more generally it could be used whenever enable_irq_wake()/disable_irq_wake() don't suffice. The hook is called -- if available -- inside pci_enable_wake(); and the semantics of that call are enhanced so that support for PCI PME# is no longer needed. It can now work for devices with "legacy PCI PM", when platform support allows it. (That support would use some board-specific signal for for the same purpose as PME#.) [akpm@linux-foundation.org: Make it compile with CONFIG_PM=n] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
9f35575d |
|
08-Mar-2007 |
Eric W. Biederman <ebiederm@xmission.com> |
[PATCH] pci: Repair pci_save/restore_state so we can restore one save many times. Because we do not reserve space for the pci-x and pci-e state in struct pci dev we need to dynamically allocate it. However because we need to support restore being called multiple times after a single save it is never safe to free the buffers we have allocated to hold the state. So this patch modifies the save routines to first check to see if we have already allocated a state buffer before allocating a new one. Then the restore routines are modified to not free the state after restoring it. Simple and it fixes some subtle error path handling bugs, that are hard to test for. 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>
|
#
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>
|
#
7f375f32 |
|
25-Feb-2007 |
Tejun Heo <htejun@gmail.com> |
PCI: allow multiple calls to pcim_pin_device() Sanity check in pcim_pin_device() was too restrictive in that it didn't allow multiple calls to the function, which is against the devres philosohpy of fire-and-forget. Track pinned status separately and allow pinning multiple times. Signed-off-by: Tejun Heo <htejun@gmail.com> Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
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>
|
#
4516a618 |
|
05-Feb-2007 |
Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
PCI: Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE boot options CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f95d882d |
|
10-Feb-2007 |
Randy Dunlap <randy.dunlap@oracle.com> |
PCI/sysfs/kobject kernel-doc fixes Fix kernel-doc warnings in PCI, sysfs, and kobject files. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
9ac7849e |
|
20-Jan-2007 |
Tejun Heo <htejun@gmail.com> |
devres: device resource management Implement device resource management, in short, devres. A device driver can allocate arbirary size of devres data which is associated with a release function. On driver detach, release function is invoked on the devres data, then, devres data is freed. devreses are typed by associated release functions. Some devreses are better represented by single instance of the type while others need multiple instances sharing the same release function. Both usages are supported. devreses can be grouped using devres group such that a device driver can easily release acquired resources halfway through initialization or selectively release resources (e.g. resources for port 1 out of 4 ports). This patch adds devres core including documentation and the following managed interfaces. * alloc/free : devm_kzalloc(), devm_kzfree() * IO region : devm_request_region(), devm_release_region() * IRQ : devm_request_irq(), devm_free_irq() * DMA : dmam_alloc_coherent(), dmam_free_coherent(), dmam_declare_coherent_memory(), dmam_pool_create(), dmam_pool_destroy() * PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed() * iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(), devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(), pcim_iomap(), pcim_iounmap() Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.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>
|
#
e36c455c |
|
15-Jan-2007 |
Pavel Machek <pavel@ucw.cz> |
PCI: power management: remove noise on non-manageable hw Return early from pci_set_power_state() if hardware does not support power management. This way, we do not generate noise in the logs. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
8255cf35 |
|
06-Jan-2007 |
Adrian Bunk <bunk@stusta.de> |
PCI: make isa_bridge Alpha-only Since isa_bridge is neither assigned any value !NULL nor used on !Alpha, there's no reason for providing it. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
c30ca1db |
|
18-Dec-2006 |
Adrian Bunk <bunk@stusta.de> |
PCI: quirks.c: cleanup This patch contains the following cleanups: - move all EXPORT_SYMBOL's directly below the code they are exporting - move all DECLARE_PCI_FIXUP_*'s directly below the functions they are calling Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
c87deff7 |
|
17-Dec-2006 |
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> |
PCI : Add selected_regions funcs This patch adds the following changes into generic PCI code especially for PCI legacy I/O port free drivers. - Added new pci_request_selected_regions() and pci_release_selected_regions() for PCI legacy I/O port free drivers in order to request/release only the selected regions. - Added helper routine pci_select_bars() which makes proper mask of BARs from the specified resource type. This would be very helpful for users of pci_enable_device_bars(). 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>
|
#
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>
|
#
9fb625c3 |
|
17-Dec-2006 |
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> |
PCI : Move pci_fixup_device and is_enabled (originally intended change) Original patch was posted as "PCI : Move pci_fixup_device and is_enabled". This 2 of 3 patches does: - Move pci_fixup_device and enable_cnt (originally intended change) - relocate pci_fixup_device (recover latter 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>
|
#
47a4d5be |
|
11-Jan-2007 |
Brice Goglin <brice@myri.com> |
[PATCH] increment pos before looking for the next cap in __pci_find_next_ht_cap While testing 2.6.20-rc3 on a machine with some CK804 chipsets, we noticed that quirk_nvidia_ck804_msi_ht_cap() was not detecting HT MSI capabilities anymore. It is actually caused by the MSI mapping on the root chipset being the 2nd HT capability in the chain. pci_find_ht_capability() does not seem to find anything but the first HT cap correctly, because it forgets to increment the position before looking for the next cap. The following patch seems to fix it. At least, this proves that having a ttl is good idea since the machine would have been stucked in an infinite loop if we didn't have a ttl :) We have to pass pos + PCI_CAP_LIST_NEXT to __pci_find_next_cap_ttl to get the next HT cap instead of the same one again. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Andrew J. Gallatin <gallatin@myri.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
687d5fe3 |
|
22-Nov-2006 |
Michael Ellerman <michael@ellerman.id.au> |
PCI: Add pci_find_ht_capability() for finding Hypertransport capabilities There are already several places in the kernel that want to search a PCI device for a given Hypertransport capability. Although this is possible using pci_find_capability() etc., it makes sense to encapsulate that logic in a helper - pci_find_ht_capability(). To cater for searching exhaustively for a capability, we also provide pci_find_next_ht_capability(). We also need to cater for the fact that the HT capability fields may be either 3 or 5 bits wide. pci_find_ht_capability() deals with this for you, but callers using the #defines directly must handle that themselves. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
d3bac118 |
|
22-Nov-2006 |
Michael Ellerman <michael@ellerman.id.au> |
PCI: Create __pci_bus_find_cap_start() from __pci_bus_find_cap() The current implementation of __pci_bus_find_cap() does two things, first it determines the start of the capability chain for the device, and then it trys to find the requested capability. Split these out, so that we can use the two parts independantly in a subsequent patch. Externally visible behaviour should be unchanged. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> 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>
|
#
edb2d97e |
|
10-Oct-2006 |
Matthew Wilcox <willy@infradead.org> |
PCI: Replace HAVE_ARCH_PCI_MWI with PCI_DISABLE_MWI pSeries is the only architecture left using HAVE_ARCH_PCI_MWI and it's really inappropriate for its needs. It really wants to disable MWI altogether. So here are a pair of stub implementations for pci_set_mwi and pci_clear_mwi. Also rename pci_generic_prep_mwi to pci_set_cacheline_size since that better reflects what it does. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Cc: Paul Mackerras <paulus@samba.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ebf5a248 |
|
10-Oct-2006 |
Matthew Wilcox <willy@infradead.org> |
PCI: Use pci_generic_prep_mwi on sparc64 The setting of the CACHE_LINE_SIZE register in sparc64's pci initialisation code isn't quite adequate as the device may have incompatible requirements. The generic code tests for this, so switch sparc64 over to using it. Since sparc64 has different L1 cache line size and PCI cache line size, it would need to override the generic code like i386 and ia64 do. We know what the cache line size is at compile time though, so introduce a new optional constant PCI_CACHE_LINE_BYTES. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: David Miller <davem@davemloft.net> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
cc692a5f |
|
08-Nov-2006 |
Stephen Hemminger <shemminger@osdl.org> |
PCI: save/restore PCI-X state Shouldn't PCI-X state be saved/restored? No device really needs this right now. qla24xx (fc HBA) and mthca (infiniband) don't do suspend, and sky2 resets its tweaks when links are brought up. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b56a5a23 |
|
21-Aug-2006 |
Michael S. Tsirkin <mst@mellanox.co.il> |
PCI: Restore PCI Express capability registers after PM event Restore PCI Express capability registers after PM event. This includes maxumum MTU for PCI express and other vital data. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
0637a70a |
|
26-Sep-2006 |
Andi Kleen <ak@linux.intel.com> |
[PATCH] x86: Allow disabling early pci scans with pci=noearly or disallowing conf1 Some buggy systems can machine check when config space accesses happen for some non existent devices. i386/x86-64 do some early device scans that might trigger this. Allow pci=noearly to disable this. Also when type 1 is disabling also don't do any early accesses which are always type1. This moves the pci= configuration parsing to be a early parameter. I don't think this can break anything because it only changes a single global that is only used by PCI. Cc: gregkh@suse.de Cc: Trammell Hudson <hudson@osresearch.net> Signed-off-by: Andi Kleen <ak@suse.de>
|
#
b887d2e6 |
|
15-Aug-2006 |
David Brownell <david-b@pacbell.net> |
PM: PCI and IDE handle PM_EVENT_PRETHAW Convert some framework code to handle the new PRETHAW message. - IDE just treats it like a FREEZE. - The pci_choose_state() thingie still doesn't use PCI_D0 when it gets a FREEZE (and now PRETHAW) event, which seems rather buglike but wasn't something to change with this patch. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> 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>
|
#
1396a8c3 |
|
12-Jun-2006 |
Greg Kroah-Hartman <gregkh@suse.de> |
[PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers This is needed if we wish to change the size of the resource structures. Based on an original patch 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>
|
#
d6e05edc |
|
26-Jun-2006 |
Andreas Mohr <andi@lisas.de> |
spelling fixes acquired (aquired) contiguous (contigious) successful (succesful, succesfull) surprise (suprise) whether (weather) some other misspellings Signed-off-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
#
99dc804d |
|
25-May-2006 |
Shaohua Li <shaohua.li@intel.com> |
[PATCH] PCI: disable msi mode in pci_disable_device Brice said the pci_save_msi_state breaks his driver in his special usage (not in suspend/resume), as pci_save_msi_state will disable msi mode. In his usage, pci_save_state will be called at runtime, and later (after the device operates for some time and has an error) pci_restore_state will be called. In another hand, suspend/resume needs disable msi mode, as device should stop working completely. This patch try to workaround this issue. Drivers are expected call pci_disable_device in suspend time after pci_save_state. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
a1e022b3 |
|
28-Apr-2006 |
Kristen Accardi <kristen.c.accardi@intel.com> |
[PATCH] PCI: don't enable device if already enabled If a device is already enabled, don't bother reenabling it. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Acked-By: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
8b8c8d28 |
|
25-Apr-2006 |
Yu, Luming <luming.yu@intel.com> |
[PATCH] PCI: reverse pci config space restore order According to Intel ICH spec, there are several rules that Base Address should be programmed before IOSE (PCICMD register ) enabled. For example ICH7: 12.1.3 SATA : the base address register for the bus master register should be programmed before this bit is set. 11.1.3: PCICMD (USB): The base address register for USB should be programmed before this bit is set. .... To make sure kernel code follow this rule , and prevent unnecessary confusion. I proposal this patch. Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
04d9c1a1 |
|
18-Apr-2006 |
Dave Jones <davej@redhat.com> |
[PATCH] PCI: Improve PCI config space writeback At least one laptop blew up on resume from suspend with a black screen due to a lack of this patch. By only writing back config space that is different, we minimise the possibility of accidents like this. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3a720d72 |
|
23-May-2006 |
Brice Goglin <brice@myri.com> |
[PATCH] Revive pci_find_ext_capability This patch revives pci_find_ext_capability (has been disabled a couple month ago since it was not used anywhere. See http://lkml.org/lkml/2006/1/20/247). It will now be used by the myri10ge driver. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Andrew J. Gallatin <gallatin@myri.com> drivers/pci/pci.c | 3 +-- include/linux/pci.h | 2 ++ 2 files changed, 3 insertions(+), 2 deletions(-) Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
#
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>
|
#
02669492 |
|
23-Mar-2006 |
Andrew Morton <akpm@osdl.org> |
[PATCH] pm: print name of failed suspend function Print more diagnostic info to help identify the source of power management suspend failures. Example: usb_hcd_pci_suspend(): pci_set_power_state+0x0/0x1af() returns -22 pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x11b() returns -22 suspend_device(): pci_device_suspend+0x0/0x34() returns -22 Work-in-progress. It needs lots more suspend_report_result() calls sprinkled everywhere. Cc: Patrick Mochel <mochel@digitalimplant.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@suspend2.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3c990e92 |
|
04-Mar-2006 |
Jeff Garzik <jeff@garzik.org> |
[PATCH] PCI: fix pci_request_region[s] arg Add missing 'const' to pci_request_region[s] 'res_name' arg, since we pass it directly to __request_region(), whose 'name' arg is also const. 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>
|
#
b82db5ce |
|
17-Jan-2006 |
Kristen Accardi <kristen.c.accardi@intel.com> |
[PATCH] PCI: return max reserved busnr Change the semantics of this call to return the max reserved bus number instead of just the max assigned bus number. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b64c05e7 |
|
14-Jan-2006 |
Grant Grundler <grundler@parisc-linux.org> |
[PATCH] PCI: clean up msi.c a bit Clean up: move assignments outside of if() statements. AFAICT, no functional change. Easier to read/understand. Depends on "[PATCH 1/3] msi vector targeting abstractions" by Mark Maule <maule@sgi.com>. I expect one hunk to fail if applied against 2.6.15. This is essentially Joe Perches' patch. I've cleaned up the one instance added by Mark's patch. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f8d65713 |
|
05-Jan-2006 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] PCI: drivers/pci/pci.c: #if 0 pci_find_ext_capability() This patch #if 0's the unused global function pci_find_ext_capability(). Signed-off-by: Adrian Bunk <bunk@stusta.de> 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>
|
#
514d207d |
|
02-Nov-2005 |
Kristen Accardi <kristen.c.accardi@intel.com> |
[PATCH] pci: use pin stored in pci_dev Use the stored value of the interrupt pin rather than try to read the config again. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
24a4e377 |
|
28-Oct-2005 |
Roland Dreier <rolandd@cisco.com> |
[PATCH] PCI: add pci_find_next_capability() Some devices have more than one capability of the same type. For example, the PCI header for the PathScale InfiniPath looks like: 04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02) Subsystem: Unknown device 1fc1:000d Flags: bus master, fast devsel, latency 0, IRQ 193 Memory at fea00000 (64-bit, non-prefetchable) [size=2M] Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration There are _two_ HyperTransport capabilities, and the PathScale driver wants to look at both of them. The current pci_find_capability() API doesn't work for this, since it only allows us to get to the first capability of a given type. The patch below introduces a new pci_find_next_capability(), which can be used in a loop like for (pos = pci_find_capability(pdev, <ID>); pos; pos = pci_find_next_capability(pdev, pos, <ID>)) { /* ... */ } Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4e57b681 |
|
30-Oct-2005 |
Tim Schmielau <tim@physik3.uni-rostock.de> |
[PATCH] fix missing includes I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
8f7020d3 |
|
23-Oct-2005 |
Randy Dunlap <rdunlap@infradead.org> |
[PATCH] kernel-doc: PCI fixes PCI: add descriptions for missing function parameters. Eliminate all kernel-doc warnings here. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
d3535fbb |
|
28-Sep-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] pci: cleanup need_restore switch statement Cleanup the need_restore switch statement in pci_set_power_state(). This makes it more safe by explicitly handling all the PCI power states instead of handling them as the default case. It also reads a little better IMHO. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
32a36585 |
|
14-Sep-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] pci: only call pci_restore_bars at boot Certain (SGI?) ia64 boxes object to having their PCI BARs restored unless absolutely necessary. This patch restricts calling pci_restore_bars from pci_set_power_state unless the current state is PCI_UNKNOWN, the actual (i.e. physical) state of the device is PCI_D3hot, and the device indicates that it will lose its configuration when transitioning to PCI_D0. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
2fd9d74b |
|
09-Sep-2005 |
Brett M Russ <russb@emc.com> |
[PATCH] PCI: PCI/libata INTx bug fix Previous INTx cleanup patch had a bug that was not caught. I found this last night during testing and can confirm that it is now 100% working. Signed-off-by: Brett Russ <russb@emc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
a04ce0ff |
|
15-Aug-2005 |
Brett M Russ <russb@emc.com> |
[PATCH] PCI/libata INTx cleanup Simple cleanup to eliminate X copies of the pci_enable_intx() function in libata. Moved ahci.c's pci_intx() to pci.c and use it throughout libata and msi.c. Signed-off-by: Brett Russ <russb@emc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3fe9d19f |
|
17-Aug-2005 |
Daniel Ritz <daniel.ritz@gmx.ch> |
[PATCH] PCI: Support PCM PM CAP version 3 - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2) - pci/probe.c sets the PM state initially to 4 which is D3cold. add a PCI_UNKNOWN - minor cleanups Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
11f3859b |
|
10-Aug-2005 |
Alan Stern <stern@rowland.harvard.edu> |
[PATCH] PCI: Fix regression in pci_enable_device_bars This patch (as552) fixes yet another small problem recently added. If an attempt to put a PCI device back into D0 fails because the device doesn't support PCI PM, it shouldn't count as error. Without this patch the UHCI controllers on my Intel motherboard don't work. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
95a62965 |
|
28-Jul-2005 |
Greg Kroah-Hartman <gregkh@suse.de> |
[PATCH] PCI: start paying attention to a lot of pci function return values Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
064b53db |
|
27-Jul-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ca078bae |
|
03-Sep-2005 |
Pavel Machek <pavel@ucw.cz> |
[PATCH] swsusp: switch pm_message_t to struct This adds type-checking to pm_message_t, so that people can't confuse it with int or u32. It also allows us to fix "disk yoyo" during suspend (disk spinning down/up/down). [We've tried that before; since that cpufreq problems were fixed and I've tried make allyes config and fixed resulting damage.] Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
dc836b5b |
|
08-Aug-2005 |
Linus Torvalds <torvalds@g5.osdl.org> |
Revert "[PATCH] PCI: restore BAR values..." Revert commit fec59a711eef002d4ef9eb8de09dd0a26986eb77, which is breaking sparc64 that doesn't have a working pci_update_resource. We'll re-do this after 2.6.13 when we'll do it all properly.
|
#
fec59a71 |
|
04-Aug-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
f165b10f |
|
30-Mar-2005 |
Greg Kroah-Hartman <gregkh@suse.de> |
cleanup: remove unnecessary initializer on static pointers Suggested-by: Greg KH <greg@kroah.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
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>
|
#
5848f23d |
|
01-Jul-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] pci: cleanup argument comments for pci_{save,restore}_state The buffer arguments have been removed from pci_{save,restore}_state. The comment blocks for those functions should reflect that. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
9171078a |
|
01-May-2005 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] PCI: drivers/pci/pci.c: remove pci_dac_set_dma_mask pci_dac_set_dma_mask is currently completely unused. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
bc56b9e0 |
|
07-Apr-2005 |
Greg Kroah-Hartman <gregkh@suse.de> |
[PATCH] PCI: Clean up a lot of sparse "Should it be static?" warnings. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ceb43744 |
|
07-Apr-2005 |
Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com> |
[PATCH] PCI: 'is_enabled' flag should be set/cleared when the device is actually enabled/disabled I think 'is_enabled' flag in pci_dev structure should be set/cleared when the device actually enabled/disabled. Especially about pci_enable_device(), it can be failed. By this change, we will also get the possibility of refering 'is_enabled' flag from the functions called through pci_enable_device()/pci_disable_device(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.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!
|