kernel/linux.git/drivers/pci/hotplug/pciehp_hpc.c, branch linux-4.16.y

Merge branch 'pci/spdx' into next

2018-02-01T17:40:07+00:00

* pci/spdx: PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate PCI: Add SPDX GPL-2.0 to replace COPYING boilerplate PCI: Add SPDX GPL-2.0 to replace GPL v2 boilerplate PCI: Add SPDX GPL-2.0 when no license was specified

Merge branch 'pci/misc' into next

2018-01-31T16:10:32+00:00

* pci/misc: PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build PCI: Add wrappers for dev_printk() PCI: Remove unnecessary messages for memory allocation failures PCI: Add #defines for Completion Timeout Disable feature hinic: Replace PCI pool old API net: e100: Replace PCI pool old API block: DAC960: Replace PCI pool old API MAINTAINERS: Include more PCI files PCI: Remove unneeded kallsyms include powerpc/pci: Unroll two pass loop when scanning bridges powerpc/pci: Use for_each_pci_bridge() helper

PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate

2018-01-28T21:49:06+00:00

Add SPDX GPL-2.0+ to all PCI files that specified the GPL and allowed either GPL version 2 or any later version. Remove the boilerplate GPL version 2 or later language, relying on the assertion in b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") that the SPDX identifier may be used instead of the full boilerplate text. Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Kroah-Hartman

PCI: pciehp: Assume NoCompl+ for Thunderbolt ports

2018-01-23T20:28:41+00:00

Certain Thunderbolt 1 controllers claim to support Command Completed events (value of 0b in the No Command Completed Support field of the Slot Capabilities register) but in reality they neither set the Command Completed bit in the Slot Status register nor signal a Command Completed interrupt: 8086:1513 CV82524 [Light Ridge 4C 2010] 8086:151a DSL2310 [Eagle Ridge 2C 2011] 8086:151b CVL2510 [Light Peak 2C 2010] 8086:1547 DSL3510 [Cactus Ridge 4C 2012] 8086:1548 DSL3310 [Cactus Ridge 2C 2012] 8086:1549 DSL2210 [Port Ridge 1C 2011] All known newer chips (Redwood Ridge and onwards) set No Command Completed Support, indicating that they do not support Command Completed events. The user-visible impact is that after unplugging such a device, 2 seconds elapse until pciehp is unbound. That's because on ->remove, pcie_write_cmd() is called via pcie_disable_notification() and every call to pcie_write_cmd() takes 2 seconds (1 second for each invocation of pcie_wait_cmd()): [ 337.942727] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x1038 (issued 21176 msec ago) [ 340.014735] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x0000 (issued 2072 msec ago) That by itself has always been unpleasant, but the situation has become worse with commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown"): Now pciehp is unbound on ->shutdown. Because Thunderbolt controllers typically have 4 hotplug ports, every reboot and shutdown is now delayed by 8 seconds, plus another 2 seconds for every attached Thunderbolt 1 device. Thunderbolt hotplug slots are not physical slots that one inserts cards into, but rather logical hotplug slots implemented in silicon. Devices appear beyond those logical slots once a PCI tunnel is established on top of the Thunderbolt Converged I/O switch. One would expect commands written to the Slot Control register to be executed immediately by the silicon, so for simplicity we always assume NoCompl+ for Thunderbolt ports. Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown") Tested-by: Mika Westerberg Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Cc: stable@vger.kernel.org # v4.12+ Cc: Sinan Kaya Cc: Yehezkel Bernat Cc: Michael Jamet Cc: Andreas Noever

PCI: Remove unnecessary messages for memory allocation failures

2018-01-17T14:41:41+00:00

Per ebfdc40969f2 ("checkpatch: attempt to find unnecessary 'out of memory' messages"), when a memory allocation fails, the memory subsystem emits generic "out of memory" messages (see slab_out_of_memory() for some of this logging). Therefore, additional error messages in the caller don't add much value. Remove messages that merely report "out of memory". This preserves some messages that report additional information, e.g., allocation failures that mean we drop hotplug events. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring [bhelgaas: changelog, squash patches, make similar changes to acpiphp, cpqphp, ibmphp, keep warning when dropping hotplug event] Signed-off-by: Bjorn Helgaas

PCI: pciehp: Do not clear Presence Detect Changed during initialization

2017-11-07T00:49:00+00:00

It is possible that the hotplug event has already happened before the driver is attached to a PCIe hotplug downstream port. If we just clear the status we never get the hotplug interrupt and thus the event will be missed. To make sure that does not happen, we leave Presence Detect Changed bit untouched during initialization. Then once the event is unmasked we get an interrupt and handle the hotplug event properly. Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas

PCI: pciehp: Fix race condition handling surprise link down

2017-11-07T00:49:00+00:00

A surprise link down may retrain very quickly causing the same slot generate a link up event before handling the link down event completes. Since the link is active, the power off work queued from the first link down will cause a second down event when power is disabled. However, the link up event sets the slot state to POWERON_STATE before the event to handle this is enqueued, making the second down event believe it needs to do something. This creates constant link up and down event cycle. To prevent this it is better to handle each event at the time in order it occurred, so change the driver to use ordered workqueue instead. A normal device hotplug triggers two events (presense detect and link up) that are already handled properly in the driver but we currently log an error if we find an existing device in the slot. Since this is not an error change the log level to be debug instead to avoid scaring users. This is based on the original work by Ashok Raj. Link: https://patchwork.kernel.org/patch/9469023 Suggested-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas

PCI: pciehp: Convert timers to use timer_setup()

2017-11-07T00:48:57+00:00

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. This fixes what appears to be a bug in passing the wrong pointer to the timer handler (address of ctrl pointer instead of ctrl pointer). Signed-off-by: Kees Cook Signed-off-by: Bjorn Helgaas Cc: Mika Westerberg Cc: Mayurkumar Patel Cc: Keith Busch Cc: Thomas Gleixner

PCI: pciehp: Report power fault only once until we clear it

2017-08-15T18:46:31+00:00

When a power fault occurs, the power controller sets Power Fault Detected in the Slot Status register, and pciehp_isr() queues an INT_POWER_FAULT event to handle it. It also clears Power Fault Detected, but since nothing has yet changed to correct the power fault, the power controller will likely set it again immediately, which may cause an infinite loop when pcie_isr() rechecks Slot Status. Fix that by masking off Power Fault Detected from new events if the driver hasn't seen the power fault clear from the previous handling attempt. Fixes: fad214b0aa72 ("PCI: pciehp: Process all hotplug events before looking for new ones") Signed-off-by: Keith Busch [bhelgaas: changelog, pull test out and add comment] Signed-off-by: Bjorn Helgaas Cc: Mayurkumar Patel Cc: stable@vger.kernel.org # 4.9+

PCI: pciehp: Prioritize data-link event over presence detect

2016-12-07T23:00:44+00:00

If Slot Status indicates changes in both Data Link Layer Status and Presence Detect, prioritize the Link status change. When both events are observed, pciehp currently relies on the Slot Status Presence Detect State (PDS) to agree with the Link Status Data Link Layer Active status. The Presence Detect State, however, may be set to 1 through out-of-band presence detect even if the link is down, which creates conflicting events. Since the Link Status accurately reflects the reachability of the downstream bus, the Link Status event should take precedence over a Presence Detect event. Skip checking the PDC status if we handled a link event in the same handler. Signed-off-by: Ashok Raj Signed-off-by: Bjorn Helgaas Reviewed-by: Keith Busch