kernel/linux.git/drivers/pci/hotplug/pciehp_ctrl.c, branch v4.14.263

Revert "PCI: pciehp: Add runtime PM support for PCIe hotplug ports"

2017-02-03T14:53:51+00:00

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 Signed-off-by: Bjorn Helgaas

Merge branch 'pci/pm' into next

2016-12-12T17:25:04+00:00

* pci/pm: x86/platform/intel-mid: Constify mid_pci_platform_pm PCI: pciehp: Add runtime PM support for PCIe hotplug ports ACPI / hotplug / PCI: Make device_is_managed_by_native_pciehp() public ACPI / hotplug / PCI: Use cached copy of PCI_EXP_SLTCAP_HPC bit PCI: Unfold conditions to block runtime PM on PCIe ports PCI: Consolidate conditions to allow runtime PM on PCIe ports PCI: Activate runtime PM on a PCIe port only if it can suspend PCI: Speed up algorithm in pci_bridge_d3_update() PCI: Autosense device removal in pci_bridge_d3_update() PCI: Don't acquire ref on parent in pci_bridge_d3_update() USB: UHCI: report non-PME wakeup signalling for Intel hardware PCI: Check for PME in targeted sleep state

PCI: pciehp: Leave power indicator on when enabling already-enabled slot

2016-12-08T18:02:25+00:00

If an error occurs when enabling a slot, pciehp_power_thread() turns off the power indicator. But if the only error is that the slot was already enabled, we should leave the power indicator on. Return success if called to enable an already-enabled slot. This is in the same spirit of the special handling for EEXISTS when pciehp_configure_device() determines the slot devices already exist. Signed-off-by: Ashok Raj Signed-off-by: Bjorn Helgaas Reviewed-by: Keith Busch

PCI: pciehp: Add runtime PM support for PCIe hotplug ports

2016-11-18T01:00:29+00:00

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 Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki CC: Mika Westerberg

PCI: pciehp: Remove useless pciehp_get_latch_status() calls

2016-09-14T19:25:05+00:00

Long ago, we updated a "switch_save" field based on the latch status. But switch_save was unused, and ed6cbcf2ac70 ("[PATCH] pciehp: miscellaneous cleanups") removed it. We no longer use the latch status, so remove calls to pciehp_get_latch_status(). No functional change intended. Tested-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg

PCI: pciehp: Clean up dmesg "Slot(%s)" messages

2016-09-14T19:25:00+00:00

Print slot name consistently as "Slot(%s)". I don't know whether that's ideal, but we can at least do it the same way all the time. No functional change intended. Tested-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg

PCI: pciehp: Don't re-read Slot Status when handling surprise event

2016-09-14T19:24:45+00:00

Previously we read Slot Status when handling a surprise event. But Slot Status might have changed since we identified the event, and the event_type already tells us whether to enable or disable the slot, so there's no need to read it again. Remove handle_surprise_event() and queue the power work directly. [bhelgaas: changelog] Tested-by: Lukas Wunner Signed-off-by: Mayurkumar Patel Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Acked-by: Rajat Jain

PCI: pciehp: Clear attention LED on device add

2016-08-22T16:57:41+00:00

Clear the LED attention status after a successful device add. It is possible the attention LED was on from a previous power fault or link failure, and a subsequent successful device insert insertion should clear it. Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas

PCI: pciehp: Always protect pciehp_disable_slot() with hotplug mutex

2015-11-25T17:45:42+00:00

When called from pciehp_sysfs_disable_slot(), the call to pciehp_disable_slot() was not protected by the hotplug mutex. Hold slot->hotplug_lock while calling pciehp_disable_slot(). Signed-off-by: Guenter Roeck Signed-off-by: Bjorn Helgaas Reviewed-by: Rajat Jain

PCI: pciehp: Queue power work requests in dedicated function

2015-10-21T18:55:37+00:00

Up to now, work items to be queued to be handled by pciehp_power_thread() are allocated using kmalloc() in three different locations. If not needed, kfree() is called to free the allocated data. Introduce a separate function to allocate the work item and queue it, and call it only if needed. This reduces code duplication and avoids having to free memory if the work item does not need to get executed. [bhelgaas: tweak "no memory" message, make pciehp_queue_power_work() static] Signed-off-by: Guenter Roeck Signed-off-by: Bjorn Helgaas