summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2020-10-05Merge 5.9-rc8 into usb-nextGreg Kroah-Hartman1-7/+4
We need the USB fixes in here as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-03Merge tag 'pci-v5.9-fixes-2' of ↵Linus Torvalds1-7/+4
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: - Fix rockchip regression in rockchip_pcie_valid_device() (Lorenzo Pieralisi) - Add Pali Rohár as aardvark PCI maintainer (Pali Rohár) * tag 'pci-v5.9-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: MAINTAINERS: Add Pali Rohár as aardvark PCI maintainer PCI: rockchip: Fix bus checks in rockchip_pcie_valid_device()
2020-10-02PCI: aardvark: Fix initialization with old Marvell's Arm Trusted FirmwarePali Rohár1-1/+3
Old ATF automatically power on pcie phy and does not provide SMC call for phy power on functionality which leads to aardvark initialization failure: [ 0.330134] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try updating your firmware [ 0.338846] phy phy-d0018300.phy.1: phy poweron failed --> -95 [ 0.344753] advk-pcie d0070000.pcie: Failed to initialize PHY (-95) [ 0.351160] advk-pcie: probe of d0070000.pcie failed with error -95 This patch fixes above failure by ignoring 'not supported' error in aardvark driver. In this case it is expected that phy is already power on. Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Link: https://lore.kernel.org/r/20200902144344.16684-3-pali@kernel.org Fixes: 366697018c9a ("PCI: aardvark: Add PHY support") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: <stable@vger.kernel.org> # 5.8+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno
2020-10-02PCI: xgene: Remove unused assignment to variable msi_valKrzysztof Wilczyński1-2/+2
The value assigned to msi_val after the inner loop finishes its run is never used for anything, and it is also immediately overridden in the line that follows with the return value from the xgene_msi_int_read() function. Since the value of msi_val following the inner loop completion is never used in any meaningful way the assignment can be removed. Addresses-Coverity-ID: 1437183 ("Unused value") Link: https://lore.kernel.org/r/20200922030257.459898-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-10-02PCI: loongson: Simplify loongson_pci_probe() return expressionQinglang Miao1-6/+1
Simplify the return expression. Link: https://lore.kernel.org/r/20200921131054.92797-1-miaoqinglang@huawei.com Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-10-02PCI: cadence: Simplify cdns_pcie_host_init_address_translation() return ↵Qinglang Miao1-6/+2
expression Simplify the return expression. Link: https://lore.kernel.org/r/20200921131053.92752-1-miaoqinglang@huawei.com Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-10-02PCI: mobiveil: Simplify mobiveil_pcie_init_irq_domain() return expressionLiu Shixin1-6/+1
Simplify the return expression by removing useless code. Link: https://lore.kernel.org/r/20200921082447.2591877-1-liushixin2@huawei.com Signed-off-by: Liu Shixin <liushixin2@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-10-02PCI: iproc: Use module_bcma_driver to simplify the codeLiu Shixin1-12/+1
module_bcma_driver() makes the code simpler by eliminating boilerplate code. Link: https://lore.kernel.org/r/20200918030829.3946025-1-liushixin2@huawei.com Signed-off-by: Liu Shixin <liushixin2@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Ray Jui <ray.jui@broadcom.com>
2020-10-02PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match listJim Quinlan1-0/+4
Now that the support is in place with previous commits, we add several chips that use the BrcmSTB driver. Link: https://lore.kernel.org/r/20200911175232.19016-11-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
2020-10-02PCI: brcmstb: Set bus max burst size by chip typeJim Quinlan1-4/+15
The proper value of the parameter SCB_MAX_BURST_SIZE varies per chip. The 2711 family requires 128B whereas other devices can employ 512. The assignment is complicated by the fact that the values for this two-bit field have different meanings; Value Type_Generic Type_7278 00 Reserved 128B 01 128B 256B 10 256B 512B 11 512B Reserved Link: https://lore.kernel.org/r/20200911175232.19016-10-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-10-02PCI: brcmstb: Accommodate MSI for older chipsJim Quinlan1-21/+49
Older BrcmSTB chips do not have a separate register for MSI interrupts; the MSIs are in a register that also contains unrelated interrupts. In addition, the interrupts lie in bits [31..24] for these legacy chips. This commit provides common code for both legacy and non-legacy MSI interrupt registers. Link: https://lore.kernel.org/r/20200911175232.19016-9-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-10-02PCI: brcmstb: Set additional internal memory DMA viewport sizesJim Quinlan1-18/+49
The Raspberry Pi (RPI) is currently the only chip using this driver (pcie-brcmstb.c). There, only one memory controller is used, without an extension region, and the SCB0 viewport size is set to the size of the first and only dma-range region. Other BrcmSTB SOCs have more complicated memory configurations that require setting additional viewport sizes. BrcmSTB PCIe controllers are intimately connected to the memory controller(s) on the SOC. The SOC may have one to three memory controllers; they are indicated by the term SCBi. Each controller has a base region and an optional extension region. In physical memory, the base and extension regions of a controller are not adjacent, but in PCIe-space they are. There is a "viewport" for each memory controller that allows DMA from endpoint devices. Each viewport's size must be set to a power of two, and that size must be equal to or larger than the amount of memory each controller supports which is the sum of base region and its optional extension. Further, the 1-3 viewports are also adjacent in PCIe-space. Unfortunately the viewport sizes cannot be ascertained from the "dma-ranges" property so they have their own property, "brcm,scb-sizes". This is because dma-range information does not indicate what memory controller it is associated. For example, consider the following case where the size of one dma-range is 2GB and the second dma-range is 1GB: /* Case 1: SCB0 size set to 4GB */ dma-range0: 2GB (from memc0-base) dma-range1: 1GB (from memc0-extension) /* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */ dma-range0: 2GB (from memc0-base) dma-range1: 1GB (from memc0-extension) By just looking at the dma-ranges information, one cannot tell which situation applies. That is why an additional property is needed. Its length indicates the number of memory controllers being used and each value indicates the viewport size. Note that the RPI DT does not have a "brcm,scb-sizes" property value, as it is assumed that it only requires one memory controller and no extension. So the optional use of "brcm,scb-sizes" will be backwards compatible. One last layer of complexity exists: all of the viewports sizes must be added and rounded up to a power of two to determine what the "BAR" size is. Further, an offset must be given that indicates the base PCIe address of this "BAR". The use of the term BAR is typically associated with endpoint devices, and the term is used here because the PCIe HW may be used as an RC or an EP. In the former case, all of the system memory appears in a single "BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely used in the EP role and its system of mapping memory is an artifact that requires multiple dma-ranges regions. Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-10-02PCI: brcmstb: Add control of rescal resetJim Quinlan1-2/+77
Some STB chips have a special purpose reset controller named RESCAL (reset calibration). The PCIe HW can now control RESCAL to start and stop its operation. On probe(), the RESCAL is deasserted and the driver goes through the sequence of setting registers and reading status in order to start the internal PHY that is required for the PCIe. Link: https://lore.kernel.org/r/20200911175232.19016-7-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-10-02PCI: hv: Fix hibernation in case interrupts are not re-createdDexuan Cui1-3/+47
pci_restore_msi_state() directly writes the MSI/MSI-X related registers via MMIO. On a physical machine, this works perfectly; for a Linux VM running on a hypervisor, which typically enables IOMMU interrupt remapping, the hypervisor usually should trap and emulate the MMIO accesses in order to re-create the necessary interrupt remapping table entries in the IOMMU, otherwise the interrupts can not work in the VM after hibernation. Hyper-V is different from other hypervisors in that it does not trap and emulate the MMIO accesses, and instead it uses a para-virtualized method, which requires the VM to call hv_compose_msi_msg() to notify the hypervisor of the info that would be passed to the hypervisor in the case of the trap-and-emulate method. This is not an issue to a lot of PCI device drivers, which destroy and re-create the interrupts across hibernation, so hv_compose_msi_msg() is called automatically. However, some PCI device drivers (e.g. the in-tree GPU driver nouveau and the out-of-tree Nvidia proprietary GPU driver) do not destroy and re-create MSI/MSI-X interrupts across hibernation, so hv_pci_resume() has to call hv_compose_msi_msg(), otherwise the PCI device drivers can no longer receive interrupts after the VM resumes from hibernation. Hyper-V is also different in that chip->irq_unmask() may fail in a Linux VM running on Hyper-V (on a physical machine, chip->irq_unmask() can not fail because unmasking an MSI/MSI-X register just means an MMIO write): during hibernation, when a CPU is offlined, the kernel tries to move the interrupt to the remaining CPUs that haven't been offlined yet. In this case, hv_irq_unmask() -> hv_do_hypercall() always fails because the vmbus channel has been closed: here the early "return" in hv_irq_unmask() means the pci_msi_unmask_irq() is not called, i.e. the desc->masked remains "true", so later after hibernation, the MSI interrupt always remains masked, which is incorrect. Refer to cpu_disable_common() -> fixup_irqs() -> irq_migrate_all_off_this_cpu() -> migrate_one_irq(): static bool migrate_one_irq(struct irq_desc *desc) { ... if (maskchip && chip->irq_mask) chip->irq_mask(d); ... err = irq_do_set_affinity(d, affinity, false); ... if (maskchip && chip->irq_unmask) chip->irq_unmask(d); Fix the issue by calling pci_msi_unmask_irq() unconditionally in hv_irq_unmask(). Also suppress the error message for hibernation because the hypercall failure during hibernation does not matter (at this time all the devices have been frozen). Note: the correct affinity info is still updated into the irqdata data structure in migrate_one_irq() -> irq_do_set_affinity() -> hv_set_affinity(), so later when the VM resumes, hv_pci_restore_msi_state() is able to correctly restore the interrupt with the correct affinity. Link: https://lore.kernel.org/r/20201002085158.9168-1-decui@microsoft.com Fixes: ac82fc832708 ("PCI: hv: Add hibernation support") Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Jake Oshins <jakeo@microsoft.com>
2020-10-01PCI: Add Kconfig options for MPS/MRRS strategyJim Quinlan2-0/+74
Add Kconfig options for changing the default pcie_bus_config, i.e., the strategy for configuration MPS and MRRS, in the same manner as the CONFIG_PCIEASPM_XXXX choice. The pci_bus_config setting may still be overridden by kernel command-line parameters, e.g., "pci=pcie_bus_tune_off". [bhelgaas: depend on EXPERT, tweak help texts] Link: https://lore.kernel.org/r/20200928194651.5393-2-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-10-01PCI/PM: Revert "PCI/PM: Apply D2 delay as milliseconds, not microseconds"Bjorn Helgaas2-4/+4
This reverts commit 7e24bc347e57992d532bc2ed700209b0fc0a4bf5. 7e24bc347e57 was based on PCIe r5.0, sec 5.9, which claims we need a 200 ms delay when transitioning to or from D2. However, sec 5.3.1.3 states the delay as 200 μs (microseconds), as does the table in PCIe r4.0, sec 5.9.1. This looks like a typo in the r5.0 spec, so revert back to a 200 μs delay instead of a 200 ms delay. Fixes: 7e24bc347e57 ("PCI/PM: Apply D2 delay as milliseconds, not microseconds") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-10-01PCI/PM: Remove unused PCI_PM_BUS_WAITBjorn Helgaas1-1/+0
476e7faefc43 ("PCI PM: Do not wait for buses in B2 or B3 during resume") removed the last use of PCI_PM_BUS_WAIT. Remove the definition as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-10-01PCI/P2PDMA: Drop double zeroing for sg_init_table()Julia Lawall1-1/+1
sg_init_table() zeroes its first argument, so the allocation of that argument doesn't have to. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x; @@ x = - kzalloc + kmalloc (...) ... sg_init_table(x,...) // </smpl> Link: https://lore.kernel.org/r/1600601186-7420-15-git-send-email-Julia.Lawall@inria.fr Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-10-01PCI: Simplify bool comparisonsKrzysztof Wilczyński1-2/+2
Take care about Coccinelle warnings: drivers/pci/pci.c:6008:6-12: WARNING: Comparison to bool drivers/pci/pci.c:6024:7-13: WARNING: Comparison to bool No change to functionality intended. Link: https://lore.kernel.org/r/20200925224555.1752460-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-30Merge tag 'thunderbolt-for-v5.10-rc1' of ↵Greg Kroah-Hartman1-57/+0
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v5.10 merge window This includes following Thunderbolt/USB4 changes for v5.10 merge window: * A couple of optimizations around Tiger Lake force power logic and NHI (Native Host Interface) LC (Link Controller) mailbox command processing * Power management improvements for Software Connection Manager * Debugfs support * Allow KUnit tests to be enabled also when Thunderbolt driver is configured as module. * Few minor cleanups and fixes All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (37 commits) thunderbolt: Capitalize comment on top of QUIRK_FORCE_POWER_LINK_CONTROLLER thunderbolt: Correct tb_check_quirks() kernel-doc thunderbolt: Log correct zeroX entries in decode_error() thunderbolt: Handle ERR_LOCK notification thunderbolt: Use "if USB4" instead of "depends on" in Kconfig thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m thunderbolt: Only stop control channel when entering freeze thunderbolt: debugfs: Fix uninitialized return in counters_write() thunderbolt: Add debugfs interface thunderbolt: No need to warn in TB_CFG_ERROR_INVALID_CONFIG_SPACE thunderbolt: Introduce tb_switch_is_tiger_lake() thunderbolt: Introduce tb_switch_is_ice_lake() thunderbolt: Check for Intel vendor ID when identifying controller thunderbolt: Introduce tb_port_is_nhi() thunderbolt: Introduce tb_switch_next_cap() thunderbolt: Introduce tb_port_next_cap() thunderbolt: Move struct tb_cap_any to tb_regs.h thunderbolt: Add runtime PM for Software CM thunderbolt: Create device links from ACPI description ACPI: Export acpi_get_first_physical_node() to modules ...
2020-09-29PCI/PM: Rename pci_dev.d3_delay to d3hot_delayKrzysztof Wilczyński4-46/+46
PCI devices support two variants of the D3 power state: D3hot (main power present) D3cold (main power removed). Previously struct pci_dev contained: unsigned int d3_delay; /* D3->D0 transition time in ms */ unsigned int d3cold_delay; /* D3cold->D0 transition time in ms */ "d3_delay" refers specifically to the D3hot state. Rename it to "d3hot_delay" to avoid ambiguity and align with the ACPI "_DSM for Specifying Device Readiness Durations" in the PCI Firmware spec r3.2, sec 4.6.9. There is no change to the functionality. Link: https://lore.kernel.org/r/20200730210848.1578826-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-29PCI/PM: Remove unused pcibios_pm_opsVaibhav Gupta1-26/+0
The "struct dev_pm_ops pcibios_pm_ops", declared in include/linux/pci.h and defined in drivers/pci/pci-driver.c, provided arch-specific hooks when a PCI device was doing a hibernate transition. 394216275c7d ("s390: remove broken hibernate / power management support") removed the last use of pcibios_pm_ops, so remove it completely. [bhelgaas: drop unused "error"] Link: https://lore.kernel.org/r/20200730194416.1029509-1-vaibhavgupta40@gmail.com Reported-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-29PCI: shpchp: Remove unused 'rc' assignmentKrzysztof Wilczyński1-1/+0
The value of the constant POWER_FAILURE assigned to the variable rc after the power fault check is never used for anything, so remove it. Addresses-Coverity-ID: 1226899 ("Unused value") Link: https://lore.kernel.org/r/20200923025225.471459-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-28PCI: kirin: Return -EPROBE_DEFER in case the gpio isn't readyBean Huo1-1/+5
PCI host bridge driver can be probed before the gpiochip it requires, so, of_get_named_gpio() can return -EPROBE_DEFER. Current code lets the kirin_pcie_probe() directly return -ENODEV, which results in the PCI host controller driver probe failure; with this error code the PCI host controller driver will not be probed again when the gpiochip driver is loaded. Fix the above issue by letting kirin_pcie_probe() return -EPROBE_DEFER in such a case. Link: https://lore.kernel.org/r/20200918123800.19983-1-huobean@gmail.com Signed-off-by: Bean Huo <beanhuo@micron.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-09-28PCI: dwc: Fix 'cast truncates bits from constant value'Gustavo Pimentel1-1/+1
Fixes warning given by executing "make C=2 drivers/pci/" Sparse output: CHECK drivers/pci/controller/dwc/pcie-designware.c drivers/pci/controller/dwc/pcie-designware.c:432:52: warning: cast truncates bits from constant value (ffffffff7fffffff becomes 7fffffff) Link: https://lore.kernel.org/r/7ea7f7d342f97c758949a17b870012f52ce5b3f5.1600767645.git.gustavo.pimentel@synopsys.com Reported-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Joao Pinto <jpinto@synopsys.com>
2020-09-28PCI: tegra: Convert to use DEFINE_SEQ_ATTRIBUTE macroLiu Shixin1-25/+3
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code. Link: https://lore.kernel.org/r/20200916025025.3992783-1-liushixin2@huawei.com Signed-off-by: Liu Shixin <liushixin2@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thierry Reding <treding@nvidia.com>
2020-09-28PCI: hv: Document missing hv_pci_protocol_negotiation() parameterKrzysztof Wilczyński1-1/+4
Add missing documentation for the parameter "version" and "num_version" of the hv_pci_protocol_negotiation() function and resolve build time kernel-doc warnings: drivers/pci/controller/pci-hyperv.c:2535: warning: Function parameter or member 'version' not described in 'hv_pci_protocol_negotiation' drivers/pci/controller/pci-hyperv.c:2535: warning: Function parameter or member 'num_version' not described in 'hv_pci_protocol_negotiation' No change to functionality intended. Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Link: https://lore.kernel.org/r/20200925234753.1767227-1-kw@linux.com Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-09-21PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORYMatthew Rosato1-0/+1
For VFs, the Memory Space Enable bit in the Command Register is hard-wired to 0. Add a new bit to signify devices where the Command Register Memory Space Enable bit does not control the device's response to MMIO accesses. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-09-21PCI: layerscape: Add EP mode support for ls1088a and ls2088aXiaowei Bao1-19/+53
Add PCIe EP mode support for ls1088a and ls2088a, there are some difference between LS1 and LS2 platform, so refactor the code of the EP driver. Link: https://lore.kernel.org/r/20200918080024.13639-10-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-09-21PCI: layerscape: Modify the MSIX to the doorbell modeXiaowei Bao1-1/+2
dw_pcie_ep_raise_msix_irq was never called in the exisitng driver before, because the ls1046a platform don't support the MSIX feature and msix_capable was always set to false. Now that add the ls1088a platform with MSIX support, use the doorbell method to support the MSIX feature. Link: https://lore.kernel.org/r/20200918080024.13639-9-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2020-09-21PCI: layerscape: Modify the way of getting capability with different PEXXiaowei Bao1-8/+23
The different PCIe controller in one board may be have different capability of MSI or MSIX, so change the way of getting the MSI capability, make it more flexible. Link: https://lore.kernel.org/r/20200918080024.13639-8-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-09-21PCI: layerscape: Fix some format issue of the codeXiaowei Bao1-2/+2
Fix some format issue of the code in EP driver. Link: https://lore.kernel.org/r/20200918080024.13639-7-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2020-09-21PCI: designware-ep: Modify MSI and MSIX CAP way of findingXiaowei Bao2-21/+118
Each PF of EP device should have its own MSI or MSIX capabitily struct, so create a dw_pcie_ep_func struct and move the msi_cap and msix_cap to this struct from dw_pcie_ep, and manage the PFs via a list. Link: https://lore.kernel.org/r/20200918080024.13639-5-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-09-21PCI: designware-ep: Move the function of getting MSI capability forwardXiaowei Bao1-4/+4
Move the function of getting MSI capability to the front of init function, because the init function of the EP platform driver will use the return value by the function of getting MSI capability. Link: https://lore.kernel.org/r/20200918080024.13639-4-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2020-09-21PCI: designware-ep: Add the doorbell mode of MSI-X in EP modeXiaowei Bao2-0/+31
Add the doorbell mode of MSI-X in DWC EP driver. Link: https://lore.kernel.org/r/20200918080024.13639-3-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2020-09-21PCI: designware-ep: Add multiple PFs support for DWCXiaowei Bao3-59/+143
Add multiple PFs support for DWC, due to different PF have different config space, we use func_conf_select callback function to access the different PF's config space, the different chip company need to implement this callback function when use the DWC IP core and intend to support multiple PFs feature. Link: https://lore.kernel.org/r/20200918080024.13639-2-Zhiqiang.Hou@nxp.com Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2020-09-18PCI: Simplify pci_dev_reset_slot_function()Lukas Wunner1-7/+1
pci_dev_reset_slot_function() refuses to reset a hotplug slot if it is shared by multiple pci_devs. That's the case if and only if the slot is occupied by a multifunction device. Simplify the function to check the device's multifunction flag instead of iterating over the devices on the bus. (Iterating over the devices requires holding pci_bus_sem, which the function erroneously does not acquire.) Link: https://lore.kernel.org/r/c6aab5af096f7b1b3db57f6335cebba8f0fcca89.1595330431.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Alex Williamson <alex.williamson@redhat.com>
2020-09-18PCI: pciehp: Reduce noisiness on hot removalLukas Wunner4-14/+17
When a PCIe card is hot-removed, the Presence Detect State and Data Link Layer Link Active bits often do not clear simultaneously. I've seen delays of up to 244 msec between the two events with Thunderbolt. After pciehp has brought down the slot in response to the first event, the other bit may still be set. It's not discernible whether it's set because a new card is already in the slot or if it will soon clear. So pciehp tries to bring up the slot and in the latter case fails with a bunch of messages, some of them at KERN_ERR severity. If the slot is no longer occupied, the messages are false positives and annoy users. Stuart Hayes reports the following splat on hot removal: KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Link Up KERN_INFO pcieport 0000:3c:06.0: pciehp: Timeout waiting for Presence Detect KERN_ERR pcieport 0000:3c:06.0: pciehp: link training error: status 0x0001 KERN_ERR pcieport 0000:3c:06.0: pciehp: Failed to check link status Dongdong Liu complains about a similar splat: KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Link Down KERN_INFO iommu: Removing device 0000:87:00.0 from group 12 KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Card present KERN_INFO pcieport 0000:80:10.0: Data Link Layer Link Active not set in 1000 msec KERN_ERR pciehp 0000:80:10.0:pcie004: Failed to check link status Users are particularly irritated to see a bringup attempt even though the slot was explicitly brought down via sysfs. In a perfect world, we could avoid this by setting Link Disable on slot bringdown and re-enabling it upon a Presence Detect State change. In reality however, there are broken hotplug ports which hardwire Presence Detect to zero, see 80696f991424 ("PCI: pciehp: Tolerate Presence Detect hardwired to zero"). Conversely, PCIe r1.0 hotplug ports hardwire Link Active to zero because Link Active Reporting wasn't specified before PCIe r1.1. On unplug, some ports first clear Presence then Link (see Stuart Hayes' splat) whereas others use the inverse order (see Dongdong Liu's splat). To top it off, there are hotplug ports which flap the Presence and Link bits on slot bringup, see 6c35a1ac3da6 ("PCI: pciehp: Tolerate initially unstable link"). pciehp is designed to work with all of these variants. Surplus attempts at slot bringup are a lesser evil than not being able to bring up slots at all. Although we could try to perfect the behavior for specific hotplug controllers, we'd risk breaking others or increasing code complexity. But we can certainly minimize annoyance by emitting only a single message with KERN_INFO severity if bringup is unsuccessful: * Drop the "Timeout waiting for Presence Detect" message in pcie_wait_for_presence(). The sole caller of that function, pciehp_check_link_status(), ignores the timeout and carries on. It emits error messages of its own and I don't think this particular message adds much value. * There's a single error condition in pciehp_check_link_status() which does not emit a message. Adding one allows dropping the "Failed to check link status" message emitted by board_added() if pciehp_check_link_status() returns a non-zero integer. * Tone down all messages in pciehp_check_link_status() to KERN_INFO severity and rephrase them to look as innocuous as possible. To this end, move the message emitted by pcie_wait_for_link_delay() to its callers. As a result, Stuart Hayes' splat becomes: KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Link Up KERN_INFO pcieport 0000:3c:06.0: pciehp: Slot(180): Cannot train link: status 0x0001 Dongdong Liu's splat becomes: KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): Card present KERN_INFO pciehp 0000:80:10.0:pcie004: Slot(36): No link The messages now merely serve as information that presence or link bits were set a little longer than expected. Bringup failures which are not false positives are still reported, albeit no longer at KERN_ERR severity. Link: https://lore.kernel.org/linux-pci/20200310182100.102987-1-stuart.w.hayes@gmail.com/ Link: https://lore.kernel.org/linux-pci/1547649064-19019-1-git-send-email-liudongdong3@huawei.com/ Link: https://lore.kernel.org/r/b45e46fd8a6aa6930aaac9d7718c2e4b787a4e5e.1595935071.git.lukas@wunner.de Reported-by: Stuart Hayes <stuart.w.hayes@gmail.com> Reported-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-09-18PCI: rpadlpar: Use for_each_child_of_node() and for_each_node_by_name()Qinglang Miao1-4/+4
Use for_each_child_of_node() and for_each_node_by_name() macros instead of open coding them. Link: https://lore.kernel.org/r/20200916062128.190819-1-miaoqinglang@huawei.com Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-17PCI: Update mmap-related #ifdef commentsClint Sbisa1-2/+2
f719582435af ("PCI: Add pci_mmap_resource_range() and use it for ARM64") changed the #ifdef condition around pci_create_resource_files(), pci_remove_resource_files(), and related functions, but did not update comments at the #else and #ifdef. Update the comments to match the #ifdef. [bhelgaas: commit log, drop #endif comment since it's close to the #else] Link: https://lore.kernel.org/r/20200821155121.nzxjeeoze4h5pone@amazon.com Signed-off-by: Clint Sbisa <csbisa@amazon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-17PCI/LINK: Print IRQ number used by portDongdong Liu1-0/+3
Print the IRQ used by PCIe Link Bandwidth Notification services port as AER, PME and DPC do. It provides convenience to track PCIe BW notification interrupt counts of certain port from /proc/interrupts. The dmesg log is as below: pcieport 0000:00:00.0: bw_notification: enabled with IRQ 1166 Link: https://lore.kernel.org/r/1599737055-73624-1-git-send-email-liudongdong3@huawei.com Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-17PCI/IOV: Simplify pci-pf-stub with module_pci_driver()Liu Shixin1-13/+1
Use the module_pci_driver() macro to make the code simpler by eliminating module_init() and module_exit() calls. Link: https://lore.kernel.org/r/20200917071042.1909191-1-liushixin2@huawei.com Signed-off-by: Liu Shixin <liushixin2@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
2020-09-17PCI/ACPI: Add Ampere Altra SOC MCFG quirkTuan Phan1-0/+10
Ampere Altra SOC supports only 32-bit ECAM reads. Add an MCFG quirk for the platform. Link: https://lore.kernel.org/r/1596751055-12316-1-git-send-email-tuanphan@os.amperecomputing.com Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-17PCI: Add schedule point in pci_read_config()Jiang Biao1-0/+1
The PCI sysfs "config" file allows large reads, and the resulting PCI config reads can take several milliseconds to complete. Testing with the cyclictest [1] benchmark showed 5ms+ latencies. Add a schedule point in pci_read_config() to reduce the maximum latency. [1] https://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20200824052025.48362-1-benbjiang@tencent.com Reported-by: Bin Lai <robinlai@tencent.com> Signed-off-by: Jiang Biao <benbjiang@tencent.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-17PCI: brcmstb: Add bcm7278 PERST# supportJim Quinlan1-28/+69
The PERST# bit was moved to a different register in 7278-type STB chips. In addition, the polarity of the bit was also changed; for other chips writing a 1 specified assert; for 7278-type chips, writing a 0 specifies assert. Of course, PERST# is a PCIe asserted-low signal. While we are here, also change the bridge_sw_init_set() functions so like the perst_set() functions they are chip specific and we no longer rely on data wrt chip specific field mask and shift values. Link: https://lore.kernel.org/r/20200911175232.19016-6-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-17PCI: brcmstb: Add suspend and resume pm_opsJim Quinlan1-0/+47
Broadcom Set-top (BrcmSTB) boards typically support S2, S3, and S5 suspend and resume. Now the PCIe driver may do so as well. Link: https://lore.kernel.org/r/20200911175232.19016-5-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-17PCI: brcmstb: Add bcm7278 register infoJim Quinlan1-12/+93
Add in compatibility strings and code for three Broadcom STB chips. Some of the register locations, shifts, and masks are different for certain chips, requiring the use of different constants based on of_id. We would like to add the following at this time to the match list but we need to wait until the end of this patchset so that everything works. { .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg }, { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg }, { .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg }, { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg }, Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
2020-09-17PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTBJim Quinlan1-1/+2
Have PCIE_BRCMSTB depend on ARCH_BRCMSTB. Also set the default value to ARCH_BRCMSTB. Link: https://lore.kernel.org/r/20200911175232.19016-2-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-17PCI/ACS: Enable Translation Blocking for external devicesRajat Jain2-0/+14
Translation Blocking is a required feature for Downstream Ports (Root Ports or Switch Downstream Ports) that implement ACS. When enabled, the Port checks the Address Type (AT) of each upstream Memory Request it receives. The default AT (00b) means "untranslated" and the IOMMU can decide whether to treat the address as I/O virtual or physical. If AT is not the default, i.e., if the Memory Request contains an already-translated (physical) address, the Port blocks the request and reports an ACS error. When enabling ACS, enable Translation Blocking for external-facing ports and untrusted (external) devices. This is to help prevent attacks from external devices that initiate DMA with physical addresses that bypass the IOMMU. [bhelgaas: commit log, simplify setting bit and drop warning; TB is required for Downstream Ports with ACS, so we should never see the warning] Link: https://lore.kernel.org/r/20200707224604.3737893-4-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-16PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectableThomas Gleixner3-1/+8
The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture requires them or not. Architectures which are fully utilizing hierarchical irq domains should never call into that code. It's not only architectures which depend on that by implementing one or more of the weak functions, there is also a bunch of drivers which relies on the weak functions which invoke msi_controller::setup_irq[s] and msi_controller::teardown_irq. Make the architectures and drivers which rely on them select them in Kconfig and if not selected replace them by stub functions which emit a warning and fail the PCI/MSI interrupt allocation. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112333.992429909@linutronix.de
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-19 04:17:37 +0300