summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-28PCI/ERR: Update error status after reset_link()Kuppuswamy Sathyanarayanan
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") uses reset_link() to recover from fatal errors. But during fatal error recovery, if the initial value of error status is PCI_ERS_RESULT_DISCONNECT or PCI_ERS_RESULT_NO_AER_DRIVER then even after successful recovery (using reset_link()) pcie_do_recovery() will report the recovery result as failure. Update the status of error after reset_link(). You can reproduce this issue by triggering a SW DPC using "DPC Software Trigger" bit in "DPC Control Register". You should see recovery failed dmesg log as below: pcieport 0000:00:16.0: DPC: containment event, status:0x1f27 source:0x0000 pcieport 0000:00:16.0: DPC: software trigger detected pci 0000:04:00.0: AER: can't recover (no error_detected callback) pcieport 0000:00:16.0: AER: device recovery failed Fixes: bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") Link: https://lore.kernel.org/r/a255fcb3a3fdebcd90f84e08b555f1786eb8eba2.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com [bhelgaas: split pci_channel_io_frozen simplification to separate patch] Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Keith Busch <keith.busch@intel.com> Cc: Ashok Raj <ashok.raj@intel.com>
2020-03-28PCI/ERR: Combine pci_channel_io_frozen casesKuppuswamy Sathyanarayanan
pcie_do_recovery() had two "if (state == pci_channel_io_frozen)" cases right after each other. Combine them to make this easier to read. No functional change intended. Link: https://lore.kernel.org/r/20200317170654.GA23125@infradead.org [bhelgaas: split from https://lore.kernel.org/r/a255fcb3a3fdebcd90f84e08b555f1786eb8eba2.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com] Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-27PCI: dwc: pci-dra7xx: Fix MSI IRQ handlingVignesh Raghavendra
Due to an issue with PCIe wrapper logic built for the DWC PCIe IP on dra7xx, the driver needs to ensure that there are no pending MSI IRQ vector set (i.e PCIE_MSI_INTR0_STATUS reads 0 at least once) before exiting IRQ handler otherwise the dra7xx PCIe wrapper will not register new MSI IRQs even though PCIE_MSI_INTR0_STATUS reports IRQs are pending. Therefore it's no longer possible to use default IRQ handler provided by DWC library. Add an irqchip implementation inside pci-dra7xx.c and install new MSI IRQ handler to handle the above errata. This fixes a bug, where PCIe wifi cards with 4 DMA queues like Intel 8260 used to throw following error and stall during ping/iperf3 tests. [ 97.776310] iwlwifi 0000:01:00.0: Queue 9 stuck for 2500 ms. Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-20dt-bindings: PCI: Convert PCIe Host/Endpoint in Cadence platform to DT schemaKishon Vijay Abraham I
Include Cadence core DT schema and define the Cadence platform DT schema for both Host and Endpoint mode. Note: The Cadence core DT schema could be included for other platforms using Cadence PCIe core. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-03-20dt-bindings: PCI: cadence: Add PCIe RC/EP DT schema for Cadence PCIeKishon Vijay Abraham I
Add PCIe Host (RC) and Endpoint (EP) device tree schema for Cadence PCIe core library. Platforms using Cadence PCIe core can include the schemas added here in the platform specific schemas. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-03-20dt-bindings: PCI: Add PCI Endpoint Controller SchemaKishon Vijay Abraham I
Define a common schema for PCI Endpoint Controllers. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-03-19PCI: Avoid ASMedia XHCI USB PME# from D0 defectKai-Heng Feng
The ASMedia USB XHCI Controller claims to support generating PME# while in D0: 01:00.0 USB controller: ASMedia Technology Inc. Device 2142 (prog-if 30 [XHCI]) Subsystem: SUNIX Co., Ltd. Device 312b Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME- However PME# only gets asserted when plugging USB 2.0 or USB 1.1 devices, but not for USB 3.0 devices. Remove PCI_PM_CAP_PME_D0 to avoid using PME under D0. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205919 Link: https://lore.kernel.org/r/20191219192006.16270-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-18PCI/P2PDMA: Add Intel Sky Lake-E Root Ports B, C, D to the whitelistAndrew Maier
Add the three remaining Intel Sky Lake-E host Root Ports to the whitelist of p2pdma. P2P has been tested and is working on this system. Link: https://lore.kernel.org/r/20200207221219.4309-1-andrew.maier@eideticom.com Signed-off-by: Andrew Maier <andrew.maier@eideticom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2020-03-18PCI/ASPM: Clear the correct bits when enabling L1 substatesYicong Yang
In pcie_config_aspm_l1ss(), we cleared the wrong bits when enabling ASPM L1 Substates. Instead of the L1.x enable bits (PCI_L1SS_CTL1_L1SS_MASK, 0xf), we cleared the Link Activation Interrupt Enable bit (PCI_L1SS_CAP_L1_PM_SS, 0x10). Clear the L1.x enable bits before writing the new L1.x configuration. [bhelgaas: changelog] Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings") Link: https://lore.kernel.org/r/1584093227-1292-1-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.11+
2020-03-18PCI: mobiveil: Fix unmet dependency warning for PCIE_MOBIVEIL_PLATHou Zhiqiang
Fix the following warning by adding the dependency PCI_MSI_IRQ_DOMAIN to PCIE_MOBIVEIL_PLAT. WARNING: unmet direct dependencies detected for PCIE_MOBIVEIL_HOST Depends on [n]: PCI [=y] && PCI_MSI_IRQ_DOMAIN [=n] Selected by [y]: - PCIE_MOBIVEIL_PLAT [=y] && PCI [=y] && (ARCH_ZYNQMP || COMPILE_TEST [=y]) && OF [=y] Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-03-17PCI: mobiveil: Fix sparse different address space warningsHou Zhiqiang
Fix the sparse warnings below: drivers/pci/controller/mobiveil/pcie-mobiveil.c:44:49: warning: incorrect type in return expression (different address spaces) drivers/pci/controller/mobiveil/pcie-mobiveil.c:44:49: expected void * drivers/pci/controller/mobiveil/pcie-mobiveil.c:44:49: got void [noderef] <asn:2> * drivers/pci/controller/mobiveil/pcie-mobiveil.c:48:41: warning: incorrect type in return expression (different address spaces) drivers/pci/controller/mobiveil/pcie-mobiveil.c:48:41: expected void * drivers/pci/controller/mobiveil/pcie-mobiveil.c:48:41: got void [noderef] <asn:2> * drivers/pci/controller/mobiveil/pcie-mobiveil.c:106:34: warning: incorrect type in argument 1 (different address spaces) drivers/pci/controller/mobiveil/pcie-mobiveil.c:106:34: expected void [noderef] <asn:2> *addr drivers/pci/controller/mobiveil/pcie-mobiveil.c:106:34: got void *[assigned] addr drivers/pci/controller/mobiveil/pcie-mobiveil.c:121:35: warning: incorrect type in argument 1 (different address spaces) drivers/pci/controller/mobiveil/pcie-mobiveil.c:121:35: expected void [noderef] <asn:2> *addr drivers/pci/controller/mobiveil/pcie-mobiveil.c:121:35: got void *[assigned] addr Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reported-by: kbuild test robot <lkp@intel.com>
2020-03-11dt-bindings: PCI: tegra: Add DT support for PCIe EP nodes in Tegra194Vidya Sagar
Add support for PCIe controllers that can operate in endpoint mode in Tegra194. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com>
2020-03-11soc/tegra: bpmp: Update ABI headerVidya Sagar
Update the firmware header to support uninitialization of UPHY PLL when the PCIe controller is operating in endpoint mode and host cuts the PCIe reference clock. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thierry Reding <treding@nvidia.com>
2020-03-10PCI: Add PCIE_LNKCAP2_SLS2SPEED() macroYicong Yang
Add PCIE_LNKCAP2_SLS2SPEED macro for transforming raw Link Capabilities 2 values to the pci_bus_speed. This is next to PCIE_SPEED2MBS_ENC() to make it easier to update both places when adding support for new speeds. Link: https://lore.kernel.org/r/1581937984-40353-10-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-10PCI: Use pci_speed_string() for all PCI/PCI-X/PCIe stringsBjorn Helgaas
Previously some PCI speed strings came from pci_speed_string(), some came from the PCIe-specific PCIE_SPEED2STR(), and some came from a PCIe-specific switch statement. These methods were inconsistent: pci_speed_string() PCIE_SPEED2STR() switch ------------------ ---------------- ------ 33 MHz PCI ... 2.5 GT/s PCIe 2.5 GT/s 2.5 GT/s 5.0 GT/s PCIe 5 GT/s 5 GT/s 8.0 GT/s PCIe 8 GT/s 8 GT/s 16.0 GT/s PCIe 16 GT/s 16 GT/s 32.0 GT/s PCIe 32 GT/s 32 GT/s Standardize on pci_speed_string() as the single source of these strings. Note that this adds ".0" and "PCIe" to some messages, including sysfs "max_link_speed" files, a brcmstb "link up" message, and the link status dmesg logging, e.g., nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) I think it's better to standardize on a single version of the speed text. Previously we had strings like this: /sys/bus/pci/slots/0/cur_bus_speed: 8.0 GT/s PCIe /sys/bus/pci/slots/0/max_bus_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8 GT/s /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8 GT/s This changes the latter two to match the slots files: /sys/devices/pci0000:00/0000:00:1c.0/current_link_speed: 8.0 GT/s PCIe /sys/devices/pci0000:00/0000:00:1c.0/max_link_speed: 8.0 GT/s PCIe Based-on-patch by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-10PCI: Add pci_speed_string()Bjorn Helgaas
Add pci_speed_string() to return a text description of the supplied bus or link speed. The slot code previously used the private pci_bus_speed_strings[] array for this purpose, but adding this interface will enable us to consolidate similar code elsewhere. Export pcie_link_speed[] and pci_speed_string() so they can be used by modules. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-09Documentation: PCI: Add background on Boot InterruptsSean V Kelley
Improve understanding of the PCI quirks for this legacy PCI interrupt behavior to the benefit of developers and users alike. Link: https://lore.kernel.org/r/20200220192930.64820-3-sean.v.kelley@linux.intel.com Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
2020-03-09PCI: hv: Introduce hv_msi_entryBoqun Feng
Add a new structure (hv_msi_entry), which is also defined in the TLFS, to describe the msi entry for HVCALL_RETARGET_INTERRUPT. The structure is needed because its layout may be different from architecture to architecture. Also add a new generic interface hv_set_msi_entry_from_desc() to allow different archs to set the msi entry from msi_desc. No functional change, only preparation for the future support of virtual PCI on non-x86 architectures. Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Dexuan Cui <decui@microsoft.com>
2020-03-09PCI: hv: Move retarget related structures into tlfs headerBoqun Feng
Currently, retarget_msi_interrupt and other structures it relys on are defined in pci-hyperv.c. However, those structures are actually defined in Hypervisor Top-Level Functional Specification [1] and may be different in sizes of fields or layout from architecture to architecture. Let's move those definitions into x86's tlfs header file to support virtual PCI on non-x86 architectures in the future. Note that "__packed" attribute is added to these structures during the movement for the same reason as we use the attribute for other TLFS structures in the header file: make sure the structures meet the specification and avoid anything unexpected from the compilers. Additionally, rename struct retarget_msi_interrupt to hv_retarget_msi_interrupt for the consistent naming convention, also mirroring the name in TLFS. [1]: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Dexuan Cui <decui@microsoft.com>
2020-03-09PCI: hv: Move hypercall related definitions into tlfs headerBoqun Feng
Currently HVCALL_RETARGET_INTERRUPT and HV_PARTITION_ID_SELF are defined in pci-hyperv.c. However, similar to other hypercall related definitions, it makes more sense to put them in the tlfs header file. Besides, these definitions are arch-dependent, so for the support of virtual PCI on non-x86 archs in the future, move them into arch-specific tlfs header file. Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk> Reviewed-by: Dexuan Cui <decui@microsoft.com>
2020-03-06PCI: hv: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Dexuan Cui <decui@microsoft.com>
2020-03-06PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2Long Li
Starting with Hyper-V PCI protocol version 1.3, the host VSP can send PCI_BUS_RELATIONS2 and pass the vNUMA node information for devices on the bus. The vNUMA node tells which guest NUMA node this device is on based on guest VM configuration topology and physical device information. Add code to negotiate v1.3 and process PCI_BUS_RELATIONS2. Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-03-06PCI: hv: Decouple the func definition in hv_dr_state from VSP messageLong Li
hv_dr_state is used to find present PCI devices on the bus. The structure reuses struct pci_function_description from VSP message to describe a device. To prepare support for pci_function_description v2, decouple this dependence in hv_dr_state so it can work with both v1 and v2 VSP messages. There is no functionality change. Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-03-04PCI: amlogic: Use AXG PCIERemi Pommarel
Now that PCIE PHY has been introduced for AXG, the whole has_shared_phy logic can be mutualized between AXG and G12A platforms. This new PHY makes use of the shared MIPI/PCIE analog PHY found on AXG platforms, which need to be used in order to have reliable PCIE communications. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-04phy: amlogic: Add Amlogic AXG PCIE PHY DriverRemi Pommarel
This adds support for the PCI PHY found in the Amlogic AXG SoC Family. This will allow to mutualize code in pci-meson.c between AXG and G12A SoC. This PHY also uses and chains an analog PHY, which on AXG platform is needed to have reliable PCIe communication. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2020-03-04phy: amlogic: Add Amlogic AXG MIPI/PCIE analog PHY DriverRemi Pommarel
This adds support for the MIPI analog PHY which is also used for PCIE found in the Amlogic AXG SoC Family. MIPI or PCIE selection is done by the #phy-cells, making the mode static and exclusive. For now only PCIE functionality is supported. This PHY will be used to replace the mipi_enable clock gating logic which was mistakenly added in the clock subsystem. This also activates a non documented band gap bit in those registers that allows reliable PCIE clock signal generation on AXG platforms. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com>
2020-03-04dt-bindings: PCI: meson: Update PCIE bindings documentationRemi Pommarel
Now that a new PHYs has been introduced for AXG SoC family, update dt bindings documentation. Please note that this breaks backward compatibility but as not a single devicetree uses that yet that seems ok. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-03-04dt-bindings: Add AXG shared MIPI/PCIE analog PHY bindingsRemi Pommarel
Add documentation for the shared MIPI/PCIE analog PHY found in AXG SoCs. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-03-04dt-bindings: Add AXG PCIE PHY bindingsRemi Pommarel
Add documentation for PCIE PHYs found in AXG SoCs. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-02-28PCI: Add 32 GT/s decoding in some macrosYicong Yang
Link speed 32.0 GT/s is supported in PCIe r5.0. Add this speed to PCIE_SPEED2STR() and PCIE_SPEED2MBS_ENC() to correctly decode it. This is complementary to de76cda215d5 ("PCI: Decode PCIe 32 GT/s link speed"). Link: https://lore.kernel.org/r/1581937984-40353-2-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-02-27PCI: Add boot interrupt quirk mechanism for Xeon chipsetsSean V Kelley
The following was observed by Kar Hin Ong with RT patchset: Backtrace: irq 19: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 3329 Comm: irq/34-nipalk Tainted:4.14.87-rt49 #1 Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020 Call Trace: <IRQ> ? dump_stack+0x46/0x5e ? __report_bad_irq+0x2e/0xb0 ? note_interrupt+0x242/0x290 ? nNIKAL100_memoryRead16+0x8/0x10 [nikal] ? handle_irq_event_percpu+0x55/0x70 ? handle_irq_event+0x4f/0x80 ? handle_fasteoi_irq+0x81/0x180 ? handle_irq+0x1c/0x30 ? do_IRQ+0x41/0xd0 ? common_interrupt+0x84/0x84 </IRQ> ... handlers: [<ffffffffb3297200>] irq_default_primary_handler threaded [<ffffffffb3669180>] usb_hcd_irq Disabling IRQ #19 The problem being that this device is triggering boot interrupts due to threaded interrupt handling and masking of the IO-APIC. These boot interrupts are then forwarded on to the legacy PCH's PIRQ lines where there is no handler present for the device. Whenever a PCI device fires interrupt (INTx) to Pin 20 of IOAPIC 2 (GSI 44), the kernel receives two interrupts: 1. Interrupt from Pin 20 of IOAPIC 2 -> Expected 2. Interrupt from Pin 19 of IOAPIC 1 -> UNEXPECTED Quirks for disabling boot interrupts (preferred) or rerouting the handler exist but do not address these Xeon chipsets' mechanism: https://lore.kernel.org/lkml/12131949181903-git-send-email-sassmann@suse.de/ Add a new mechanism via PCI CFG for those chipsets supporting CIPINTRC register's dis_intx_rout2ich bit. Link: https://lore.kernel.org/r/20200220192930.64820-2-sean.v.kelley@linux.intel.com Reported-by: Kar Hin Ong <kar.hin.ong@ni.com> Tested-by: Kar Hin Ong <kar.hin.ong@ni.com> Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org
2020-02-26PCI: pci-epf-test: Add support to defer core initializationVidya Sagar
Add support to defer core initialization for the endpoint mode of operation. This would enable support for implementations where the core initialization needs to be deferred until the PCIe reference clock is available from the host system. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-25PCI: dwc: Add API to notify core initialization completionVidya Sagar
Add a new API dw_pcie_ep_init_notify() to let platform drivers call it when the core is available for initialization. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-25PCI: endpoint: Add notification for core init completionVidya Sagar
Add support to send notifications to EPF from EPC once the core registers initialization is complete. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-25PCI: dwc: Refactor core initialization code for EP modeVidya Sagar
Split core initialization code for EP mode into two, one that doesn't touch core registers and the other that touches core registers. The latter would be called/skipped based on the EPC feature 'core_init_notifier'. In platforms where this is skipped, it would be called indirectly through hooks from the endpoint function driver. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-25PCI: endpoint: Add core init notifying featureVidya Sagar
Add a new feature core_init_notifier for cores that can notify about their availability for initialization. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-24PCI: hv: Add missing kfree(hbus) in hv_pci_probe()'s error handling pathDexuan Cui
Now that we use kzalloc() to allocate the hbus buffer, we must call kfree() in the error path as well to prevent memory leakage. Fixes: 877b911a5ba0 ("PCI: hv: Avoid a kmemleak false positive caused by the hbus buffer") Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-02-24PCI: hv: Remove unnecessary type casting from kzallocDexuan Cui
In C, there is no need to cast a void * to any other pointer type, remove an unnecessary cast. Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-02-24PCI: endpoint: Assign function number for each PF in EPC coreKishon Vijay Abraham I
The PCIe endpoint core relies on the drivers that invoke the pci_epc_add_epf() API to allocate and assign a function number to each physical function (PF). Since endpoint function device can be created by multiple mechanisms (configfs, devicetree, etc..), allowing each of these mechanisms to assign a function number would result in mutliple endpoint function devices having the same function number. In order to avoid this, let EPC core assign a function number to the endpoint device. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-02-24PCI: endpoint: Protect concurrent access to pci_epf_ops with mutexKishon Vijay Abraham I
Protect concurrent access to pci_epf_ops with a mutex. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-02-24PCI: endpoint: Fix for concurrent memory allocation in OB address regionKishon Vijay Abraham I
pci-epc-mem uses a bitmap to manage the Endpoint outbound (OB) address region. This address region will be shared by multiple endpoint functions (in the case of multi function endpoint) and it has to be protected from concurrent access to avoid updating an inconsistent state. Use a mutex to protect bitmap updates to prevent the memory allocation API from returning incorrect addresses. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org # v4.14+
2020-02-24PCI: endpoint: Replace spinlock with mutexKishon Vijay Abraham I
The pci_epc_ops is not intended to be invoked from interrupt context. Hence replace spin_lock_irqsave and spin_unlock_irqrestore with mutex_lock and mutex_unlock respectively. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-02-24PCI: endpoint: Use notification chain mechanism to notify EPC events to EPFKishon Vijay Abraham I
Use atomic_notifier_call_chain() to notify EPC events like linkup to EPF driver instead of using linkup ops in EPF driver. This is in preparation for adding proper locking mechanism to EPF ops. This will also enable to add more events (in addition to linkup) in the future. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Vidya Sagar <vidyas@nvidia.com>
2020-02-21PCI: mobiveil: Add PCIe Gen4 RC driver for Layerscape SoCsHou Zhiqiang
Add a PCI host controller driver for Layerscape SoCs integrating the Mobiveil GPEX IP. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Minghuan Lian <Minghuan.Lian@nxp.com> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
2020-02-21dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controllerHou Zhiqiang
Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs. 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-02-21PCI: mobiveil: Add Header Type field checkHou Zhiqiang
Check the Header Type and exit from the host driver initialization if it is not in host mode. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
2020-02-21PCI: mobiveil: Add 8-bit and 16-bit CSR register accessorsHou Zhiqiang
There are some 8-bit and 16-bit registers in PCIe configuration space, so add these accessors accordingly. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Minghuan Lian <Minghuan.Lian@nxp.com> Reviewed-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
2020-02-21PCI: mobiveil: Allow mobiveil_host_init() to be used to re-init hostHou Zhiqiang
Allow the mobiveil_host_init() function to be used to re-init host controller's PAB and GPEX CSR register block, since the NXP integrated Mobiveil IP has to reset and then re-init the PAB and GPEX CSR registers upon hot-reset. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
2020-02-21PCI: mobiveil: Add callback function for link up checkHou Zhiqiang
Platforms integrating the Mobiveil GPEX can implement a specific mechanism to check the link status. Add a callback to enable platform specific link status functions. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [lorenzo.pieralisi@arm.com: updated log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2020-02-21PCI: mobiveil: Add callback function for interrupt initializationHou Zhiqiang
The Mobiveil GPEX internal MSI/INTx controller is not implemented in all platforms in which the Mobiveil GPEX is integrated. Allow platforms to implement their specific interrupt initialization. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 06:44:56 +0000