- 06 Jun, 2018 6 commits
-
-
Bjorn Helgaas authored
- add macros for PCIe Link Control 2 register (Frederick Lawler) - replace IB/hfi1 custom macros with PCI core versions (Frederick Lawler) - remove dead microblaze and xtensa code (Bjorn Helgaas) - use dev_printk() when possible in xtensa and mips (Bjorn Helgaas) * pci/misc: MIPS: PCI: Use dev_printk() when possible xtensa/PCI: Use dev_printk() when possible xtensa/PCI: Make variables static xtensa/PCI: Remove dead code microblaze/PCI: Remove pcibios_claim_one_bus() dead code microblaze/PCI: Remove pcibios_finish_adding_to_bus() dead code IB/hfi1: Replace custom hfi1 macros with PCIe macros PCI: Add PCI_EXP_LNKCTL2_TLS* macros
-
Bjorn Helgaas authored
- fix use-before-set error in ibmphp (Dan Carpenter) - fix pciehp timeouts caused by Command Completed errata (Bjorn Helgaas) - fix refcounting in pnv_php hotplug (Julia Lawall) - clear pciehp Presence Detect and Data Link Layer Status Changed on resume so we don't miss hotplug events (Mika Westerberg) - only request pciehp control if we support it, so platform can use ACPI hotplug otherwise (Mika Westerberg) - convert SHPC to be builtin only (Mika Westerberg) - request SHPC control via _OSC if we support it (Mika Westerberg) - simplify SHPC handoff from firmware (Mika Westerberg) * pci/hotplug: PCI: Improve "partially hidden behind bridge" log message PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() doc PCI: Move resource distribution for single bridge outside loop PCI: Account for all bridges on bus when distributing bus numbers ACPI / hotplug / PCI: Drop unnecessary parentheses ACPI / hotplug / PCI: Mark stale PCI devices disconnected ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug PCI: hotplug: Add hotplug_is_native() PCI: shpchp: Add shpchp_is_native() PCI: shpchp: Fix AMD POGO identification PCI: shpchp: Use dev_printk() for OSHP-related messages PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapper PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flags PCI: shpchp: Rely on previous _OSC results PCI: shpchp: Request SHPC control via _OSC when adding host bridge PCI: shpchp: Convert SHPC to be builtin only PCI: pciehp: Make pciehp_is_native() stricter PCI: pciehp: Rename host->native_hotplug to host->native_pcie_hotplug PCI: pciehp: Request control of native hotplug only if supported PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume PCI: pnv_php: Add missing of_node_put() PCI: pciehp: Add quirk for Command Completed errata PCI: Add Qualcomm vendor ID PCI: ibmphp: Fix use-before-set in get_max_bus_speed() # Conflicts: # drivers/acpi/pci_root.c -
Bjorn Helgaas authored
- neaten pci=earlydump output (Andy Shevchenko) - avoid errors when extended config space inaccessible (Gilles Buloz) - prevent sysfs disable of device while driver attached (Christoph Hellwig) - use core interface to report PCIe link properties in bnx2x, bnxt_en, cxgb4, ixgbe (Bjorn Helgaas) - remove unused pcie_get_minimum_link() (Bjorn Helgaas) * pci/enumeration: PCI: Remove unused pcie_get_minimum_link() ixgbe: Report PCIe link properties with pcie_print_link_status() cxgb4: Report PCIe link properties with pcie_print_link_status() bnxt_en: Report PCIe link properties with pcie_print_link_status() bnx2x: Report PCIe link properties with pcie_print_link_status() PCI: Prevent sysfs disable of device while driver is attached PCI: Check whether bridges allow access to extended config space x86/PCI: Make pci=earlydump output neat -
Bjorn Helgaas authored
- clear interrupt status in top half to avoid interrupt storm (Oza Pawandeep) * pci/dpc: PCI/DPC: Clear interrupt status in interrupt handler top half -
Bjorn Helgaas authored
- disable ASPM L1.2 substate if we don't have LTR (Bjorn Helgaas) - respect platform ownership of LTR (Bjorn Helgaas) * pci/aspm: PCI/ACPI: Request LTR control from platform before using it PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR
-
Bjorn Helgaas authored
- unify AER decoding for native and ACPI CPER sources (Alexandru Gagniuc) - add TLP header info to AER tracepoint (Thomas Tai) - add generic pcie_wait_for_link() interface (Oza Pawandeep) - handle AER ERR_FATAL by removing and re-enumerating devices, as Downstream Port Containment does (Oza Pawandeep) - factor out common code between AER and DPC recovery (Oza Pawandeep) - stop triggering DPC for ERR_NONFATAL errors (Oza Pawandeep) - share ERR_FATAL recovery path between AER and DPC (Oza Pawandeep) * pci/aer: PCI/AER: Replace struct pcie_device with pci_dev PCI/AER: Remove unused parameters PCI/AER: Decode Error Source Requester ID PCI/AER: Remove aer_recover_work_func() forward declaration PCI/DPC: Use the generic pcie_do_fatal_recovery() path PCI/AER: Pass service type to pcie_do_fatal_recovery() PCI/DPC: Disable ERR_NONFATAL handling by DPC PCI/portdrv: Add generic pcie_port_find_device() PCI/portdrv: Add generic pcie_port_find_service() PCI/AER: Factor out error reporting to drivers/pci/pcie/err.c PCI/AER: Rename error recovery interfaces to generic PCI naming PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices PCI: Add generic pcie_wait_for_link() interface PCI/AER: Add TLP header information to tracepoint PCI/AER: Unify error bit printing for native and CPER reporting
-
- 05 Jun, 2018 2 commits
-
-
Keith Busch authored
The AER driver only needed the pcie_device to get to the port pci_dev. Save the pci_dev pointer directly in struct aer_rpc and remove the unnecessary indirection. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Keith Busch authored
Remove unused "struct pcie_device *" parameters to handle_error_source() and aer_process_err_devices(). No functional change intended. Signed-off-by:
-
- 04 Jun, 2018 10 commits
-
-
Mika Westerberg authored
pci_scan_child_bus_extend() complains when we assign an unreachable secondary bus number to a bridge. For example, given the topology below: +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0 +-01.0-[04-39]-- \-02.0-[3a]----00.0 it logs the following messages: pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39] pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39] These messages are incorrect (0000:02 is a bus, not a bridge) and confusing. Make the message more understandable: pci 0000:02:02.0: devices behind bridge are unusable because [bus 3a] cannot be assigned for them Also, remove the reference to CardBus, because this issue affects all varieties of PCI, not just CardBus. Suggested-by:Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: changelog] Signed-off-by:
-
Mika Westerberg authored
It is not immediately clear what the two functions actually return so add kernel-doc comment explaining it a bit better. Suggested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Mika Westerberg authored
If there is only a single bridge on the bus, we assign all resources to it. Currently this is done as a part of the resource distribution loop but it does not have to be there, and moving it outside actually improves readability because we can then save one indent level in the loop. While there we can add hotplug_bridges == 1 && normal_bridges == 0 to the same block because they are dealt the same way. Suggested-by:
-
Mika Westerberg authored
When distributing extra bus number space to hotplug bridges for future extension, we don't account for the fact that there might be non-hotplug bridges on the bus after the hotplug bridges. For example: 01:00.0 --+- 02:00.0 (HotPlug-) -- Thunderbolt host controller +- 02:01.0 (HotPlug+) \- 02:02.0 (HotPlug-) -- xHCI host controller pci_scan_child_bus_extend() is supposed to distribute the remaining bus numbers to the hotplug bridge at 02:01.0, but only after accounting for all bridges on bus 02. Since we don't check whether there's another non-hotplug bridge after the hotplug bridge 02:01.0, it may not leave space for the non-hotplug bridge: pci 0000:00:1b.0: PCI bridge to [bus 01-39] (Root Port) pci 0000:01:00.0: PCI bridge to [bus 02-39] ... pci 0000:02:00.0: PCI bridge to [bus 03] pci 0000:02:01.0: PCI bridge to [bus 04] pci_bus 0000:04: [bus 04-39] extended by 0x35 pci_bus 0000:04: bus scan returning with max=39 pci_bus 0000:04: busn_res: [bus 04-39] end is updated to 39 pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:3a: scanning bus pci_bus 0000:3a: bus scan returning with max=3a pci_bus 0000:3a: busn_res: [bus 3a] end is updated to 3a pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39] pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39] pci_bus 0000:02: bus scan returning with max=3a pci_bus 0000:02: busn_res: [bus 02-39] end can not be updated to 3a The resulting 'lspci -t' output looks like this: +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0 ^^ +-01.0-[04-39]-- \-02.0-[3a]----00.0 ^^ The xHCI host controller behind 02:02.0 is not usable because it would have to be assigned bus 3a, which is not accessible through 00:1b.0. To fix this, reserve at least one bus for each bridge while scanning already configured bridges. Then use this information in the second scan to correct the available extra bus space for hotplug bridges. After this change the 'lspci -t' output is what is expected: +-1b.0-[01-39]----00.0-[02-39]--+-00.0-[03]----00.0 +-01.0-[04-38]-- \-02.0-[39]----00.0 The xHCI controller is now on bus 39, where it is usable. Fixes: 1c02ea81 ("PCI: Distribute available buses to hotplug-capable bridges") Reported-by:Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
-
Mika Westerberg authored
Remove unnecessary parentheses. Signed-off-by:
-
Mika Westerberg authored
Following PCIehp mark the unplugged PCI devices disconnected. This makes sure PCI core code leaves the now missing hardware registers alone. Signed-off-by:
-
Mika Westerberg authored
When acpiphp re-enumerates a PCI hierarchy because of an ACPI Notify() event, we should skip bridges managed by native hotplug (pciehp or shpchp). We don't want to scan below a native hotplug bridge until the hotplug controller generates a hot-add event. A typical scenario is a Root Port leading to a Thunderbolt host router that remains powered off until something is connected to it. See [1] for the lspci details. 1. Before something is connected, only the Root Port exists. It has PCI_EXP_SLTCAP_HPC set and pciehp is responsible for hotplug: 00:1b.0 Root Port (HotPlug+) 2. When a USB-C or Thunderbolt device is connected, the Switch in the Thunderbolt host router is powered up, the Root Port signals a hotplug add event and pciehp enumerates the Switch: 01:00.0 Switch Upstream Port to [bus 02-39] 02:00.0 Switch Downstream Port to [bus 03] (HotPlug-, to NHI) 02:01.0 Switch Downstream Port to [bus 04-38] (HotPlug+, to Thunderbolt connector) 02:02.0 Switch Downstream Port to [bus 39] (HotPlug-, to xHCI) The 02:00.0 and 02:02.0 Ports lead to Endpoints that are not powered up yet. The Ports have PCI_EXP_SLTCAP_HPC cleared, so pciehp doesn't handle hotplug for them and we assign minimal resources to them. The 02:01.0 Port has PCI_EXP_SLTCAP_HPC set, so pciehp handles native hotplug events for it. 3. The BIOS powers up the xHCI controller. If a Thunderbolt device was connected (not just a USB-C device), it also powers up the NHI. Then it sends an ACPI Notify() to the Root Port, and acpiphp enumerates the new device(s): 03:00.0 Thunderbolt Host Controller (NHI) Endpoint 39:00.0 xHCI Endpoint 4. If a Thunderbolt device was connected, the host router firmware uses the NHI to set up Thunderbolt tunnels and triggers a native hotplug event (via 02:01.0 in this example). Then pciehp enumerates the new Thunderbolt devices: 04:00.0 Switch Upstream Port to [bus 05-38] 05:01.0 Switch Downstream Port to [bus 06-09] (HotPlug-) 05:04.0 Switch Downstream Port to [bus 0a-38] (HotPlug+) In this example, 05:01.0 leads to another Switch and some NICs. This subtree is static, so 05:01.0 doesn't support hotplug and has PCI_EXP_SLTCAP_HPC cleared. In step 3, acpiphp previously enumerated everything below the Root Port, including things below the 02:01.0 Port. We don't want that because pciehp expects to manage hotplug below that Port, and firmware on the host router may be in the middle of configuring its Link so it may not be ready yet. To make this work better with the native PCIe (pciehp) and standard PCI (shpchp) hotplug drivers, we let them handle all slot management and resource allocation for hotplug bridges and restrict ACPI hotplug to non-hotplug bridges. [1] https://bugzilla.kernel.org/show_bug.cgi?id=199581#c5 Link: https://lkml.kernel.org/r/20180529160155.1738-1-mika.westerberg@linux.intel.comSigned-off-by: -
Mika Westerberg authored
Add hotplug_is_native() to find out whether the OS is supposed to handle native hotplug of a given bridge. Signed-off-by:
-
Mika Westerberg authored
In the same way we do for pciehp, add shpchp_is_native(), which returns true if the bridge should be handled by the native SHPC driver. Then convert the driver to use this function. Signed-off-by:
-
Bjorn Helgaas authored
The fix for an AMD POGO erratum related to SHPC incorrectly identified the device. The workaround should be applied only for AMD POGO devices, but it was instead applied to: - all AMD bridges, and - all devices from any vendor with device ID 0x7458 Fixes: 53044f35 ("[PATCH] PCI Hotplug: shpchp: AMD POGO errata fix") Signed-off-by:
-
- 03 Jun, 2018 6 commits
-
-
Bjorn Helgaas authored
Decode the Requester ID from the AER Error Source Register into domain/ bus/device/function format to match other logging. In cases where the ID matches the device used for pci_err(), drop the extra ID completely so we don't print it twice. Signed-off-by: -
Borislav Petkov authored
Just move the actual function up so that it is visible to its user aer_recover_queue(). No functional changes. Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Oza Pawandeep authored
Our goal is to handle ERR_FATAL errors similarly, whether they are reported via AER or via DPC. A previous commit changed AER so it handles ERR_FATAL by calling driver .remove() methods and resetting the Link. DPC already does that (although the Link reset is done automatically by hardware and happens before we call the driver .remove() methods). Restructure the DPC code so it calls the same pcie_do_fatal_recovery() interface used by AER. This makes it clearer that we want to use the same path. Implement the .reset_link() method used by pcie_do_fatal_recovery(). For DPC, the actual reset is done automatically by hardware, so we really only have to wait for the Link to be inactive, then release the Port from DPC. Signed-off-by:
Oza Pawandeep <poza@codeaurora.org> [bhelgaas: changelog, DPC_FATAL is not a bitfield, can be sequential] Signed-off-by:
-
Oza Pawandeep authored
Pass the service type to pcie_do_fatal_recovery() instead of assuming AER. We will make DPC also use pcie_do_fatal_recovery(), and it needs to do things a little differently for AER and DPC. Signed-off-by:
-
Oza Pawandeep authored
PCIe ERR_NONFATAL errors mean a particular transaction is unreliable but the Link is otherwise fully functional (PCIe r4.0, sec 6.2.2). The AER driver handles these by logging the error details and calling driver-supplied pci_error_handlers callbacks. It does not reset downstream devices, does not remove them from the PCI subsystem, does not re-enumerate them, and does not call their driver .remove() or .probe() methods. But DPC driver previously enabled DPC on ERR_NONFATAL, so if the hardware supports DPC, these errors caused a Link reset (performed automatically by the hardware), followed by the DPC driver removing affected devices (which calls their .remove() methods), bringing the Link back up, and re-enumerating (which calls driver .probe() methods). Disable ERR_NONFATAL DPC triggering so these errors will only be handled by AER. This means drivers won't have to deal with different usage of their pci_error_handlers callbacks and .probe() and .remove() methods based on whether the platform has DPC support. Signed-off-by:
-
Oza Pawandeep authored
Add generic pcie_port_find_device() routine. Signed-off-by:
-
- 02 Jun, 2018 8 commits
-
-
Bjorn Helgaas authored
Use dev_printk() for messages related to requesting control of SHPC hotplug via the OSHP method. Signed-off-by:
-
Mika Westerberg authored
get_hp_hw_control_from_firmware() is a trivial wrapper around acpi_get_hp_hw_control_from_firmware(), probably intended to be generic in case other firmware needed similar OS/platform negotiation. Remove get_hp_hw_control_from_firmware() and call acpi_get_hp_hw_control_from_firmware() directly. Add a stub for acpi_get_hp_hw_control_from_firmware() for the non-ACPI case. Signed-off-by:
-
Mika Westerberg authored
acpi_get_hp_hw_control_from_firmware() no longer uses the flags parameter, so remove it. Signed-off-by:
-
Mika Westerberg authored
If _OSC exists, we evaluated it when adding the ACPI host bridge, and we requested SHPC control if the SHPC driver is present. Use the result of that _OSC evaluation instead of evaluating it again. Signed-off-by:
-
Mika Westerberg authored
The SHPC driver now must be builtin (it cannot be a module). If it is present, request SHPC control immediately when adding the ACPI host bridge. This is similar to how we handle native PCIe hotplug via pciehp. Suggested-by:
-
Mika Westerberg authored
We need to be able coordinate between SHPC and acpiphp to determine which driver handles hotplug of a given bridge. Because acpiphp is already bool, convert SHPC to be bool as well. Suggested-by:
-
Mika Westerberg authored
Previously pciehp_is_native() returned true for any PCI device in a hierarchy where _OSC says we can use pciehp. This is incorrect because bridges without PCI_EXP_SLTCAP_HPC capability should be managed by acpiphp instead. Improve pciehp_is_native() to return true only when PCI_EXP_SLTCAP_HPC is set and the pciehp driver is present. In any other case return false to let acpiphp handle those. Suggested-by:
-
Mika Westerberg authored
Rename host->native_hotplug to host->native_pcie_hotplug to make room for a similar flag for SHPC hotplug. Suggested-by:
-
- 25 May, 2018 6 commits
-
-
Bjorn Helgaas authored
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 authored
Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (which may be different links) without considering the total bandwidth of each link. For a path with a 16 GT/s x1 link and a 2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of bandwidth, not the true available bandwidth of about 1969 MB/s for a 16 GT/s x1 link. Use pcie_print_link_status() to report PCIe link speed and possible limitations instead of implementing this in the driver itself. This finds the slowest link in the path to the device by computing the total bandwidth of each link and compares that with the capabilities of the device. The dmesg change is: - PCI Express bandwidth of %dGT/s available - (Speed:%s, Width: x%d, Encoding Loss:%s) + %u.%03u Gb/s available PCIe bandwidth (%s x%d link) or, if the device is capable of better performance than is available in the current slot: - This is not sufficient for optimal performance of this card. - For optimal performance, at least %dGT/s of bandwidth is required. - A slot with more lanes and/or higher speed is suggested. + %u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link) Note that the driver previously used dev_warn() to suggest using a different slot, but pcie_print_link_status() uses dev_info() because if the platform has no faster slot available, the user can't do anything about the warning and may not want to be bothered with it. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Bjorn Helgaas authored
Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (which may be different links) without considering the total bandwidth of each link. For a path with a 16 GT/s x1 link and a 2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of bandwidth, not the true available bandwidth of about 1969 MB/s for a 16 GT/s x1 link. Use pcie_print_link_status() to report PCIe link speed and possible limitations instead of implementing this in the driver itself. This finds the slowest link in the path to the device by computing the total bandwidth of each link and compares that with the capabilities of the device. The dmesg change is: - PCIe link speed is %s, device supports %s - PCIe link width is x%d, device supports x%d + %u.%03u Gb/s available PCIe bandwidth (%s x%d link) or, if the device is capable of better performance than is available in the current slot: - A slot with more lanes and/or higher speed is suggested for optimal performance. + %u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link) Signed-off-by: -
Bjorn Helgaas authored
Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (which may be different links) without considering the total bandwidth of each link. For a path with a 16 GT/s x1 link and a 2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of bandwidth, not the true available bandwidth of about 1969 MB/s for a 16 GT/s x1 link. Use pcie_print_link_status() to report PCIe link speed and possible limitations instead of implementing this in the driver itself. This finds the slowest link in the path to the device by computing the total bandwidth of each link and compares that with the capabilities of the device. The dmesg change is: - PCIe: Speed %s Width x%d + %u.%03u Gb/s available PCIe bandwidth (%s x%d link) Signed-off-by: -
Bjorn Helgaas authored
Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (which may be different links) without considering the total bandwidth of each link. For a path with a 16 GT/s x1 link and a 2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of bandwidth, not the true available bandwidth of about 1969 MB/s for a 16 GT/s x1 link. Use pcie_print_link_status() to report PCIe link speed and possible limitations instead of implementing this in the driver itself. This finds the slowest link in the path to the device by computing the total bandwidth of each link and compares that with the capabilities of the device. The dmesg change is: - %s (%c%d) PCI-E x%d %s found at mem %lx, IRQ %d, node addr %pM + %s (%c%d) PCI-E found at mem %lx, IRQ %d, node addr %pM + %u.%03u Gb/s available PCIe bandwidth (%s x%d link) Signed-off-by: -
Christoph Hellwig authored
Manipulating the enable_cnt behind the back of the driver will wreak complete havoc with the kernel state, so disallow it. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
-
- 23 May, 2018 2 commits
-
-
Mika Westerberg authored
Currently we request control of native PCIe hotplug unconditionally. Native PCIe hotplug events are handled by the pciehp driver, and if it is not enabled those events will be lost. Request control of native PCIe hotplug only if the pciehp driver is enabled, so we will actually handle native PCIe hotplug events. Suggested-by:
-
Mika Westerberg authored
After a suspend/resume cycle the Presence Detect or Data Link Layer Status Changed bits might be set. If we don't clear them those events will not fire anymore and nothing happens for instance when a device is now hot-unplugged. Fix this by clearing those bits in a newly introduced function pcie_reenable_notification(). This should be fine because immediately after, we check if the adapter is still present by reading directly from the status register. Signed-off-by:
-
