summaryrefslogtreecommitdiffstats
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2022-03-10PCI: dwc: Restore MSI Receiver mask during resumeJisheng Zhang1-1/+6
If a host that uses the IP's integrated MSI Receiver lost power during suspend, we call dw_pcie_setup_rc() to reinit the RC. But dw_pcie_setup_rc() always sets pp->irq_mask[ctrl] to ~0, so the mask register is always set as 0xffffffff incorrectly, thus the MSI can't work after resume. Fix this issue by moving pp->irq_mask[ctrl] initialization to dw_pcie_host_init() so we can correctly set the mask reg during both boot and resume. Tested-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://lore.kernel.org/r/20211226074019.2556-1-jszhang@kernel.org Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-10PCI: fu740: Drop redundant '-gpios' from DT GPIO lookupBen Dooks1-2/+2
The calls to devm_gpiod_get_optional() have the -gpios at the end of the name but the GPIO core code is already adding the suffix during the lookup. This means the PCIe driver is not finding the necessary reset or power lines to allow initialisation of the PCIe. Drop the redundant '-gpios' when we look up GPIOs from the DT. This bug has not been noticed because if U-Boot has setup the GPIO lines for the hardware when it does the PCIe initialisation (either by booting from PCIe or user command to access PCIe) then the PCIe will work in Linux. The U-Boot as supplied by SiFive does not by default initialise any PCIe component. Link: https://lore.kernel.org/r/20220221210347.1335004-1-ben.dooks@codethink.co.uk Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-10PCI: apple: Change MSI handling to handle 4-cell AIC fwspec formHector Martin1-1/+1
AIC2 changes the IRQ fwspec to add a cell. Always use the second-to-last cell for the MSI handling, so it will work for both AIC1 and AIC2 devices. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220309192123.152028-2-marcan@marcan.st
2022-03-09PCI/VGA: Replace full MIT license text with SPDX identifierBjorn Helgaas1-22/+1
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is equivalent to including the entire MIT license text from LICENSES/preferred/MIT. Replace the MIT license text with the equivalent SPDX identifier. Link: https://lore.kernel.org/r/20220224224753.297579-12-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Use unsigned format string to print lock countsBjorn Helgaas1-1/+1
In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we previously printed them with "%d", the signed decimal format. Print them with the unsigned format "%u" instead. Link: https://lore.kernel.org/r/20220224224753.297579-11-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Log bridge control messages when adding devicesHuacai Chen1-11/+8
Previously vga_arb_device_init() iterated through all VGA devices and indicated whether legacy VGA routing to each could be controlled by an upstream bridge. But we determine that information in vga_arbiter_add_pci_device(), which we call for every device, so we can log it there without iterating through the VGA devices again. Note that we call vga_arbiter_check_bridge_sharing() before adding the device to vga_list, so we have to handle the very first device separately. Link: https://lore.kernel.org/r/20220224224753.297579-10-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Remove empty vga_arb_device_card_gone()Bjorn Helgaas1-15/+1
vga_arb_device_card_gone() has always been empty. Remove it. Link: https://lore.kernel.org/r/20220224224753.297579-9-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Move disabled VGA device detection to ADD_DEVICE pathHuacai Chen1-18/+9
a37c0f48950b ("vgaarb: Select a default VGA device even if there's no legacy VGA") extended the vga_arb_device_init() subsys_initcall so that if there are no other eligible devices, it could select a disabled VGA device as the default. Move this detection from vga_arb_select_default_device() to vga_arbiter_add_pci_device() so every device, even those hot-added or enumerated after vga_arb_device_init() is eligible for selection as the default VGA device. [bhelgaas: commit log, restructure] Link: https://lore.kernel.org/r/20211015061512.2941859-5-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20220224224753.297579-8-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Daniel Axtens <dja@axtens.net> Cc: Zhou Wang <wangzhou1@hisilicon.com>
2022-03-09PCI/VGA: Move non-legacy VGA detection to ADD_DEVICE pathHuacai Chen1-22/+32
a37c0f48950b ("vgaarb: Select a default VGA device even if there's no legacy VGA") extended the vga_arb_device_init() subsys_initcall so it could select a non-legacy VGA device as the default. That failed to consider that PCI devices may be enumerated after vga_arb_device_init(), e.g., hot-added devices or non-ACPI systems that do PCI enumeration in pcibios_init(). Devices found then could never be selected as the default. One system where this is a problem is the MIPS-based Loongson where an ASpeed AST2500 VGA device is behind a bridge that doesn't implement the VGA Enable bit, so legacy resources are not routed to the VGA device. [1] Fix this by moving the non-legacy VGA device selection from vga_arb_select_default_device() to vga_arbiter_add_pci_device(), which is called after every PCI device is enumerated, either by the vga_arb_device_init() subsys_initcall or as an ADD_DEVICE notifier. [1] https://lore.kernel.org/r/20210514080025.1828197-6-chenhuacai@loongson.cn [bhelgaas: commit log, restructure] Link: https://lore.kernel.org/r/20211015061512.2941859-5-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20211015061512.2941859-7-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20220224224753.297579-7-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Daniel Axtens <dja@axtens.net> Cc: Zhou Wang <wangzhou1@hisilicon.com>
2022-03-09PCI/VGA: Move firmware default device detection to ADD_DEVICE pathHuacai Chen1-20/+17
Previously we selected the firmware default device, i.e., one that owns the boot framebuffer, as the default device in vga_arb_select_default_device(). This was only done in the vga_arb_device_init() subsys_initcall, so devices enumerated later, e.g., by pcibios_init(), were not eligible. Fix this by moving the firmware default device selection from vga_arb_select_default_device() to vga_arbiter_add_pci_device(), which is called after every PCI device is enumerated, either by the vga_arb_device_init() subsys_initcall or as an ADD_DEVICE notifier. Note that if vga_arb_select_default_device() previously found a device owning the boot framebuffer, it unconditionally set it to be the default VGA device, and no subsequent device could replace it. [bhelgaas: commit log, restructure slightly] Link: https://lore.kernel.org/r/20211015061512.2941859-7-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20220224224753.297579-6-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Bruno Prémont <bonbons@linux-vserver.org>
2022-03-09PCI/VGA: Factor out default VGA device selectionHuacai Chen1-6/+39
Default VGA device selection fails when PCI devices are enumerated after the vga_arb_device_init() subsys_initcall. vga_arbiter_add_pci_device() selects the first fully enabled device to which legacy VGA resources are routed as the default VGA device. This is an ADD_DEVICE notifier, so it runs after every PCI device is enumerated. vga_arb_select_default_device() may select framebuffer devices, partially enabled GPUs, or non-legacy devices that don't have legacy VGA resources routed to them as the default VGA device. But this only happens once, from the vga_arb_device_init() subsys_initcall, so it doesn't consider devices enumerated after that: acpi_init acpi_scan_init acpi_pci_root_init # PCI device enumeration (ACPI systems) vga_arb_device_init for_each_pci_device vga_arbiter_add_pci_device # ADD_DEVICE notifier if (VGA-owner) vga_set_default_device <-- set default VGA vga_arb_select_default_device # only called ONCE for_each_vga_device if (framebuffer) vga_set_default_device <-- set default VGA to framebuffer if (!vga_default_device()) if (non-legacy, integrated GPU, etc) vga_set_default_device <-- set default VGA if (!vga_default_device()) vga_set_default_device <-- set default VGA pcibios_init pcibios_scanbus # PCI device enumeration (non-ACPI systems) ... vga_arbiter_add_pci_device # ADD_DEVICE notification if (VGA-owner) vga_set_default_device <-- set default VGA Note that on non-ACPI systems, vga_arb_select_default_device() runs before pcibios_init(), so it sees no VGA devices and can never set a framebuffer device, a non-legacy integrated GPU, etc., as the default device. Factor out the default VGA device selection to vga_is_boot_device(), called from vga_arbiter_add_pci_device(). Then we can migrate the default device selection from vga_arb_select_default_device() to the vga_arbiter_add_pci_device() path. [bhelgaas: commit log, split to separate patch] Link: https://lore.kernel.org/r/20211015061512.2941859-4-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20220224224753.297579-5-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Factor out vga_select_framebuffer_device()Bjorn Helgaas1-46/+53
On x86 and ia64, if a VGA device BARs include a framebuffer reported by platform firmware, we select the device as the default VGA device. Factor this code to a separate function. No functional change intended. Link: https://lore.kernel.org/r/20220224224753.297579-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Bruno Prémont <bonbons@linux-vserver.org>
2022-03-09PCI/VGA: Move vga_arb_integrated_gpu() earlier in fileHuacai Chen1-14/+11
Move vga_arb_integrated_gpu() earlier in file to prepare for future patch. No functional change intended. [bhelgaas: pull #ifdefs inside function] Link: https://lore.kernel.org/r/20211015061512.2941859-3-chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20220224224753.297579-3-helgaas@kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-09PCI/VGA: Move vgaarb to drivers/pciBjorn Helgaas3-0/+1587
The VGA arbiter is really PCI-specific and doesn't depend on any GPU things. Move it to the PCI subsystem. Note that misc_init() must be called before vga_arb_device_init(). These are both subsys_initcalls, so this ordering depends on the link order, which is determined by drivers/Makefile: obj-y += pci/ obj-y += char/ <-- misc_init() obj-y += gpu/ <-- vga_arb_device_init() (before this commit) The drivers/pci/ subsys_initcalls are called *before* misc_init(), so convert vga_arb_device_init() to subsys_initcall_sync(), which is called after *all* subsys_initcalls. Link: https://lore.kernel.org/r/20220224224753.297579-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-08PM: sleep: Add device name to suspend_report_result()Youngjin Jang1-7/+7
Currently, suspend_report_result() prints only function information. If any driver uses a common PM function, nobody knows who exactly called the failing function. A device pinter is needed to recognize the failing device. For example: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0 PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0 become after the change: serial 00:05: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0 pci 0000:00:01.3: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0 Signed-off-by: Youngjin Jang <yj84.jang@samsung.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-07PCI/IOV: Fix wrong kernel-doc identifierLeon Romanovsky1-2/+2
Replace "-" to be ":" in comment section to be aligned with kernel-doc format. drivers/pci/iov.c:67: warning: Function parameter or member 'dev' not described in 'pci_iov_get_pf_drvdata' drivers/pci/iov.c:67: warning: Function parameter or member 'pf_driver' not described in 'pci_iov_get_pf_drvdata' Fixes: a7e9f240c0da ("PCI/IOV: Add pci_iov_get_pf_drvdata() to allow VF reaching the drvdata of a PF") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/8cecf7df45948a256dc56148cf9e87b2f2bb4198.1646652504.git.leonro@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-03-07PCI: endpoint: Fix misused goto labelLi Chen1-1/+1
Fix a misused goto label jump since that can result in a memory leak. Link: https://lore.kernel.org/r/17e7b9b9ee6.c6d9c6a02564.4545388417402742326@zohomail.com Signed-off-by: Li Chen <lchen@ambarella.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2022-03-07PCI: imx6: Enable i.MX6QP PCIe power management supportRichard Zhu1-1/+3
i.MX6QP PCIe supports the reset logic, thus it can reset itself to the initialized state when exit from L2 or L3 states. Enable the i.MX6QP PCIe suspend/resume operations support. Link: https://lore.kernel.org/r/1645425237-4071-2-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
2022-03-04PCI: Reduce warnings on possible RW1C corruptionMark Tomlinson1-3/+6
For hardware that only supports 32-bit writes to PCI there is the possibility of clearing RW1C (write-one-to-clear) bits. A rate-limited messages was introduced by fb2659230120, but rate-limiting is not the best choice here. Some devices may not show the warnings they should if another device has just produced a bunch of warnings. Also, the number of messages can be a nuisance on devices which are otherwise working fine. Change the ratelimit to a single warning per bus. This ensures no bus is 'starved' of emitting a warning and also that there isn't a continuous stream of warnings. It would be preferable to have a warning per device, but the pci_dev structure is not available here, and a lookup from devfn would be far too slow. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit config writes") Link: https://lore.kernel.org/r/20200806041455.11070-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Scott Branden <scott.branden@broadcom.com>
2022-03-03PCI: Support BAR sizes up to 8TBDongdong Liu1-1/+1
Current kernel reports that BARs larger than 128GB, e.g., this 4TB BAR, are disabled: pci 0000:01:00.0: disabling BAR 4: [mem 0x00000000-0x3ffffffffff 64bit pref] (bad alignment 0x40000000000) Increase the maximum BAR size from 128GB to 8TB for future expansion. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20220118092117.10089-1-liudongdong3@huawei.com Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-02PCI/AER: Update aer-inject URLYicong Yang2-2/+2
The link to the aer-inject referenced leads to an empty repo and seems no longer used. Replace it with the link mentioned in Documentation/PCI/pcieaer-howto.rst. Link: https://lore.kernel.org/r/20220115104921.21606-1-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-03-02PCI: hv: Avoid the retarget interrupt hypercall in irq_unmask() on ARM64Boqun Feng1-111/+122
On ARM64 Hyper-V guests, SPIs are used for the interrupts of virtual PCI devices, and SPIs can be managed directly via GICD registers. Therefore the retarget interrupt hypercall is not needed on ARM64. An arch-specific interface hv_arch_irq_unmask() is introduced to handle the architecture level differences on this. For x86, the behavior remains unchanged, while for ARM64 no hypercall is invoked when unmasking an irq for virtual PCI devices. Link: https://lore.kernel.org/r/20220217034525.1687678-1-boqun.feng@gmail.com Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2022-02-27Merge tag 'irq-urgent-2022-02-27' of ↵Linus Torvalds1-7/+7
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Thomas Gleixner: "A single fix for a regression caused by the recent PCI/MSI rework which resulted in a recursive locking problem in the VMD driver. The cure is to cache the relevant information upfront instead of retrieving it at runtime" * tag 'irq-urgent-2022-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI: vmd: Prevent recursive locking on interrupt allocation
2022-02-27PCI/IOV: Add pci_iov_get_pf_drvdata() to allow VF reaching the drvdata of a PFJason Gunthorpe1-0/+29
There are some cases where a SR-IOV VF driver will need to reach into and interact with the PF driver. This requires accessing the drvdata of the PF. Provide a function pci_iov_get_pf_drvdata() to return this PF drvdata in a safe way. Normally accessing a drvdata of a foreign struct device would be done using the device_lock() to protect against device driver probe()/remove() races. However, due to the design of pci_enable_sriov() this will result in a ABBA deadlock on the device_lock as the PF's device_lock is held during PF sriov_configure() while calling pci_enable_sriov() which in turn holds the VF's device_lock while calling VF probe(), and similarly for remove. This means the VF driver can never obtain the PF's device_lock. Instead use the implicit locking created by pci_enable/disable_sriov(). A VF driver can access its PF drvdata only while its own driver is attached, and the PF driver can control access to its own drvdata based on when it calls pci_enable/disable_sriov(). To use this API the PF driver will setup the PF drvdata in the probe() function. pci_enable_sriov() is only called from sriov_configure() which cannot happen until probe() completes, ensuring no VF races with drvdata setup. For removal, the PF driver must call pci_disable_sriov() in its remove function before destroying any of the drvdata. This ensures that all VF drivers are unbound before returning, fencing concurrent access to the drvdata. The introduction of a new function to do this access makes clear the special locking scheme and the documents the requirements on the PF/VF drivers using this. Link: https://lore.kernel.org/all/20220224142024.147653-5-yishaih@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2022-02-27PCI/IOV: Add pci_iov_vf_id() to get VF indexJason Gunthorpe1-0/+14
The PCI core uses the VF index internally, often called the vf_id, during the setup of the VF, eg pci_iov_add_virtfn(). This index is needed for device drivers that implement live migration for their internal operations that configure/control their VFs. Specifically, mlx5_vfio_pci driver that is introduced in coming patches from this series needs it and not the bus/device/function which is exposed today. Add pci_iov_vf_id() which computes the vf_id by reversing the math that was used to create the bus/device/function. Link: https://lore.kernel.org/all/20220224142024.147653-2-yishaih@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2022-02-25PCI/P2PDMA: Add Intel 3rd Gen Intel Xeon Scalable Processors to whitelistMichael J. Ruhl1-0/+1
In order to do P2P communication the bridge ID of the platform must be in the P2P device table. Update the P2P device table with a device ID for the 3rd Gen Intel Xeon Scalable Processors. Link: https://lore.kernel.org/r/20220209162801.7647-1-michael.j.ruhl@intel.com Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
2022-02-25Revert "PCI: aardvark: Fix initialization with old Marvell's Arm Trusted ↵Pali Rohár1-3/+1
Firmware" This reverts commit b0c6ae0f8948a2be6bf4e8b4bbab9ca1343289b6. Armada 3720 phy driver (phy-mvebu-a3700-comphy.c) does not return -EOPNOTSUPP from phy_power_on() callback anymore. So remove dead code which handles -EOPNOTSUPP return value. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/20220203214444.1508-6-kabel@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-02-24Merge tag 'pci-v5.17-fixes-5' of ↵Linus Torvalds2-6/+11
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull pci fixes from Bjorn Helgaas: - Fix a merge error that broke PCI device enumeration on mvebu platforms, including Turris Omnia (Armada 385) (Pali Rohár) - Avoid using ATS on all AMD Navi10 and Navi14 GPUs because some VBIOSes don't account for "harvested" (disabled) parts of the chip when initializing caches (Alex Deucher) * tag 'pci-v5.17-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Mark all AMD Navi10 and Navi14 GPU ATS as broken PCI: mvebu: Fix device enumeration regression
2022-02-24sizes.h: Add SZ_1T macroChristophe Leroy1-1/+0
Today drivers/pci/controller/pci-xgene.c defines SZ_1T Move it into linux/sizes.h so that it can be re-used elsewhere. Link: https://lore.kernel.org/r/575cb7164cf124c75df7cb9242ea7374733942bf.1642752946.git.christophe.leroy@csgroup.eu Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Toan Le <toan@os.amperecomputing.com> Cc: linux-pci@vger.kernel.org
2022-02-23PCI: Mark all AMD Navi10 and Navi14 GPU ATS as brokenAlex Deucher1-5/+9
There are enough VBIOS escapes without the proper workaround that some users still hit this. Microsoft never productized ATS on Windows so OEM platforms that were Windows-only didn't always validate ATS. The advantages of ATS are not worth it compared to the potential instabilities on harvested boards. Disable ATS on all Navi10 and Navi14 boards. Symptoms include: amdgpu 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xffffc02000 flags=0x0000] AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xffffc02000 flags=0x0000] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=6047, emitted seq=6049 amdgpu 0000:07:00.0: amdgpu: GPU reset begin! amdgpu 0000:07:00.0: amdgpu: GPU reset succeeded, trying to resume amdgpu 0000:07:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring sdma0 test failed (-110) [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <sdma_v4_0> failed -110 amdgpu 0000:07:00.0: amdgpu: GPU reset(1) failed Related commits: e8946a53e2a6 ("PCI: Mark AMD Navi14 GPU ATS as broken") a2da5d8cc0b0 ("PCI: Mark AMD Raven iGPU ATS as broken in some platforms") 45beb31d3afb ("PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken") 5e89cd303e3a ("PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken") d28ca864c493 ("PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken") 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken") [bhelgaas: add symptoms and related commits] Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1760 Link: https://lore.kernel.org/r/20220222160801.841643-1-alexander.deucher@amd.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Guchun Chen <guchun.chen@amd.com>
2022-02-23PCI: qcom: Add SM8450 PCIe supportDmitry Baryshkov1-13/+44
On SM8450 platform PCIe hosts do not use all the clocks (and add several additional clocks), so expand the driver to handle these requirements. PCIe0 and PCIe1 hosts use different sets of clocks, so separate entries are required. Link: https://lore.kernel.org/r/20220223101435.447839-5-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
2022-02-23PCI: qcom: Add ddrss_sf_tbu flagDmitry Baryshkov1-1/+3
Qualcomm PCIe driver uses compatible string to check if the ddrss_sf_tbu clock should be used. Since sc7280 support has added flags, switch to the new mechanism to check if this clock should be used. Link: https://lore.kernel.org/r/20220223101435.447839-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
2022-02-23PCI: qcom: Remove redundancy between qcom_pcie and qcom_pcie_cfgDmitry Baryshkov1-18/+16
In preparation to adding more flags to configuration data, use pointer to struct qcom_pcie_cfg directly inside struct qcom_pcie, rather than duplicating all its fields. This would save us from the boilerplate code that just copies flag values from one struct to another one. Link: https://lore.kernel.org/r/20220223101435.447839-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
2022-02-22PCI: mvebu: Implement support for legacy INTx interruptsPali Rohár1-0/+159
This adds support for legacy INTx interrupts received from other PCIe devices and which are reported by a new INTx irq chip. With this change, kernel can distinguish between INTA, INTB, INTC and INTD interrupts. Note that for this support, device tree files has to be properly adjusted to provide "interrupts" or "interrupts-extended" property with intx interrupt source, "interrupt-names" property with "intx" string and also 'interrupt-controller' subnode must be defined. If device tree files do not provide these nodes then driver would work as before. Link: https://lore.kernel.org/r/20220222155030.988-12-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: mvebu: Fix macro names and comments about legacy interruptsPali Rohár1-8/+18
Register 0x1910 unmasks interrupts and legacy INTx interrupts are unmasked because driver does not support individual masking yet. Link: https://lore.kernel.org/r/20220222155030.988-11-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: mvebu: Use child_ops APIPali Rohár1-37/+40
Split struct pci_ops between ops and child_ops. Member ops is used for accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for accessing real PCIe cards. There is no need to mix these two struct pci_ops into one as PCI core code already provides separate callbacks via bridge->ops and bridge->child_ops. Link: https://lore.kernel.org/r/20220222155030.988-9-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: mvebu: Add support for Advanced Error Reporting registers on emulated ↵Pali Rohár1-1/+66
bridge AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND, PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP hardware and returns zeros. Note that AER interrupt is not supported yet as mvebu emulated bridge does not implement interrupts support at all yet. Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and correctly this register should be referenced via standard macros with offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4. Link: https://lore.kernel.org/r/20220222155030.988-8-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridgePali Rohár1-0/+4
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via emulated bridge. After this change Subsystem ID is visible in lspci output at line: Capabilities: [40] Subsystem Link: https://lore.kernel.org/r/20220222155030.988-7-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: mvebu: Correctly configure x1/x4 modePali Rohár1-1/+18
If x1/x4 mode is not set correctly then link with endpoint card is not established. Use DTS property 'num-lanes' to deteriminate x1/x4 mode. Link: https://lore.kernel.org/r/20220222155030.988-6-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capabilityPali Rohár2-20/+51
This is read-only capability in PCI config space. Put it between base PCI capability and base PCI Express capability. Driver just have to specify subsystem_vendor_id and subsystem_id fields in emulated bridge structure and pci-bridge-emul takes care of correctly compose PCI Bridge Subsystem Vendor ID capability. Link: https://lore.kernel.org/r/20220222155030.988-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: pci-bridge-emul: Add support for PCIe extended capabilitiesRussell King2-25/+67
Add support for PCIe extended capabilities, which we just redirect to the emulating driver. [pali: Fix writing new value with W1C bits] Link: https://lore.kernel.org/r/20220222155030.988-3-pali@kernel.org Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-22PCI: pci-bridge-emul: Re-arrange register testsRussell King1-30/+31
Re-arrange the tests for which sets of registers are being accessed so that it is easier to add further regions later. No functional change. [pali: Fix reading old value in pci_bridge_emul_conf_write] Link: https://lore.kernel.org/r/20220222155030.988-2-pali@kernel.org Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2022-02-21Merge tag 'v5.17-rc5' into sched/core, to resolve conflictsIngo Molnar8-102/+93
New conflicts in sched/core due to the following upstream fixes: 44585f7bc0cb ("psi: fix "defined but not used" warnings when CONFIG_PROC_FS=n") a06247c6804f ("psi: Fix uaf issue when psi trigger is destroyed while being polled") Conflicts: include/linux/psi_types.h kernel/sched/psi.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-02-21PCI: vmd: Prevent recursive locking on interrupt allocationThomas Gleixner1-7/+7
Tejas reported the following recursive locking issue: swapper/0/1 is trying to acquire lock: ffff8881074fd0a0 (&md->mutex){+.+.}-{3:3}, at: msi_get_virq+0x30/0xc0 but task is already holding lock: ffff8881017cd6a0 (&md->mutex){+.+.}-{3:3}, at: __pci_enable_msi_range+0xf2/0x290 stack backtrace: __mutex_lock+0x9d/0x920 msi_get_virq+0x30/0xc0 pci_irq_vector+0x26/0x30 vmd_msi_init+0xcc/0x210 msi_domain_alloc+0xbf/0x150 msi_domain_alloc_irqs_descs_locked+0x3e/0xb0 __pci_enable_msi_range+0x155/0x290 pci_alloc_irq_vectors_affinity+0xba/0x100 pcie_port_device_register+0x307/0x550 pcie_portdrv_probe+0x3c/0xd0 pci_device_probe+0x95/0x110 This is caused by the VMD MSI code which does a lookup of the Linux interrupt number for an VMD managed MSI[X] vector. The lookup function tries to acquire the already held mutex. Avoid that by caching the Linux interrupt number at initialization time instead of looking it up over and over. Fixes: 82ff8e6b78fc ("PCI/MSI: Use msi_get_virq() in pci_get_vector()") Reported-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: linux-pci@vger.kernel.org Link: https://lore.kernel.org/r/87a6euub2a.ffs@tglx
2022-02-17PCI: iproc: Set all 24 bits of PCI class codePali Rohár1-5/+4
Register 0x43c in its low 24 bits contains PCI class code. Update code to set all 24 bits of PCI class code and not only upper 16 bits of PCI class code. Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits of normal PCI bridge class. Link: https://lore.kernel.org/r/20220214114109.26809-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Roman Bacik <roman.bacik@broadcom.com> Acked-by: Ray Jui <ray.jui@broadcom.com>
2022-02-17PCI: Add defines for normal and subtractive PCI bridgesPali Rohár17-30/+31
Add these PCI class codes to pci_ids.h: PCI_CLASS_BRIDGE_PCI_NORMAL PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE Use these defines in all kernel code for describing PCI class codes for normal and subtractive PCI bridges. [bhelgaas: similar change in pci-mvebu.c] Link: https://lore.kernel.org/r/20220214114109.26809-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-02-16sched/isolation: Use single feature type while referring to housekeeping cpumaskFrederic Weisbecker1-2/+2
Refer to housekeeping APIs using single feature types instead of flags. This prevents from passing multiple isolation features at once to housekeeping interfaces, which soon won't be possible anymore as each isolation features will have their own cpumask. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Juri Lelli <juri.lelli@redhat.com> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://lore.kernel.org/r/20220207155910.527133-5-frederic@kernel.org
2022-02-16pci: Decouple HK_FLAG_WQ and HK_FLAG_DOMAIN cpumask fetchFrederic Weisbecker1-5/+16
To prepare for supporting each feature of the housekeeping cpumask toward cpuset, prepare each of the HK_FLAG_* entries to move to their own cpumask with enforcing to fetch them individually. The new constraint is that multiple HK_FLAG_* entries can't be mixed together anymore in a single call to housekeeping cpumask(). This will later allow, for example, to runtime modify the cpulist passed through "isolcpus=", "nohz_full=" and "rcu_nocbs=" kernel boot parameters. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Juri Lelli <juri.lelli@redhat.com> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://lore.kernel.org/r/20220207155910.527133-2-frederic@kernel.org
2022-02-15Merge tag 'hyperv-fixes-signed-20220215' of ↵Linus Torvalds1-2/+11
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - Rework use of DMA_BIT_MASK in vmbus to work around a clang bug (Michael Kelley) - Fix NUMA topology (Long Li) - Fix a memory leak in vmbus (Miaoqian Lin) - One minor clean-up patch (Cai Huoqing) * tag 'hyperv-fixes-signed-20220215' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: Drivers: hv: utils: Make use of the helper macro LIST_HEAD() Drivers: hv: vmbus: Rework use of DMA_BIT_MASK(64) Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj PCI: hv: Fix NUMA node assignment when kernel boots with custom NUMA topology
2022-02-14PCI: mvebu: Fix device enumeration regressionPali Rohár1-1/+2
Jan reported that on Turris Omnia (Armada 385), no PCIe devices were detected after upgrading from v5.16.1 to v5.16.3 and identified the cause as the backport of 91a8d79fc797 ("PCI: mvebu: Fix configuring secondary bus of PCIe Root Port via emulated bridge"), which appeared in v5.17-rc1. 91a8d79fc797 was incorrectly applied from mailing list patch [1] to the linux git repository [2] probably due to resolving merge conflicts incorrectly. Fix it now. [1] https://lore.kernel.org/r/20211125124605.25915-12-pali@kernel.org [2] https://git.kernel.org/linus/91a8d79fc797 [bhelgaas: commit log] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215540 Fixes: 91a8d79fc797 ("PCI: mvebu: Fix configuring secondary bus of PCIe Root Port via emulated bridge") Link: https://lore.kernel.org/r/20220214110228.25825-1-pali@kernel.org Link: https://lore.kernel.org/r/20220127234917.GA150851@bhelgaas Reported-by: Jan Palus <jpalus@fastmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-15 08:08:45 +0000