summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2018-06-07Merge branch 'pci/enumeration'Bjorn Helgaas3-49/+61
- 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
2018-06-07Merge branch 'pci/dpc'Bjorn Helgaas1-1/+4
- clear interrupt status in top half to avoid interrupt storm (Oza Pawandeep) * pci/dpc: PCI/DPC: Clear interrupt status in interrupt handler top half
2018-06-07Merge branch 'pci/aspm'Bjorn Helgaas2-0/+14
- 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
2018-06-06PCI/AER: Replace struct pcie_device with pci_devKeith Busch3-14/+12
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>
2018-06-06PCI/AER: Remove unused parametersKeith Busch1-9/+5
Remove unused "struct pcie_device *" parameters to handle_error_source() and aer_process_err_devices(). No functional change intended. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-05Merge tag 'pm-4.18-rc1' of ↵Linus Torvalds2-6/+5
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "These include a significant update of the generic power domains (genpd) and Operating Performance Points (OPP) frameworks, mostly related to the introduction of power domain performance levels, cpufreq updates (new driver for Qualcomm Kryo processors, updates of the existing drivers, some core fixes, schedutil governor improvements), PCI power management fixes, ACPI workaround for EC-based wakeup events handling on resume from suspend-to-idle, and major updates of the turbostat and pm-graph utilities. Specifics: - Introduce power domain performance levels into the the generic power domains (genpd) and Operating Performance Points (OPP) frameworks (Viresh Kumar, Rajendra Nayak, Dan Carpenter). - Fix two issues in the runtime PM framework related to the initialization and removal of devices using device links (Ulf Hansson). - Clean up the initialization of drivers for devices in PM domains (Ulf Hansson, Geert Uytterhoeven). - Fix a cpufreq core issue related to the policy sysfs interface causing CPU online to fail for CPUs sharing one cpufreq policy in some situations (Tao Wang). - Make it possible to use platform-specific suspend/resume hooks in the cpufreq-dt driver and make the Armada 37xx DVFS use that feature (Viresh Kumar, Miquel Raynal). - Optimize policy transition notifications in cpufreq (Viresh Kumar). - Improve the iowait boost mechanism in the schedutil cpufreq governor (Patrick Bellasi). - Improve the handling of deferred frequency updates in the schedutil cpufreq governor (Joel Fernandes, Dietmar Eggemann, Rafael Wysocki, Viresh Kumar). - Add a new cpufreq driver for Qualcomm Kryo (Ilia Lin). - Fix and clean up some cpufreq drivers (Colin Ian King, Dmitry Osipenko, Doug Smythies, Luc Van Oostenryck, Simon Horman, Viresh Kumar). - Fix the handling of PCI devices with the DPM_SMART_SUSPEND flag set and update stale comments in the PCI core PM code (Rafael Wysocki). - Work around an issue related to the handling of EC-based wakeup events in the ACPI PM core during resume from suspend-to-idle if the EC has been put into the low-power mode (Rafael Wysocki). - Improve the handling of wakeup source objects in the PM core (Doug Berger, Mahendran Ganesh, Rafael Wysocki). - Update the driver core to prevent deferred probe from breaking suspend/resume ordering (Feng Kan). - Clean up the PM core somewhat (Bjorn Helgaas, Ulf Hansson, Rafael Wysocki). - Make the core suspend/resume code and cpufreq support the RT patch (Sebastian Andrzej Siewior, Thomas Gleixner). - Consolidate the PM QoS handling in cpuidle governors (Rafael Wysocki). - Fix a possible crash in the hibernation core (Tetsuo Handa). - Update the rockchip-io Adaptive Voltage Scaling (AVS) driver (David Wu). - Update the turbostat utility (fixes, cleanups, new CPU IDs, new command line options, built-in "Low Power Idle" counters support, new POLL and POLL% columns) and add an entry for it to MAINTAINERS (Len Brown, Artem Bityutskiy, Chen Yu, Laura Abbott, Matt Turner, Prarit Bhargava, Srinivas Pandruvada). - Update the pm-graph to version 5.1 (Todd Brandt). - Update the intel_pstate_tracer utility (Doug Smythies)" * tag 'pm-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (128 commits) tools/power turbostat: update version number tools/power turbostat: Add Node in output tools/power turbostat: add node information into turbostat calculations tools/power turbostat: remove num_ from cpu_topology struct tools/power turbostat: rename num_cores_per_pkg to num_cores_per_node tools/power turbostat: track thread ID in cpu_topology tools/power turbostat: Calculate additional node information for a package tools/power turbostat: Fix node and siblings lookup data tools/power turbostat: set max_num_cpus equal to the cpumask length tools/power turbostat: if --num_iterations, print for specific number of iterations tools/power turbostat: Add Cannon Lake support tools/power turbostat: delete duplicate #defines x86: msr-index.h: Correct SNB_C1/C3_AUTO_UNDEMOTE defines tools/power turbostat: Correct SNB_C1/C3_AUTO_UNDEMOTE defines tools/power turbostat: add POLL and POLL% column tools/power turbostat: Fix --hide Pk%pc10 tools/power turbostat: Build-in "Low Power Idle" counters support tools/power turbostat: Don't make man pages executable tools/power turbostat: remove blank lines tools/power turbostat: a small C-states dump readability immprovement ...
2018-06-05Merge branch 'irq-core-for-linus' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq updates from Thomas Gleixner: - Consolidation of softirq pending: The softirq mask and its accessors/mutators have many implementations scattered around many architectures. Most do the same things consisting in a field in a per-cpu struct (often irq_cpustat_t) accessed through per-cpu ops. We can provide instead a generic efficient version that most of them can use. In fact s390 is the only exception because the field is stored in lowcore. - Support for level!?! triggered MSI (ARM) Over the past couple of years, we've seen some SoCs coming up with ways of signalling level interrupts using a new flavor of MSIs, where the MSI controller uses two distinct messages: one that raises a virtual line, and one that lowers it. The target MSI controller is in charge of maintaining the state of the line. This allows for a much simplified HW signal routing (no need to have hundreds of discrete lines to signal level interrupts if you already have a memory bus), but results in a departure from the current idea the kernel has of MSIs. - Support for Meson-AXG GPIO irqchip - Large stm32 irqchip rework (suspend/resume, hierarchical domains) - More SPDX conversions * 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits) ARM: dts: stm32: Add exti support to stm32mp157 pinctrl ARM: dts: stm32: Add exti support for stm32mp157c pinctrl/stm32: Add irq_eoi for stm32gpio irqchip irqchip/stm32: Add suspend/resume support for hierarchy domain irqchip/stm32: Add stm32mp1 support with hierarchy domain irqchip/stm32: Prepare common functions irqchip/stm32: Add host and driver data structures irqchip/stm32: Add suspend support irqchip/stm32: Add falling pending register support irqchip/stm32: Checkpatch fix irqchip/stm32: Optimizes and cleans up stm32-exti irq_domain irqchip/meson-gpio: Add support for Meson-AXG SoCs dt-bindings: interrupt-controller: New binding for Meson-AXG SoC dt-bindings: interrupt-controller: Fix the double quotes softirq/s390: Move default mutators of overwritten softirq mask to s390 softirq/x86: Switch to generic local_softirq_pending() implementation softirq/sparc: Switch to generic local_softirq_pending() implementation softirq/powerpc: Switch to generic local_softirq_pending() implementation softirq/parisc: Switch to generic local_softirq_pending() implementation softirq/ia64: Switch to generic local_softirq_pending() implementation ...
2018-06-04Merge tag 'dma-mapping-4.18' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds3-7/+34
Pull dma-mapping updates from Christoph Hellwig: - replace the force_dma flag with a dma_configure bus method. (Nipun Gupta, although one patch is іncorrectly attributed to me due to a git rebase bug) - use GFP_DMA32 more agressively in dma-direct. (Takashi Iwai) - remove PCI_DMA_BUS_IS_PHYS and rely on the dma-mapping API to do the right thing for bounce buffering. - move dma-debug initialization to common code, and apply a few cleanups to the dma-debug code. - cleanup the Kconfig mess around swiotlb selection - swiotlb comment fixup (Yisheng Xie) - a trivial swiotlb fix. (Dan Carpenter) - support swiotlb on RISC-V. (based on a patch from Palmer Dabbelt) - add a new generic dma-noncoherent dma_map_ops implementation and use it for arc, c6x and nds32. - improve scatterlist validity checking in dma-debug. (Robin Murphy) - add a struct device quirk to limit the dma-mask to 32-bit due to bridge/system issues, and switch x86 to use it instead of a local hack for VIA bridges. - handle devices without a dma_mask more gracefully in the dma-direct code. * tag 'dma-mapping-4.18' of git://git.infradead.org/users/hch/dma-mapping: (48 commits) dma-direct: don't crash on device without dma_mask nds32: use generic dma_noncoherent_ops nds32: implement the unmap_sg DMA operation nds32: consolidate DMA cache maintainance routines x86/pci-dma: switch the VIA 32-bit DMA quirk to use the struct device flag x86/pci-dma: remove the explicit nodac and allowdac option x86/pci-dma: remove the experimental forcesac boot option Documentation/x86: remove a stray reference to pci-nommu.c core, dma-direct: add a flag 32-bit dma limits dma-mapping: remove unused gfp_t parameter to arch_dma_alloc_attrs dma-debug: check scatterlist segments c6x: use generic dma_noncoherent_ops arc: use generic dma_noncoherent_ops arc: fix arc_dma_{map,unmap}_page arc: fix arc_dma_sync_sg_for_{cpu,device} arc: simplify arc_dma_sync_single_for_{cpu,device} dma-mapping: provide a generic dma-noncoherent implementation dma-mapping: simplify Kconfig dependencies riscv: add swiotlb support riscv: only enable ZONE_DMA32 for 64-bit ...
2018-06-04PCI: qcom: Include gpio/consumer.hArnd Bergmann1-1/+1
When CONFIG_GPIOLIB is disabled, we run into a build failure: drivers/pci/dwc/pcie-qcom.c: In function 'qcom_pcie_probe': drivers/pci/dwc/pcie-qcom.c:1223:16: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration] pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); Including gpio/consumer.h directly is the correct fix. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-06-04PCI: Improve "partially hidden behind bridge" log messageMika Westerberg1-9/+4
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: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-04PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() docMika Westerberg1-0/+4
It is not immediately clear what the two functions actually return so add kernel-doc comment explaining it a bit better. Suggested-by: Bjorn Helgaas <bhelgaas@google.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> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-06-04PCI: Move resource distribution for single bridge outside loopMika Westerberg1-41/+41
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: Bjorn Helgaas <bhelgaas@google.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> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-06-04PCI: Account for all bridges on bus when distributing bus numbersMika Westerberg1-3/+12
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: 1c02ea810065 ("PCI: Distribute available buses to hotplug-capable bridges") Reported-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org
2018-06-04ACPI / hotplug / PCI: Drop unnecessary parenthesesMika Westerberg1-2/+2
Remove unnecessary parentheses. 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>
2018-06-04ACPI / hotplug / PCI: Mark stale PCI devices disconnectedMika Westerberg1-0/+5
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 <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-06-04ACPI / hotplug / PCI: Don't scan bridges managed by native hotplugMika Westerberg1-17/+58
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.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: changelog, use hotplug_is_native() instead of dev->is_hotplug_bridge] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-06-04PCI: shpchp: Add shpchp_is_native()Mika Westerberg4-16/+32
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: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-04PCI: shpchp: Fix AMD POGO identificationBjorn Helgaas1-4/+4
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: 53044f357448 ("[PATCH] PCI Hotplug: shpchp: AMD POGO errata fix") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-04PCI: mobiveil: Add MSI supportSubrahmanya Lingappa1-4/+202
Implement MSI support for Mobiveil PCIe Host Bridge IP device driver. Signed-off-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Marc Zyngier <marc.zyngier@arm.com>
2018-06-04PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driverSubrahmanya Lingappa1-0/+669
Add a driver for Mobiveil AXI PCIe Host Bridge Soft IP - GPEX 4.0, a PCIe gen4 IP. This IP has upto 8 outbound and inbound windows for the address translation. Signed-off-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> [bhelgaas: fold in mobiveil_pcie_of_match[] NULL termination from Wei Yongjun <weiyongjun1@huawei.com>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Marc Zyngier <marc.zyngier@arm.com>
2018-06-03PCI/AER: Decode Error Source Requester IDBjorn Helgaas1-7/+11
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: Bjorn Helgaas <bhelgaas@google.com>
2018-06-03PCI/AER: Remove aer_recover_work_func() forward declarationBorislav Petkov1-24/+24
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: Bjorn Helgaas <bhelgaas@google.com>
2018-06-03PCI/DPC: Use the generic pcie_do_fatal_recovery() pathOza Pawandeep1-20/+33
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: Bjorn Helgaas <bhelgaas@google.com>
2018-06-03PCI/AER: Pass service type to pcie_do_fatal_recovery()Oza Pawandeep3-8/+9
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 <poza@codeaurora.org> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-03PCI/DPC: Disable ERR_NONFATAL handling by DPCOza Pawandeep1-2/+2
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 <poza@codeaurora.org> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-03PCI/portdrv: Add generic pcie_port_find_device()Oza Pawandeep2-0/+24
Add generic pcie_port_find_device() routine. Signed-off-by: Oza Pawandeep <poza@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
2018-06-02PCI: shpchp: Use dev_printk() for OSHP-related messagesBjorn Helgaas1-7/+6
Use dev_printk() for messages related to requesting control of SHPC hotplug via the OSHP method. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-02PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapperMika Westerberg2-11/+1
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 <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-02PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flagsMika Westerberg2-4/+2
acpi_get_hp_hw_control_from_firmware() no longer uses the flags parameter, so remove it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-02PCI: shpchp: Rely on previous _OSC resultsMika Westerberg1-19/+10
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 <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-06-02PCI: shpchp: Request SHPC control via _OSC when adding host bridgeMika Westerberg1-0/+1
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: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-02PCI: shpchp: Convert SHPC to be builtin onlyMika Westerberg1-4/+1
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: Bjorn Helgaas <bhelgaas@google.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>
2018-06-02PCI: pciehp: Make pciehp_is_native() stricterMika Westerberg2-14/+14
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: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: remove NULL pointer check] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-02PCI: pciehp: Rename host->native_hotplug to host->native_pcie_hotplugMika Westerberg2-2/+2
Rename host->native_hotplug to host->native_pcie_hotplug to make room for a similar flag for SHPC hotplug. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-30PCI: Enable PCI_DOMAINS along with generic PCI host controllerJan Kiszka1-0/+1
The generic PCI host controller is often instantiated by hypervisors, and they may add several of them or add them in addition to a physical host controller like the Jailhouse hypervisor is doing. Therefore, allow for multiple domains so that we can handle them all. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-30PCI: Add support for unbinding the generic PCI host controllerJan Kiszka2-0/+14
Add support for unbinding the generic PCI host controller. This is particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Will Deacon <will.deacon@arm.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2018-05-30PCI: Rework of_pci_get_host_bridge_resources() to ↵Jan Kiszka13-30/+24
devm_of_pci_get_host_bridge_resources() of_pci_get_host_bridge_resources() allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, convert the existing function to a managed version. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by: Joao Pinto <jpinto@synopsys.com> Acked-by: Jingoo Han <jingoohan1@gmail.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2018-05-30PCI: Use dev_printk() in of_pci_get_host_bridge_resources()Jan Kiszka1-10/+10
Now that we have a device reference, make use of it for printing. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
2018-05-30PCI: Pass struct device to of_pci_get_host_bridge_resources()Jan Kiszka13-28/+27
Another step towards a managed version of of_pci_get_host_bridge_resources(): Feed in the underlying device, rather than just the OF node. This will allow us to use managed resource allocation internally later on. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by: Jingoo Han <jingoohan1@gmail.com> CC: Joao Pinto <Joao.Pinto@synopsys.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2018-05-30PCI: Rename of_pci_get_host_bridge_resources() device node parameterJan Kiszka1-9/+9
We will add a "struct device *dev" parameter to this function soon, so rename the existing "struct device_node *dev" parameter to "dev_node". Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
2018-05-30PCI: Fix devm_pci_alloc_host_bridge() memory leakJan Kiszka1-1/+3
Fix a memory leak by freeing the PCI resource list in devm_pci_release_host_bridge_dev(). Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-26PCI: Remove unused pcie_get_minimum_link()Bjorn Helgaas1-43/+0
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>
2018-05-26PCI: Prevent sysfs disable of device while driver is attachedChristoph Hellwig1-6/+9
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: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Acked-by: Keith Busch <keith.busch@intel.com>
2018-05-25PCI/IOV: Allow PF drivers to limit total_VFs to 0Jakub Kicinski1-4/+2
Some SR-IOV PF drivers implement .sriov_configure(), which allows user-space to enable VFs by writing the desired number of VFs to the sysfs "sriov_numvfs" file (see sriov_numvfs_store()). The PCI core limits the number of VFs to the TotalVFs advertised by the device in its SR-IOV capability. The PF driver can limit the number of VFs to even fewer (it may have pre-allocated data structures or knowledge of device limitations) by calling pci_sriov_set_totalvfs(), but previously it could not limit the VFs to 0. Change pci_sriov_get_totalvfs() so it always respects the VF limit imposed by the PF driver, even if the limit is 0. This sequence: pci_sriov_set_totalvfs(dev, 0); x = pci_sriov_get_totalvfs(dev); previously set "x" to TotalVFs from the SR-IOV capability. Now it will set "x" to 0. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-25PCI: hv: Do not wait forever on a device that has disappearedDexuan Cui1-12/+34
Before the guest finishes the device initialization, the device can be removed anytime by the host, and after that the host won't respond to the guest's request, so the guest should be prepared to handle this case. Add a polling mechanism to detect device presence. Signed-off-by: Dexuan Cui <decui@microsoft.com> [lorenzo.pieralisi@arm.com: edited commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com>
2018-05-24PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi() failpathMarek Vasut1-9/+16
The rcar_pcie_enable_msi() creates IRQ mappings using irq_create_mapping() before requesting the IRQs using devm_request_irq(). If devm_request_irq() fails for some reason, rcar_pcie_enable_msi() does not remove the mapping. Pull out the code for disposing IRQ mappings from rcar_pcie_teardown_msi() into a separate function and call it from both rcar_pcie_teardown_msi() and rcar_pcie_enable_msi() failpath to remove the mappings correctly. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2018-05-24PCI: rcar: Teardown MSI setup if rcar_pcie_enable() failsMarek Vasut1-1/+27
If the rcar_pcie_enable() fails and MSIs are enabled, the setup done in rcar_pcie_enable_msi() is never undone. Add a function to tear down the MSI setup by disabling the MSI handling in the PCIe block, deallocating the pages requested for the MSIs and zapping the IRQ mapping. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2018-05-24PCI: rcar: Add missing irq_dispose_mapping() into failpathMarek Vasut1-3/+14
The rcar_pcie_get_resources() is another misnomer with a side effect. The function does not only get resources, but also maps MSI IRQs via irq_of_parse_and_map(). In case anything fails afterward, the IRQ mapping must be disposed through irq_dispose_mapping() which is not done. This patch handles irq_of_parse_and_map() failures in by disposing of the mapping in rcar_pcie_get_resources() as well as in probe. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2018-05-24PCI: rcar: Pull bus clock enable/disable from rcar_pcie_get_resources()Marek Vasut1-17/+16
The rcar_pcie_get_resources() is another misnomer with a side effect. The function does not only get resources, but also enables/disables bus clock. This is forgotten in the probe() function though and if anything in probe() fails after rcar_pcie_get_resources() is called, the bus clock are never disabled. This patch pulls the clock handling out of the rcar_pcie_get_resources() and enables clock after all the resources were requested. Moreover, this patch also always disables the clock in case of failure. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2018-05-24PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()Marek Vasut1-2/+3
The data link active signal usually takes ~20 uSec to be asserted, poll the bit more often to avoid useless delays in this function. Use udelay() instead of usleep() for such a small delay as suggested by the timer documentation. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-20 00:07:46 +0300