summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2020-09-17PCI: Simplify pci_dev_reset_slot_function()Lukas Wunner
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-17PCI: pciehp: Reduce noisiness on hot removalLukas Wunner
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-17PCI: rpadlpar: Use for_each_child_of_node() and for_each_node_by_name()Qinglang Miao
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 Sbisa
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 Liu
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 Shixin
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 Phan
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 Biao
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 Quinlan
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 Quinlan
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 Quinlan
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 Quinlan
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-16PCI/ACS: Enable Translation Blocking for external devicesRajat Jain
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 Gleixner
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
2020-09-16PCI/MSI: Provide pci_dev_has_special_msi_domain() helperThomas Gleixner
Provide a helper function to check whether a PCI device is handled by a non-standard PCI/MSI domain. This will be used to exclude such devices which hang of a special bus, e.g. VMD, to be excluded from the irq domain override in irq remapping. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20200826112333.139387358@linutronix.de
2020-09-16PCI_vmd_Mark_VMD_irqdomain_with_DOMAIN_BUS_VMD_MSIThomas Gleixner
Devices on the VMD bus use their own MSI irq domain, but it is not distinguishable from regular PCI/MSI irq domains. This is required to exclude VMD devices from getting the irq domain pointer set by interrupt remapping. Override the default bus token. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200826112333.047315047@linutronix.de
2020-09-16x86/msi: Use generic MSI domain opsThomas Gleixner
pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the generic MSI domain ops in the core and PCI MSI code unconditionally and get rid of the x86 specific implementations in the X86 MSI code and in the hyperv PCI driver. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200826112332.564274859@linutronix.de
2020-09-16x86/msi: Consolidate MSI allocationThomas Gleixner
Convert the interrupt remap drivers to retrieve the pci device from the msi descriptor and use info::hwirq. This is the first step to prepare x86 for using the generic MSI domain ops. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Wei Liu <wei.liu@kernel.org> Acked-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200826112332.466405395@linutronix.de
2020-09-16PCI/MSI: Rework pci_msi_domain_calc_hwirq()Thomas Gleixner
Retrieve the PCI device from the msi descriptor instead of doing so at the call sites. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200826112332.352583299@linutronix.de
2020-09-16PCI: vmd: Dont abuse vector irqomain as parentThomas Gleixner
VMD has it's own PCI/MSI interrupt domain which is not in any way depending on the x86 vector domain. PCI devices behind VMD share the VMD MSIX vector entries via a VMD specific message translation to the actual VMD MSIX vector. The VMD device interrupt handler for the VMD MSIX vectors invokes all interrupt handlers of the devices which share a vector. Making the x86 vector domain the actual parent of the VMD irq domain is pointless and actually counterproductive. When a device interrupt is requested then it will activate the interrupt which traverses down the hierarchy and consumes an interrupt vector in the vector domain which is never used. The domain is self contained and has no parent dependencies, so just hand in NULL for the parent and be done with it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112330.928952181@linutronix.de
2020-09-16PCI: hip: Add handling of HiSilicon HIP PCIe controller errorsYicong Yang
The HiSilicon HIP PCIe controller is capable of handling errors on root port and performing port reset separately at each root port. Add error handling driver for HIP PCIe controller to log and report recoverable errors. Perform root port reset and restore link status after the recovery. Following are some of the PCIe controller's recoverable errors 1. completion transmission timeout error. 2. CRS retry counter over the threshold error. 3. ECC 2 bit errors 4. AXI bresponse/rresponse errors etc. The driver placed in the drivers/pci/controller/ because the HIP PCIe controller does not use DWC IP. Link: https://lore.kernel.org/r/20200903123456.1823-3-shiju.jose@huawei.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-09-10PCI: dwc: Use DBI accessorsRob Herring
Convert the remaining cases of register accesses using dbi_base rather than dw_pcie_(read|write)[bwl]_dbi accessors. Link: https://lore.kernel.org/r/20200821035420.380495-41-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Pratyush Anand <pratyush.anand@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org
2020-09-10PCI: dwc: Move N_FTS setup to common setupRob Herring
The Designware controller has common registers to set number of fast training sequence ordered sets. The Artpec6, Intel, and Tegra driver initialize these register fields. Let's move the initialization to the common setup code and drivers just have to provide the value. There's a slight change in that the common clock mode N_FTS field is now initialized. Previously only the Intel driver set this. It's not clear from the code if common clock mode is used in the Artpec6 or Tegra driver. It depends on the DWC configuration. Given the field is not initialized while the others are, it seems unlikely common clock mode is used. Link: https://lore.kernel.org/r/20200821035420.380495-40-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org
2020-09-10PCI: dwc/intel-gw: Drop unused max_widthRob Herring
'max_width' is read, but never used, so let's remove it. Link: https://lore.kernel.org/r/20200821035420.380495-39-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Dilip Kota <eswara.kota@linux.intel.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-10PCI: dwc/intel-gw: Move getting PCI_CAP_ID_EXP offset to intel_pcie_link_setup()Rob Herring
The PCI_CAP_ID_EXP offset is only needed by intel_pcie_link_setup(), so let's retrieve it there and avoid storing the offset. Link: https://lore.kernel.org/r/20200821035420.380495-38-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Dilip Kota <eswara.kota@linux.intel.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-10PCI: dwc/intel-gw: Drop unnecessary checking of DT 'device_type' propertyRob Herring
A driver doesn't need to check for DT 'device_type' property, so let's remove the check. Link: https://lore.kernel.org/r/20200821035420.380495-37-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Dilip Kota <eswara.kota@linux.intel.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-10PCI: dwc: Set PORT_LINK_DLL_LINK_EN in common setup codeRob Herring
The Intel driver is the only one to set PORT_LINK_DLL_LINK_EN. The default value is set and it seems pretty certain that enabling link initialization is always required. Maybe it could just be dropped from the Intel driver, but lets move setting it into the common code to be sure. Link: https://lore.kernel.org/r/20200821035420.380495-36-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Dilip Kota <eswara.kota@linux.intel.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-10PCI: dwc: Centralize link gen settingRob Herring
keystone would force gen2 if no DT property. Now it relies on the PCI_EXP_LNKCAP value. Link: https://lore.kernel.org/r/20200821035420.380495-35-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Stanimir Varbanov <svarbanov@mm-sol.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Pratyush Anand <pratyush.anand@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-omap@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: linux-tegra@vger.kernel.org
2020-09-08PCI: rockchip: Fix bus checks in rockchip_pcie_valid_device()Lorenzo Pieralisi
The root bus checks rework in d84c572de1a3 ("PCI: rockchip: Use pci_is_root_bus() to check if bus is root bus") caused a regression whereby in rockchip_pcie_valid_device() if the bus parameter is the root bus and the dev value == 0, the function should return 1 (ie true) without checking if the bus->parent pointer is a root bus because that triggers a NULL pointer dereference. Fix this by streamlining the root bus detection. Fixes: d84c572de1a3 ("PCI: rockchip: Use pci_is_root_bus() to check if bus is root bus") Link: https://lore.kernel.org/r/20200904140904.944-1-lorenzo.pieralisi@arm.com Reported-by: Samuel Dionne-Riel <samuel@dionne-riel.com> Tested-by: Samuel Dionne-Riel <samuel@dionne-riel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Shawn Lin <shawn.lin@rock-chips.com>
2020-09-08PCI: iproc: Set affinity mask on MSI interruptsMark Tomlinson
The core interrupt code expects the irq_set_affinity call to update the effective affinity for the interrupt. This was not being done, so update iproc_msi_irq_set_affinity() to do so. Link: https://lore.kernel.org/r/20200803035241.7737-1-mark.tomlinson@alliedtelesis.co.nz Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support") Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
2020-09-08PCI: mvebu: Remove useless msi_controller pointer allocationLorenzo Pieralisi
The mvebu host controller driver allocates an msi_controller structure pointer without allocating the structure and initializing its methods, which makes the pointer useless. This means that the PCI IRQ MSI layer ignores it and that after all it should not really be needed. Remove it. Link: https://lore.kernel.org/r/20200904142132.6054-1-lorenzo.pieralisi@arm.com Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-09-08PCI: dwc: Make ATU accessors privateRob Herring
The ATU registers are only accessed in pcie-designware.c and can be private to it. Link: https://lore.kernel.org/r/20200821035420.380495-34-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-08PCI: dwc: Remove read_dbi2 codeRob Herring
The DBI2 appears to be write-only and there's no read accesses in the code anyways, so let's remove all the read_dbi2 related code. Link: https://lore.kernel.org/r/20200821035420.380495-33-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2020-09-08PCI: dwc/tegra: Use common Designware port logic register definitionsRob Herring
The Tegra driver has its own defines for common Designware Port Logic registers. Convert it to use the standard register definitions. Link: https://lore.kernel.org/r/20200821035420.380495-32-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org
2020-09-08PCI: dwc: Remove hardcoded PCI_CAP_ID_EXP offsetRob Herring
While the Designware controller appears to hard code the PCI_CAP_ID_EXP capability register at 0x70, there's no need to hard code this in the driver as it is discoverable. Link: https://lore.kernel.org/r/20200821035420.380495-31-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Pratyush Anand <pratyush.anand@gmail.com> Cc: linux-omap@vger.kernel.org
2020-09-08PCI: dwc/qcom: Use common PCI register definitionsRob Herring
The QCom driver has its own defines for common PCI config space registers. It also hard codes the capability register offsets which are discoverable. Convert it to use the standard register definitions. Link: https://lore.kernel.org/r/20200821035420.380495-30-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Stanimir Varbanov <svarbanov@mm-sol.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-arm-msm@vger.kernel.org
2020-09-08PCI: dwc/imx6: Use common PCI register definitionsRob Herring
The i.MX6 driver has its own defines for common PCI config space registers. It also hard codes the capability register offsets which are discoverable. Convert it to use the standard register definitions. Link: https://lore.kernel.org/r/20200821035420.380495-29-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com>
2020-09-08PCI: dwc/meson: Rework PCI config and DW port logic register accessesRob Herring
The meson 'elbi' registers are just the Designware 'dbi' space and all the registers accessed are either standard PCI config space or DWC port logic registers. Convert the accesses to use the common defines and register accessors. Link: https://lore.kernel.org/r/20200821035420.380495-28-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Yue Wang <yue.wang@Amlogic.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: linux-amlogic@lists.infradead.org
2020-09-08PCI: dwc/meson: Drop unnecessary RC config space initializationRob Herring
The common Designware init already initializes the RC PCI_COMMAND, BAR0 and BAR1 registers. The only difference here is the common code sets SERR. If clearing SERR is what's desired, then the Meson driver should do that instead. Link: https://lore.kernel.org/r/20200821035420.380495-27-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Yue Wang <yue.wang@Amlogic.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org
2020-09-08PCI: dwc/meson: Drop the duplicate number of lanes setupRob Herring
The meson lanes initialization is the same DWC port logic registers as in dw_pcie_setup(). We just need to initialize 'num_lanes' to 1 to do the same init. dw_pcie_setup_rc() sets the PORT_LOGIC_SPEED_CHANGE bit, so setting it can be dropped. Link: https://lore.kernel.org/r/20200821035420.380495-26-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Yue Wang <yue.wang@Amlogic.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: linux-amlogic@lists.infradead.org
2020-09-08PCI: dwc: Ensure FAST_LINK_MODE is clearedRob Herring
"Fast Link Mode" is a simulation environment speed up setting which should never be set and the default is not set. However some Amlogic platforms have it set (by firmware presumably). See commit 87dccf09323f ("PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link") for more information. Let's clear it in core DWC code so we can drop some vendor specific code. Link: https://lore.kernel.org/r/20200821035420.380495-25-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-08PCI: dwc: Add a 'num_lanes' field to struct dw_pcieRob Herring
Add a 'num_lanes' field to allow drivers to provide a the number of lanes if not in DT or using a custom DT property. A driver can provide a non-zero value which is used if the DT doesn't have a 'num-lanes' property. Link: https://lore.kernel.org/r/20200821035420.380495-24-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-08PCI: dwc/imx6: Remove duplicate define PCIE_LINK_WIDTH_SPEED_CONTROLRob Herring
PCIE_LINK_WIDTH_SPEED_CONTROL is already defined in pcie-designware.h, so remove it from the i.MX6 driver. Link: https://lore.kernel.org/r/20200821035420.380495-23-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com>
2020-09-08PCI: dwc: Check CONFIG_PCI_MSI inside dw_pcie_msi_init()Rob Herring
Move the IS_ENABLED(CONFIG_PCI_MSI) check into dw_pcie_msi_init() instead of duplicating it in all the drivers. Link: https://lore.kernel.org/r/20200821035420.380495-22-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Yue Wang <yue.wang@Amlogic.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Xiaowei Song <songxiaowei@hisilicon.com> Cc: Binghui Wang <wangbinghui@hisilicon.com> Cc: Stanimir Varbanov <svarbanov@mm-sol.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@axis.com Cc: linux-arm-msm@vger.kernel.org
2020-09-08PCI: dwc/keystone: Drop duplicated 'num-viewport'Rob Herring
The DWC core driver already parses and stores the 'num-viewport' DT property, so there is no need for the Keystone driver to store it. Link: https://lore.kernel.org/r/20200821035420.380495-21-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-08PCI: dwc: Simplify config space handlingRob Herring
The config space is divided in half for type 0 and type 1 accesses, but this is pointless as there's only one iATU window which is reconfigured on each access. The only platform doing something custom is TI Keystone (surprise!). It does its own mapping of the config space to avoid spliting the config space and never actually uses va_cfg1_base as it has its own config space accessors. With the splitting removed, Keystone can use the default mapping of config space. Link: https://lore.kernel.org/r/20200821035420.380495-20-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2020-09-08PCI: dwc: Remove storing of PCI resourcesRob Herring
The PCI bridge resources are stored in pci_host_bridge.windows, so there's no need to store them in a DWC specific struct. There's also no need to parse the resources and store them a 2nd time as they are mainly used for one time setup of iATU windows. Link: https://lore.kernel.org/r/20200821035420.380495-19-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Jonathan Chocron <jonnyc@amazon.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2020-09-08PCI: dwc: Remove root_bus pointerRob Herring
The pci_host_bridge struct already has a pointer to its pci_bus, so let's convert the one user to use the bridge struct and remove the private 'root_bus' pointer. Link: https://lore.kernel.org/r/20200821035420.380495-18-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org
2020-09-08PCI: dwc: Convert to use pci_host_probe()Rob Herring
Now that there are no more .scan_bus() callbacks, we can remove it and just use pci_host_probe(). Link: https://lore.kernel.org/r/20200821035420.380495-17-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2020-09-08PCI: dwc: keystone: Convert .scan_bus() callback to use add_busRob Herring
TI keystone is the only Designware driver using .scan_bus(). This function pointer is the only thing preventing the Designware driver from using pci_host_probe(). Let's use the pci_ops.add_bus hook instead. Link: https://lore.kernel.org/r/20200821035420.380495-16-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>