aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2020-03-28PCI/ASPM: Reduce severity of common clock config messageChris Packham1-1/+1
When the UEFI/BIOS or bootloader has not initialised a PCIe device we would get the following message: kern.warning: pci 0000:00:01.0: ASPM: current common clock configuration is broken, reconfiguring "warning" and "broken" are slightly misleading. On an embedded system it is quite possible for the bootloader to avoid configuring PCIe devices if they are not needed. Downgrade the message to pci_info() and change "broken" to "inconsistent" since we fix up the inconsistency in the code immediately following the message (and emit an error if that fails). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chris Packham <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/AER: Rationalize error status register clearingKuppuswamy Sathyanarayanan5-7/+9
The AER interfaces to clear error status registers were a confusing mess: - pci_cleanup_aer_uncorrect_error_status() cleared non-fatal errors from the Uncorrectable Error Status register. - pci_aer_clear_fatal_status() cleared fatal errors from the Uncorrectable Error Status register. - pci_cleanup_aer_error_status_regs() cleared the Root Error Status register (for Root Ports), the Uncorrectable Error Status register, and the Correctable Error Status register. Rename them to make them consistent: From To ---------------------------------------- ------------------------------- pci_cleanup_aer_uncorrect_error_status() pci_aer_clear_nonfatal_status() pci_aer_clear_fatal_status() pci_aer_clear_fatal_status() pci_cleanup_aer_error_status_regs() pci_aer_clear_status() Since pci_cleanup_aer_error_status_regs() (renamed to pci_aer_clear_status()) is only used within drivers/pci/, move the declaration from <linux/aer.h> to drivers/pci/pci.h. [bhelgaas: commit log, add renames] Link: https://lore.kernel.org/r/d1310a75dc3d28f7e8da4e99c45fbd3e60fe238e.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/DPC: Add Error Disconnect Recover (EDR) supportKuppuswamy Sathyanarayanan5-0/+253
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to notify OSPM that a device has been disconnected due to an error condition (ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler should invalidate software state associated with disconnected devices and may attempt to recover them. OSPM communicates the status of recovery to the firmware via _OST (sec 6.3.5.2). For PCIe, firmware may use Downstream Port Containment (DPC) to support EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control of DPC, OSPM may read/write DPC control and status registers during the EDR notification processing window, i.e., from the time it receives an EDR notification until it clears the DPC Trigger Status. Note that per [1], sec 4.5.1 and 4.5.2.4, 1. If the OS supports EDR, it should advertise that to firmware by setting OSC_PCI_EDR_SUPPORT in _OSC Support. 2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in _OSC Support. Add an EDR notify handler to attempt recovery. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 [bhelgaas: squash add/enable patches into one] Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Len Brown <[email protected]>
2020-03-28PCI/DPC: Expose dpc_process_error(), dpc_reset_link() for use by EDRKuppuswamy Sathyanarayanan2-3/+11
If firmware controls DPC, it is generally responsible for managing the DPC capability and events, and the OS should not access the DPC capability. However, if firmware controls DPC and both the OS and the platform support Error Disconnect Recover (EDR) notifications, the OS EDR notify handler is responsible for recovery, and the notify handler may read/write the DPC capability until it clears the DPC Trigger Status bit. See [1], sec 4.5.1, table 4-6. Expose some DPC error handling functions so they can be used by the EDR notify handler. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 Link: https://lore.kernel.org/r/e9000bb15b3a4293e81d98bb29ead7c84a6393c9.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/AER: Add pci_aer_raw_clear_status() to unconditionally clear Error StatusKuppuswamy Sathyanarayanan2-4/+20
Per the SFI _OSC and DPC Updates ECN [1] implementation note flowchart, the OS seems to be expected to clear AER status even if it doesn't have ownership of the AER capability. Unlike the DPC capability, where a DPC ECN [2] specifies a window when the OS is allowed to access DPC registers even if it doesn't have ownership, there is no clear model for AER. Add pci_aer_raw_clear_status() to clear the AER error status registers unconditionally. This is intended for use only by the EDR path (see [2]). [1] System Firmware Intermediary (SFI) _OSC and DPC Updates ECN, Feb 24, 2020, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/14076 [2] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 [bhelgaas: changelog] Link: https://lore.kernel.org/r/c19ad28f3633cce67448609e89a75635da0da07d.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/DPC: Cache DPC capabilities in pci_init_capabilities()Kuppuswamy Sathyanarayanan3-12/+24
Since Error Disconnect Recover needs to use DPC error handling routines even if the OS doesn't have control of DPC, move the initalization and caching of DPC capabilities from the DPC driver to pci_init_capabilities(). Link: https://lore.kernel.org/r/5888380657c8b9551675b5dbd48e370e4fd2703d.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/ERR: Return status of pcie_do_recovery()Kuppuswamy Sathyanarayanan2-6/+9
As per the DPC Enhancements ECN [1], sec 4.5.1, table 4-4, if the OS supports Error Disconnect Recover (EDR), it must invalidate the software state associated with child devices of the port without attempting to access the child device hardware. In addition, if the OS supports DPC, it must attempt to recover the child devices if the port implements the DPC Capability. If the OS continues operation, the OS must inform the firmware of the status of the recovery operation via the _OST method. Return the result of pcie_do_recovery() so we can report it to firmware via _OST. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 Link: https://lore.kernel.org/r/eb60ec89448769349c6722954ffbf2de163155b5.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/ERR: Remove service dependency in pcie_do_recovery()Kuppuswamy Sathyanarayanan6-81/+14
Previously we passed the PCIe service type parameter to pcie_do_recovery(), where reset_link() looked up the underlying pci_port_service_driver and its .reset_link() function pointer. Instead of using this roundabout way, we can just pass the driver-specific .reset_link() callback function when calling pcie_do_recovery() function. This allows us to call pcie_do_recovery() from code that is not a PCIe port service driver, e.g., Error Disconnect Recover (EDR) support. Remove pcie_port_find_service() and pcie_port_service_driver.reset_link since they are now unused. Link: https://lore.kernel.org/r/60e02b87b526cdf2930400059d98704bf0a147d1.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/DPC: Move DPC data into struct pci_devBjorn Helgaas1-72/+31
We only need 25 bits of data for DPC, so I don't think it's worth the complexity of allocating and keeping track of the struct dpc_dev separately from the pci_dev. Move that data into the struct pci_dev. Link: https://lore.kernel.org/r/98323eaa18080adbe5bb30846862f09f8722d4b3.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-28PCI/ERR: Update error status after reset_link()Kuppuswamy Sathyanarayanan1-1/+2
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 <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Keith Busch <[email protected]> Cc: Ashok Raj <[email protected]>
2020-03-28PCI/ERR: Combine pci_channel_io_frozen casesKuppuswamy Sathyanarayanan1-6/+5
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/[email protected] [bhelgaas: split from https://lore.kernel.org/r/a255fcb3a3fdebcd90f84e08b555f1786eb8eba2.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com] Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-27PCI: dwc: pci-dra7xx: Fix MSI IRQ handlingVignesh Raghavendra1-36/+195
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 <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-03-27Merge branches 'iommu/fixes', 'arm/qcom', 'arm/omap', 'arm/smmu', 'x86/amd', ↵Joerg Roedel1-0/+4
'x86/vt-d', 'virtio' and 'core' into next
2020-03-25Merge branch 'x86/cpu' into perf/core, to resolve conflictIngo Molnar1-4/+2
Conflicts: arch/x86/events/intel/uncore.c Signed-off-by: Ingo Molnar <[email protected]>
2020-03-25powerpc/eeh: Make early EEH init pseries specificOliver O'Halloran3-3/+3
The eeh_ops->probe() function is called from two different contexts: 1. On pseries, where we set EEH_PROBE_MODE_DEVTREE, it's called in eeh_add_device_early() which is supposed to run before we create a pci_dev. 2. On PowerNV, where we set EEH_PROBE_MODE_DEV, it's called in eeh_device_add_late() which is supposed to run *after* the pci_dev is created. The "early" probe is required because PAPR requires that we perform an RTAS call to enable EEH support on a device before we start interacting with it via config space or MMIO. This requirement doesn't exist on PowerNV and shoehorning two completely separate initialisation paths into a common interface just results in a convoluted code everywhere. Additionally the early probe requires the probe function to take an pci_dn rather than a pci_dev argument. We'd like to make pci_dn a pseries specific data structure since there's no real requirement for them on PowerNV. To help both goals move the early probe into the pseries containment zone so the platform depedence is more explicit. Reviewed-by: Sam Bobroff <[email protected]> Signed-off-by: Oliver O'Halloran <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-03-25powerpc/eeh: Do early EEH init only when requiredOliver O'Halloran2-1/+5
The pci hotplug helper (pci_hp_add_devices()) calls eeh_add_device_tree_early() to scan the device-tree for new PCI devices and do the early EEH probe before the device is scanned. This early probe is a no-op in a lot of cases because: a) The early init is only required to satisfy a PAPR requirement that EEH be configured before we start doing config accesses. On PowerNV it is a no-op. b) It's a no-op for devices that have already had their eeh_dev initialised. There are four callers of pci_hp_add_devices(): 1. arch/powerpc/kernel/eeh_driver.c Here the hotplug helper is called when re-scanning pci_devs that were removed during an EEH recovery pass. The EEH stat for each removed device (the eeh_dev) is retained across a recovery pass so the early init is a no-op in this case. 2. drivers/pci/hotplug/pnv_php.c This is also a no-op since the PowerNV hotplug driver is, suprisingly, PowerNV specific. 3. drivers/pci/hotplug/rpaphp_core.c 4. drivers/pci/hotplug/rpaphp_pci.c In these two cases new devices have been hotplugged and FW has provided new DT nodes for each. These are the only two cases where the EEH we might have new PCI device nodes in the DT so these are the only two cases where the early EEH probe needs to be done. We can move the calls to eeh_add_device_tree_early() to the locations where it's needed and remove it from the generic path. This is preparation for making the early EEH probe pseries specific. Reviewed-by: Sam Bobroff <[email protected]> Signed-off-by: Oliver O'Halloran <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-03-25PCI: rpaphp: Remove unused variable 'value'Chen Zhou1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/pci/hotplug/rpaphp_core.c: In function is_php_type: drivers/pci/hotplug/rpaphp_core.c:291:16: warning: variable value set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Chen Zhou <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-03-24PCI: intel-mid: Convert to new X86 CPU match macrosThomas Gleixner1-4/+2
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones. Get rid the of the local macro wrappers for consistency. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-21pci/switchtec: Replace completion wait queue usage for pollSebastian Andrzej Siewior1-9/+13
The poll callback is using the completion wait queue and sticks it into poll_wait() to wake up pollers after a command has completed. This works to some extent, but cannot provide EPOLLEXCLUSIVE support because the waker side uses complete_all() which unconditionally wakes up all waiters. complete_all() is required because completions internally use exclusive wait and complete() only wakes up one waiter by default. This mixes conceptually different mechanisms and relies on internal implementation details of completions, which in turn puts contraints on changing the internal implementation of completions. Replace it with a regular wait queue and store the state in struct switchtec_user. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-21PCI/switchtec: Fix init_completion race condition with poll_wait()Logan Gunthorpe1-1/+1
The call to init_completion() in mrpc_queue_cmd() can theoretically race with the call to poll_wait() in switchtec_dev_poll(). poll() write() switchtec_dev_poll() switchtec_dev_write() poll_wait(&s->comp.wait); mrpc_queue_cmd() init_completion(&s->comp) init_waitqueue_head(&s->comp.wait) To my knowledge, no one has hit this bug. Fix this by using reinit_completion() instead of init_completion() in mrpc_queue_cmd(). Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver") Reported-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-19PCI: Avoid ASMedia XHCI USB PME# from D0 defectKai-Heng Feng1-0/+11
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/[email protected] Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-18PCI/P2PDMA: Add Intel Sky Lake-E Root Ports B, C, D to the whitelistAndrew Maier1-0/+3
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/[email protected] Signed-off-by: Andrew Maier <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2020-03-18PCI/ASPM: Clear the correct bits when enabling L1 substatesYicong Yang1-2/+2
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/[email protected] Signed-off-by: Yicong Yang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> CC: [email protected] # v4.11+
2020-03-18PCI/ATS: Export symbols of PASID functionsJean-Philippe Brucker1-0/+4
The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related functions. Export them to allow the driver to be built as a module. Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-03-18PCI: mobiveil: Fix unmet dependency warning for PCIE_MOBIVEIL_PLATHou Zhiqiang1-0/+1
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2020-03-17PCI: mobiveil: Fix sparse different address space warningsHou Zhiqiang1-3/+4
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reported-by: kbuild test robot <[email protected]>
2020-03-12Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller1-1/+1
Minor overlapping changes, nothing serious. Signed-off-by: David S. Miller <[email protected]>
2020-03-10PCI: Add PCIE_LNKCAP2_SLS2SPEED() macroYicong Yang2-13/+13
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/[email protected] Signed-off-by: Yicong Yang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-10PCI: Use pci_speed_string() for all PCI/PCI-X/PCIe stringsBjorn Helgaas4-36/+10
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 <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-03-10PCI: Add pci_speed_string()Bjorn Helgaas3-37/+42
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 <[email protected]>
2020-03-10s390/pci: embedding hotplug_slot in zdevPierre Morel1-70/+29
Embedding the hotplug_slot in zdev structure allows to greatly simplify the hotplug handling by eliminating the handling of the slot_list. Signed-off-by: Pierre Morel <[email protected]> Reviewed-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-03-09PCI: hv: Introduce hv_msi_entryBoqun Feng1-2/+1
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) <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dexuan Cui <[email protected]>
2020-03-09PCI: hv: Move retarget related structures into tlfs headerBoqun Feng1-32/+2
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) <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dexuan Cui <[email protected]>
2020-03-09PCI: hv: Move hypercall related definitions into tlfs headerBoqun Feng1-6/+0
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) <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Andrew Murray <[email protected]> Reviewed-by: Dexuan Cui <[email protected]>
2020-03-08PCI/AER: Fix the broken interrupt injectionThomas Gleixner2-4/+3
The AER error injection mechanism just blindly abuses generic_handle_irq() which is really not meant for consumption by random drivers. The include of linux/irq.h should have been a red flag in the first place. Driver code, unless implementing interrupt chips or low level hypervisor functionality has absolutely no business with that. Invoking generic_handle_irq() from non interrupt handling context can have nasty side effects at least on x86 due to the hardware trainwreck which makes interrupt affinity changes a fragile beast. Sathyanarayanan triggered a NULL pointer dereference in the low level APIC code that way. While the particular pointer could be checked this would only paper over the issue because there are other ways to trigger warnings or silently corrupt state. Invoke the new irq_inject_interrupt() mechanism, which has the necessary sanity checks in place and injects the interrupt via the irq_retrigger() mechanism, which is at least halfways safe vs. the fragile x86 affinity change mechanics. It's safe on x86 as it does not corrupt state, but it still can cause a premature completion of an interrupt affinity change causing the interrupt line to become stale. Very unlikely, but possible. For regular operations this is a non issue as AER error injection is meant for debugging and testing and not for usage on production systems. People using this should better know what they are doing. Fixes: 390e2db82480 ("PCI/AER: Abstract AER interrupt handling") Reported-by: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: Bjorn Helgaas <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-06PCI: hv: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-4/+4
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dexuan Cui <[email protected]>
2020-03-06PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2Long Li1-0/+109
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2020-03-06PCI: hv: Decouple the func definition in hv_dr_state from VSP messageLong Li1-30/+70
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2020-03-05PCI: Introduce pci_get_dsnJacob Keller1-0/+34
Several device drivers read their Device Serial Number from the PCIe extended config space. Introduce a new helper function, pci_get_dsn(). This function reads the eight bytes of the DSN and returns them as a u64. If the capability does not exist for the device, the function returns 0. Signed-off-by: Jacob Keller <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Jeff Kirsher <[email protected]> Cc: Michael Chan <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-04PCI: pci-bridge-emul: Use new constant PCI_STATUS_ERROR_BITSHeiner Kallweit1-12/+2
Use new constant PCI_STATUS_ERROR_BITS to simplify the code. Signed-off-by: Heiner Kallweit <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-04PCI: Add pci_status_get_and_clear_errorsHeiner Kallweit1-0/+23
Several drivers use the following code sequence: 1. Read PCI_STATUS 2. Mask out non-error bits 3. Action based on error bits set 4. Write back set error bits to clear them As this is a repeated pattern, add a helper to the PCI core. Signed-off-by: Heiner Kallweit <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-04PCI: amlogic: Use AXG PCIERemi Pommarel1-94/+22
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-02-28PCI: Add 32 GT/s decoding in some macrosYicong Yang1-2/+4
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/[email protected] Signed-off-by: Yicong Yang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-02-27PCI: Add boot interrupt quirk mechanism for Xeon chipsetsSean V Kelley1-7/+73
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/[email protected]/ Add a new mechanism via PCI CFG for those chipsets supporting CIPINTRC register's dis_intx_rout2ich bit. Link: https://lore.kernel.org/r/[email protected] Reported-by: Kar Hin Ong <[email protected]> Tested-by: Kar Hin Ong <[email protected]> Signed-off-by: Sean V Kelley <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2020-02-27PCI: brcmstb: Fix build on 32bit ARM platforms with older compilersMarek Szyprowski1-1/+1
Some older compilers have no implementation for the helper for 64-bit unsigned division/modulo, so linking pcie-brcmstb driver causes the "undefined reference to `__aeabi_uldivmod'" error. *rc_bar2_size is always a power of two, because it is calculated as: "1ULL << fls64(entry->res->end - entry->res->start)", so the modulo operation in the subsequent check can be replaced by a simple logical AND with a proper mask. Link: https://lore.kernel.org/r/[email protected] Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Nicolas Saenz Julienne <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]>
2020-02-26PCI: qcom: Fix the fixup of PCI_VENDOR_ID_QCOMBjorn Andersson1-1/+7
There exists non-bridge PCIe devices with PCI_VENDOR_ID_QCOM, so limit the fixup to only affect the relevant PCIe bridges. Fixes: 322f03436692 ("PCI: qcom: Use default config space read function") Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Stanimir Varbanov <[email protected]> Cc: [email protected] # v5.2+
2020-02-26PCI: pci-epf-test: Add support to defer core initializationVidya Sagar1-41/+77
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 <[email protected]> [[email protected]: commit log] Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-02-25PCI: dwc: Add API to notify core initialization completionVidya Sagar2-0/+12
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-02-25PCI: endpoint: Add notification for core init completionVidya Sagar1-1/+18
Add support to send notifications to EPF from EPC once the core registers initialization is complete. Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-02-25PCI: dwc: Refactor core initialization code for EP modeVidya Sagar2-28/+50
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.