14 Nov, 2018
1 commit
-
commit aeae4f3e5c38d47bdaef50446dc0ec857307df68 upstream.
Upon removal of the last device on a bus, the link_state of the bridge
leading to that bus is sought to be torn down by having pci_stop_dev()
call pcie_aspm_exit_link_state().When ASPM was originally introduced by commit 7d715a6c1ae5 ("PCI: add
PCI Express ASPM support"), it determined whether the device being
removed is the last one by calling list_empty() on the bridge's
subordinate devices list. That didn't work because the device is only
removed from the list slightly later in pci_destroy_dev().Commit 3419c75e15f8 ("PCI: properly clean up ASPM link state on device
remove") attempted to fix it by calling list_is_last(), but that's not
correct either because it checks whether the device is at the *end* of
the list, not whether it's the last one *left* in the list. If the user
removes the device which happens to be at the end of the list via sysfs
but other devices are preceding the device in the list, the link_state
is torn down prematurely.The real fix is to move the invocation of pcie_aspm_exit_link_state() to
pci_destroy_dev() and reinstate the call to list_empty(). Remove a
duplicate check for dev->bus->self because pcie_aspm_exit_link_state()
already contains an identical check.Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Signed-off-by: Lukas Wunner
Signed-off-by: Bjorn Helgaas
Cc: Shaohua Li
Cc: stable@vger.kernel.org # v2.6.26
Signed-off-by: Greg Kroah-Hartman
09 Mar, 2018
1 commit
-
commit ee8bdfb6568d86bb93f55f8d99c4c643e77304ee upstream.
Even though it is unconventional, some PCIe host implementations omit the
root ports entirely, and simply consist of a host bridge (which is not
modeled as a device in the PCI hierarchy) and a link.When the downstream device is an endpoint, our current code does not seem
to mind this unusual configuration. However, when PCIe switches are
involved, the ASPM code assumes that any downstream switch port has a
parent, and blindly dereferences the bus->parent->self field of the pci_dev
struct to chain the downstream link state to the link state of the root
port. Given that the root port is missing, the link is not modeled at all,
and nor is the link state, and attempting to access it results in a NULL
pointer dereference and a crash.Avoid this by allowing the link state chain to terminate at the downstream
port if no root port exists.Signed-off-by: Ard Biesheuvel
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman
25 Dec, 2017
1 commit
-
[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]
Previously, if an non-fatal error was reported by an endpoint, we
called report_error_detected() for the endpoint, every sibling on the
bus, and their descendents. If any of them did not implement the
.error_detected() method, do_recovery() failed, leaving all these
devices unrecovered.For example, the system described in the bugzilla below has two devices:
0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected()
0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()When a device such as 74:02.0 reported a non-fatal error, do_recovery()
failed because 74:03.0 lacked an .error_detected() method. But per PCIe
r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and
does not affect 74:03.0:Non-fatal errors are uncorrectable errors which cause a particular
transaction to be unreliable but the Link is otherwise fully functional.
Isolating Non-fatal from Fatal errors provides Requester/Receiver logic
in a device or system management software the opportunity to recover from
the error without resetting the components on the Link and disturbing
other transactions in progress. Devices not associated with the
transaction in error are not impacted by the error.Report non-fatal errors only to the endpoint that reported them. We really
want to check for AER_NONFATAL here, but the current code structure doesn't
allow that. Looking for pci_channel_io_normal is the best we can do now.Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055
Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Gabriele Paoloni
Signed-off-by: Dongdong Liu
[bhelgaas: changelog]
Signed-off-by: Bjorn HelgaasSigned-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
20 Dec, 2017
1 commit
-
[ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ]
PCIe PME and native hotplug share the same interrupt number, so hotplug
interrupts are also processed by PME. In some cases, e.g., a Link Down
interrupt, a device may be present but unreachable, so when we try to
read its Root Status register, the read fails and we get all ones data
(0xffffffff).Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
"some device has asserted PME," so we scheduled pcie_pme_work_fn(). This
caused an infinite loop because pcie_pme_work_fn() tried to handle PME
requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
PCI_EXP_RTSTA_PME can't be cleared.Check for the invalid 0xffffffff data everywhere we read the Root Status
register.1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
non-existent devices") added similar checks in the hotplug driver.Signed-off-by: Qiang Zheng
[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
other similar checks]
Signed-off-by: Bjorn HelgaasSigned-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2017
2 commits
-
commit c00054f540bf81e592e1fee709b0bdbf20f478b5 upstream.
Previously we programmed the LTR_L1.2_THRESHOLD in the parent (upstream)
device using the capability pointer of the *child* (downstream) device,
which corrupted some random word of the parent's config space.Use the parent's L1 SS capability pointer to program its
LTR_L1.2_THRESHOLD.Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings")
Signed-off-by: Bjorn Helgaas
Reviewed-by: Vidya Sagar
CC: Rajat Jain
Signed-off-by: Greg Kroah-Hartman -
commit 94ac327e043ee40d7fc57b54541da50507ef4e99 upstream.
Every Port that supports the L1.2 substate advertises its Port
Common_Mode_Restore_Time, i.e., the time the Port requires to re-establish
common mode when exiting L1.2 (see PCIe r3.1, sec 7.33.2).Per sec 5.5.3.3.1, when exiting L1.2, the Downstream Port (the device at
the upstream end of the link) must send TS1 training sequences for at least
T(COMMONMODE) after it detects electrical idle exit on the Link. We want
this to be long enough for both ends of the Link, so we should set it to
the maximum of the Port Common_Mode_Restore_Time for the upstream and
downstream components on the Link.Previously we only looked at the Port Common_Mode_Restore_Time of the
upstream device, so if the downstream device required more time, we didn't
program the upstream device's T(COMMONMODE) correctly.Fixes: f1f0366dd6be ("PCI/ASPM: Calculate and save the L1.2 timing parameters")
Signed-off-by: Bjorn Helgaas
Reviewed-by: Vidya Sagar
Acked-by: Rajat Jain
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
14 Sep, 2017
1 commit
-
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]Signed-off-by: Christoph Hellwig
Signed-off-by: Jean Delvare
08 Sep, 2017
2 commits
-
* pci/trivial:
PCI: Fix typos and whitespace errors
PCI: Remove unused "res" variable from pci_resource_io()
PCI: Correct kernel-doc of pci_vpd_srdt_size(), pci_vpd_srdt_tag() -
* pci/dpc:
PCI/DPC: Add local struct device pointers
PCI/DPC: Add eDPC support
02 Sep, 2017
1 commit
-
Fix various typos and whitespace errors:
s/Synopsis/Synopsys/
s/Designware/DesignWare/
s/Keystine/Keystone/
s/gpio/GPIO/
s/pcie/PCIe/
s/phy/PHY/
s/confgiruation/configuration/No functional change intended.
Signed-off-by: Bjorn Helgaas
25 Aug, 2017
2 commits
-
Use a local "struct device *dev" for brevity and consistency in DPC driver.
No functional change intended.Signed-off-by: Dongdong Liu
Signed-off-by: Bjorn Helgaas
Reviewed-by: Keith Busch -
Add eDPC support. Get and print the RP PIO error information when the
trigger condition is RP PIO error.For more information on eDPC, please see PCI Express Base Specification
Revision 3.1, section 6.2.10.3, or view the PCI-SIG eDPC ECN here:
https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_DPC_2012-11-19_final.pdfSigned-off-by: Dongdong Liu
Signed-off-by: Bjorn Helgaas
Reviewed-by: Keith Busch
01 Aug, 2017
1 commit
-
Move the error handler methods to struct pcie_port_service_driver and avoid
the detour through the mostly unused pci_error_handlers structure.Signed-off-by: Christoph Hellwig
Signed-off-by: Bjorn Helgaas
14 Jul, 2017
1 commit
-
* pm-pci:
PCI / PM: Fix native PME handling during system suspend/resume
PCI / PM: Restore PME Enable after config space restoration
13 Jul, 2017
1 commit
-
Commit 76cde7e49590 (PCI / PM: Make PCIe PME interrupts wake up from
suspend-to-idle) went too far with preventing pcie_pme_work_fn() from
clearing the root port's PME Status and re-enabling the PME interrupt
which should be done for PMEs to work correctly after system resume.The failing scenario is as follows:
1. pcie_pme_suspend() finds that the PME IRQ should be designated
for system wakeup, so it calls enable_irq_wake() and then sets
data->suspend_level to PME_SUSPEND_WAKEUP.2. PME interrupt happens at this point.
3. pcie_pme_irq() runs, disables the PME interrupt and queues up
the execution of pcie_pme_work_fn().4. pcie_pme_work_fn() runs before pcie_pme_resume() and breaks out
of the loop right away, because data->suspend_level is not
PME_SUSPEND_NONE, and it doesn't re-enable the PME interrupt
for the same reason.5. pcie_pme_resume() runs and simply calls disable_irq_wake()
without re-enabling the PME interrupt (because data->suspend_level
is not PME_SUSPEND_NONE), so the PME interrupt remains disabled
and the PME Status remains set.To fix this notice that there is no reason why pcie_pme_work_fn()
should behave in a special way during system resume if the PME
interrupt is not disabled by pcie_pme_suspend() and partially revert
commit 76cde7e49590 and restore the previous (and correct) behavior
of pcie_pme_work_fn().Fixes: 76cde7e49590 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle)
Reported-and-tested-by: Naresh Solanki
Signed-off-by: Rafael J. Wysocki
Acked-by: Bjorn Helgaas
09 Jul, 2017
1 commit
-
Pull PCI updates from Bjorn Helgaas:
- add sysfs max_link_speed/width, current_link_speed/width (Wong Vee
Khee)- make host bridge IRQ mapping much more generic (Matthew Minter,
Lorenzo Pieralisi)- convert most drivers to pci_scan_root_bus_bridge() (Lorenzo
Pieralisi)- mutex sriov_configure() (Jakub Kicinski)
- mutex pci_error_handlers callbacks (Christoph Hellwig)
- split ->reset_notify() into ->reset_prepare()/reset_done()
(Christoph Hellwig)- support multiple PCIe portdrv interrupts for MSI as well as MSI-X
(Gabriele Paoloni)- allocate MSI/MSI-X vector for Downstream Port Containment (Gabriele
Paoloni)- fix MSI IRQ affinity pre/post/min_vecs issue (Michael Hernandez)
- test INTx masking during enumeration, not at run-time (Piotr Gregor)
- avoid using device_may_wakeup() for runtime PM (Rafael J. Wysocki)
- restore the status of PCI devices across hibernation (Chen Yu)
- keep parent resources that start at 0x0 (Ard Biesheuvel)
- enable ECRC only if device supports it (Bjorn Helgaas)
- restore PRI and PASID state after Function-Level Reset (CQ Tang)
- skip DPC event if device is not present (Keith Busch)
- check domain when matching SMBIOS info (Sujith Pandel)
- mark Intel XXV710 NIC INTx masking as broken (Alex Williamson)
- avoid AMD SB7xx EHCI USB wakeup defect (Kai-Heng Feng)
- work around long-standing Macbook Pro poweroff issue (Bjorn Helgaas)
- add Switchtec "running" status flag (Logan Gunthorpe)
- fix dra7xx incorrect RW1C IRQ register usage (Arvind Yadav)
- modify xilinx-nwl IRQ chip for legacy interrupts (Bharat Kumar
Gogada)- move VMD SRCU cleanup after bus, child device removal (Jon Derrick)
- add Faraday clock handling (Linus Walleij)
- configure Rockchip MPS and reorganize (Shawn Lin)
- limit Qualcomm TLP size to 2K (hardware issue) (Srinivas Kandagatla)
- support Tegra MSI 64-bit addressing (Thierry Reding)
- use Rockchip normal (not privileged) register bank (Shawn Lin)
- add HiSilicon Kirin SoC PCIe controller driver (Xiaowei Song)
- add Sigma Designs Tango SMP8759 PCIe controller driver (Marc
Gonzalez)- add MediaTek PCIe host controller support (Ryder Lee)
- add Qualcomm IPQ4019 support (John Crispin)
- add HyperV vPCI protocol v1.2 support (Jork Loeser)
- add i.MX6 regulator support (Quentin Schulz)
* tag 'pci-v4.13-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (113 commits)
PCI: tango: Add Sigma Designs Tango SMP8759 PCIe host bridge support
PCI: Add DT binding for Sigma Designs Tango PCIe controller
PCI: rockchip: Use normal register bank for config accessors
dt-bindings: PCI: Add documentation for MediaTek PCIe
PCI: Remove __pci_dev_reset() and pci_dev_reset()
PCI: Split ->reset_notify() method into ->reset_prepare() and ->reset_done()
PCI: xilinx: Make of_device_ids const
PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts
PCI: vmd: Move SRCU cleanup after bus, child device removal
PCI: vmd: Correct comment: VMD domains start at 0x10000, not 0x1000
PCI: versatile: Add local struct device pointers
PCI: tegra: Do not allocate MSI target memory
PCI: tegra: Support MSI 64-bit addressing
PCI: rockchip: Use local struct device pointer consistently
PCI: rockchip: Check for clk_prepare_enable() errors during resume
MAINTAINERS: Remove Wenrui Li as Rockchip PCIe driver maintainer
PCI: rockchip: Configure RC's MPS setting
PCI: rockchip: Reconfigure configuration space header type
PCI: rockchip: Split out rockchip_pcie_cfg_configuration_accesses()
PCI: rockchip: Move configuration accesses into rockchip_pcie_cfg_atu()
...
03 Jul, 2017
1 commit
-
* pci/portdrv:
PCI/portdrv: Allocate MSI/MSI-X vector for Downstream Port Containment
PCI/portdrv: Support multiple interrupts for MSI as well as MSI-X
28 Jun, 2017
2 commits
-
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
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas -
The pme_interrupt flag in struct pci_dev is set when PMEs generated
by the device are going to be signaled via root port PME interrupts.Ironically enough, that information is only used by the code setting
up device wakeup through ACPI which returns as soon as it sees the
pme_interrupt flag set while setting up "remote runtime wakeup".
That is questionable, however, because in theory there may be PCIe
devices using out-of-band PME signaling under root ports handled
by the native PME code or devices requiring wakeup power setup to be
carried out by AML. For such devices, ACPI wakeup should be invoked
regardless of whether or not native PME signaling is used in general.For this reason, drop the pme_interrupt flag and rework the code
using it which then allows the ACPI-based device wakeup handling
in PCI to be consolidated to use one code path for both "runtime
remote wakeup" and system wakeup (from sleep states).Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas
17 Jun, 2017
2 commits
-
Currently pcie_port_enable_irq_vec() only allocates MSI/MSI-X vectors for
PME, hotplug, and AER.The Downstream Port Containment feature also supports MSI/MSI-X interrupts,
so allocate a vector for it, too.Signed-off-by: Liudongdong
Signed-off-by: Gabriele Paoloni
[bhelgaas: changelog, comment]
Signed-off-by: Bjorn Helgaas
Reviewed-by: Christoph Hellwig -
Root Ports can generate several different interrupts using either MSI or
MSI-X, but we only support that for MSI-X. Ports that support MSI but not
MSI-X are currently limited to sharing a single interrupt.Rename pcie_port_enable_msix() to pcie_port_enable_irq_vec() and extend it
to support multiple interrupts using either MSI-X (preferred) or MSI.Signed-off-by: Gabriele Paoloni
[bhelgaas: changelog, reword comments, simplify PME/hotplug no-MSI logic]
Signed-off-by: Bjorn Helgaas
Reviewed-by: Christoph Hellwig
23 May, 2017
2 commits
-
This driver was OR'ing desired bits from the existing control setting.
That could create an invalid DPC Trigger Enabled configuration if the
platform previously set this to "ERR_FATAL", 01b. The driver currently
wants to set this to ERR_NONFATAL/ERR_FATAL, 10b, and the logical OR of
this gets 11b, which is reserved. Fix that by masking off the fields it is
setting.Signed-off-by: Keith Busch
Signed-off-by: Bjorn Helgaas -
The DPC interupt may be executed on a device that is being removed. Skip
queuing event handling if the status is all 1's, which should be seen only
if the device is not present.Signed-off-by: Keith Busch
Signed-off-by: Bjorn Helgaas
28 Apr, 2017
1 commit
-
* pci/enumeration:
PCI: Include PCI-to-PCIe bridges as "Downstream Ports"
PCI: Improve __pci_read_base() robustness
PCI: Short-circuit pci_device_is_present() for disconnected devices
PCI/MSI: Skip disabling disconnected devices
PCI: Don't attempt config access to disconnected devices
PCI: Add device disconnected state
PCI: Export PCI device config accessors
30 Mar, 2017
1 commit
-
Add a new state to pci_dev to be set when it is unexpectedly disconnected.
The PCI driver tear down functions can observe this new device state so
they may skip operations that will fail.The pciehp and pcie-dpc drivers are aware when the link is down, so these
set the flag when their handlers detect the device is disconnected.Tested-by: Krishna Dhulipala
Signed-off-by: Keith Busch
Signed-off-by: Bjorn Helgaas
Reviewed-by: Christoph Hellwig
Reviewed-by: Wei Zhang
08 Mar, 2017
1 commit
-
We call pcie_aspm_exit_link_state() when we remove a device. If the device
is the last PCIe function to be removed below a bridge and the bridge has
an ASPM link_state struct, we disable ASPM on the link. Disabling ASPM
requires link->downstream (used in pcie_config_aspm_link()).We previously set link->downstream in pcie_aspm_cap_init(), but only if the
device was not blacklisted. Removing the blacklisted device caused a NULL
pointer dereference in the pcie_aspm_exit_link_state() ->
pcie_config_aspm_link() path:# echo 1 > /sys/bus/pci/devices/0000\:0b\:00.0/remove
...
BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
IP: pcie_config_aspm_link+0x5d/0x2b0
Call Trace:
pcie_aspm_exit_link_state+0x75/0x130
pci_stop_bus_device+0xa4/0xb0
pci_stop_and_remove_bus_device_locked+0x1a/0x30
remove_store+0x50/0x70
dev_attr_store+0x18/0x30
sysfs_kf_write+0x44/0x60
kernfs_fop_write+0x10e/0x190
__vfs_write+0x28/0x110
? rcu_read_lock_sched_held+0x5d/0x80
? rcu_sync_lockdep_assert+0x2c/0x60
? __sb_start_write+0x173/0x1a0
? vfs_write+0xb3/0x180
vfs_write+0xc4/0x180
SyS_write+0x49/0xa0
do_syscall_64+0xa6/0x1c0
entry_SYSCALL64_slow_path+0x25/0x25
---[ end trace bd187ee0267df5d9 ]---To avoid this, set link->downstream in alloc_pcie_link_state(), so every
pcie_link_state structure has a valid link->downstream pointer.[bhelgaas: changelog]
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Acked-by: Rajat Jain
CC: stable@vger.kernel.org
24 Feb, 2017
1 commit
-
Pull PCI updates from Bjorn Helgaas:
- add ASPM L1 substate support
- enable PCIe Extended Tags when supported
- configure PCIe MPS settings on iProc, Versatile, X-Gene, and Xilinx
- increase VPD access timeout
- add ACS quirks for Intel Union Point, Qualcomm QDF2400 and QDF2432
- use new pci_irq_alloc_vectors() in more drivers
- fix MSI affinity memory leak
- remove unused MSI interfaces and update documentation
- remove unused AER .link_reset() callback
- avoid pci_lock / p->pi_lock deadlock seen with perf
- serialize sysfs enable/disable num_vfs operations
- move DesignWare IP from drivers/pci/host/ to drivers/pci/dwc/ and
refactor so we can support both hosts and endpoints- add DT ECAM-like support for HiSilicon Hip06/Hip07 controllers
- add Rockchip system power management support
- add Thunder-X cn81xx and cn83xx support
- add Exynos 5440 PCIe PHY support
* tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (93 commits)
PCI: dwc: Remove dependency of designware on CONFIG_PCI
PCI: dwc: Add CONFIG_PCIE_DW_HOST to enable PCI dwc host
PCI: dwc: Split pcie-designware.c into host and core files
PCI: dwc: designware: Fix style errors in pcie-designware.c
PCI: dwc: designware: Parse "num-lanes" property in dw_pcie_setup_rc()
PCI: dwc: all: Split struct pcie_port into host-only and core structures
PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init()
PCI: dwc: all: Rename cfg_read/cfg_write to read/write
PCI: dwc: all: Use platform_set_drvdata() to save private data
PCI: dwc: designware: Move register defines to designware header file
PCI: dwc: Use PTR_ERR_OR_ZERO to simplify code
PCI: dra7xx: Group PHY API invocations
PCI: dra7xx: Enable MSI and legacy interrupts simultaneously
PCI: dra7xx: Add support to force RC to work in GEN1 mode
PCI: dra7xx: Simplify probe code with devm_gpiod_get_optional()
PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory
PCI: exynos: Support the PHY generic framework
Documentation: binding: Modify the exynos5440 PCIe binding
phy: phy-exynos-pcie: Add support for Exynos PCIe PHY
Documentation: samsung-phy: Add exynos-pcie-phy binding
...
16 Feb, 2017
2 commits
-
* pci/msi:
PCI/MSI: Update MSI/MSI-X bits in PCIEBUS-HOWTO
PCI/MSI: Document pci_alloc_irq_vectors(), deprecate pci_enable_msi()
PCI/MSI: Return -ENOSPC if pci_enable_msi_range() can't get enough vectors
PCI/portdrv: Use pci_irq_alloc_vectors()
PCI/MSI: Check that we have a legacy interrupt line before using it
PCI/MSI: Remove pci_msi_domain_{alloc,free}_irqs()
PCI/MSI: Remove unused pci_msi_create_default_irq_domain()
PCI/MSI: Return failure when msix_setup_entries() fails
PCI/MSI: Remove pci_enable_msi_{exact,range}()
amd-xgbe: Update PCI support to use new IRQ functions
[media] cobalt: use pci_irq_allocate_vectors()
PCI/MSI: Fix msi_capability_init() kernel-doc warnings -
* pci/dpc:
PCI/DPC: Wait for Root Port busy to clear
PCI/DPC: Decode extended reasons
15 Feb, 2017
6 commits
-
In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make
explicitly non-modular") removed the pcie_pme_driver .remove() method,
pcie_pme_remove().pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe().
The fact that we don't free the IRQ after d7def2040077 causes the following
crash when removing a PCIe port device via /sys:------------[ cut here ]------------
kernel BUG at drivers/pci/msi.c:370!
invalid opcode: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 14509 Comm: sh Tainted: G W 4.8.0-rc1-yh-00012-gd29438d
RIP: 0010:[] free_msi_irqs+0x65/0x190
...
Call Trace:
[] pci_disable_msi+0x34/0x40
[] cleanup_service_irqs+0x27/0x30
[] pcie_port_device_remove+0x2a/0x40
[] pcie_portdrv_remove+0x40/0x50
[] pci_device_remove+0x4b/0xc0
[] __device_release_driver+0xb6/0x150
[] device_release_driver+0x25/0x40
[] pci_stop_bus_device+0x74/0xa0
[] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[] remove_store+0x50/0x70
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x44/0x60
[] kernfs_fop_write+0x10e/0x190
[] __vfs_write+0x28/0x110
[] ? percpu_down_read+0x44/0x80
[] ? __sb_start_write+0xa7/0xe0
[] ? __sb_start_write+0xa7/0xe0
[] vfs_write+0xc4/0x180
[] SyS_write+0x49/0xa0
[] do_syscall_64+0xa6/0x1b0
[] entry_SYSCALL64_slow_path+0x25/0x25
...
RIP [] free_msi_irqs+0x65/0x190
RSP
---[ end trace f4505e1dac5b95d3 ]---
Segmentation faultRestore pcie_pme_remove().
[bhelgaas: changelog]
Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
CC: stable@vger.kernel.org # v4.9+ -
Since the exit latencies for L1 substates are not advertised by a device,
it is not clear in spec how to do a L1 substate exit latency check. We
assume that the L1 exit latencies advertised by a device include L1
substate latencies (and hence do not do any check). If that is not true,
we should do some sort of check here.(I'm not clear about what that check should like currently. I'd be glad to
take up any suggestions).Signed-off-by: Rajat Jain
Signed-off-by: Bjorn Helgaas -
Configure the L1 substate settings on the upstream and downstream devices,
while taking care of the rules dictated by the PCIe spec.[bhelgaas: drop "inline"]
Signed-off-by: Rajat Jain
Signed-off-by: Bjorn Helgaas -
Calculate and save the timing parameters that need to be programmed if we
need to enable L1.2 substates later.We use the same logic (and a constant value for 1 of the parameters) as
used by Intel's coreboot:https://www.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134.html
https://review.coreboot.org/#/c/8832/Signed-off-by: Rajat Jain
Signed-off-by: Bjorn Helgaas -
The PCIe spec (r3.1, sec 7.33) says the L1 PM Substates Capability may be
implemented only in function 0.Read the L1 substate capability structures of upstream and downstream
components of the link and set it up in the device structure.[bhelgaas: add specific spec reference]
Signed-off-by: Rajat Jain
Signed-off-by: Bjorn Helgaas -
Add support for ASPM L1 substates. For details about L1 substates, see the
PCIe r3.1 spec, which includes the ECN below in secs 5.5 and 7.33.Add macros for the 4 new L1 substates, and add a new ASPM "POWER_SUPERSAVE"
policy that can be used to enable L1 substates on a system if desired. The
new policy is in a sense, a superset of the existing POWERSAVE policy. The
4 policies are now:DEFAULT: Reads and uses whatever ASPM states BIOS enabled
PERFORMANCE: Everything except L0 disabled.
POWERSAVE: L0s and L1 enabled (but not L1 substates)
POWER_SUPERSAVE: L0s + L1 + L1 substates also enabled[bhelgaas: add PCIe r3.1 spec reference]
Link: https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf
Signed-off-by: Rajat Jain
Signed-off-by: Bjorn Helgaas
11 Feb, 2017
3 commits
-
Use pci_irq_alloc_vectors() and greatly simplify the code by managing the
vector number for the subservices directly.Signed-off-by: Christoph Hellwig
Signed-off-by: Bjorn Helgaas -
Per PCIe r3.1, sec 6.2.10 and sec 7.13.4, on Root Ports that support "RP
Extensions for DPC",When the DPC Trigger Status bit is Set and the DPC RP Busy bit is Set,
software must leave the Root Port in DPC until the DPC RP Busy bit reads
0b.Wait up to 1 second for the Root Port to become non-busy.
[bhelgaas: changelog, spec references]
Signed-off-by: Keith Busch
Signed-off-by: Bjorn Helgaas -
Decode the currently defined extended event reasons rather than just using
the generic "extended" explanation.Signed-off-by: Keith Busch
Signed-off-by: Bjorn Helgaas
28 Jan, 2017
1 commit
-
In a struct pcie_link_state, link->root points to the pcie_link_state of
the root of the PCIe hierarchy. For the topmost link, this points to
itself (link->root = link). For others, we copy the pointer from the
parent (link->root = link->parent->root).Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link->parent->root,
there was no parent, and we dereferenced a NULL pointer:BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
IP: [] pcie_aspm_init_link_state+0x170/0x820Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link->root for these devices should also point to
itself.Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: lists@ssl-mail.com
Tested-by: Jayachandran C.
Signed-off-by: Bjorn Helgaas
CC: stable@vger.kernel.org # v4.2+