summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2022-03-21PCI: fu740: Force 2.5GT/s for initial device probeBen Dooks
The fu740 PCIe core does not probe any devices on the SiFive Unmatched board without this fix (or having U-Boot explicitly start the PCIe via either boot-script or user command). The fix is to start the link at 2.5GT/s speeds and once the link is up then change the maximum speed back to the default. The U-Boot driver claims to set the link-speed to 2.5GT/s to get the probe to work (and U-Boot does print link up at 2.5GT/s) in the following code: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pci/pcie_dw_sifive.c?id=v2022.01#L271 Link: https://lore.kernel.org/r/20220318152430.526320-1-ben.dooks@codethink.co.uk Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-03-21PCI: xgene: Revert "PCI: xgene: Fix IB window setup"Marc Zyngier
Commit c7a75d07827a ("PCI: xgene: Fix IB window setup") tried to fix the damages that 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") caused, but actually didn't improve anything for some plarforms (at least Mustang and m400 are still broken). Given that 6dce5aa59e0b has been reverted, revert this patch as well, restoring the PCIe support on XGene to its pre-5.5, working state. Link: https://lore.kernel.org/r/YjN8pT5e6/8cRohQ@xps13.dannf Link: https://lore.kernel.org/r/20220321104843.949645-3-maz@kernel.org Fixes: c7a75d07827a ("PCI: xgene: Fix IB window setup") Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Rob Herring <robh@kernel.org> Cc: Toan Le <toan@os.amperecomputing.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Krzysztof Wilczyński <kw@linux.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Stéphane Graber <stgraber@ubuntu.com> Cc: dann frazier <dann.frazier@canonical.com>
2022-03-21PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup"Marc Zyngier
Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") killed PCIe on my XGene-1 box (a Mustang board). The machine itself is still alive, but half of its storage (over NVMe) is gone, and the NVMe driver just times out. Note that this machine boots with a device tree provided by the UEFI firmware (2016 vintage), which could well be non conformant with the spec, hence the breakage. With the patch reverted, the box boots 5.17-rc8 with flying colors. Link: https://lore.kernel.org/all/Yf2wTLjmcRj+AbDv@xps13.dannf Link: https://lore.kernel.org/r/20220321104843.949645-2-maz@kernel.org Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Rob Herring <robh@kernel.org> Cc: Toan Le <toan@os.amperecomputing.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Krzysztof Wilczyński <kw@linux.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Stéphane Graber <stgraber@ubuntu.com> Cc: dann frazier <dann.frazier@canonical.com>
2022-03-18Merge branches 'pm-sleep', 'pm-domains' and 'pm-docs'Rafael J. Wysocki
Merge changes related to system sleep, PM domains changes and power management documentation changes for 5.18-rc1: - Fix load_image_and_restore() error path (Ye Bin). - Fix typos in comments in the system wakeup hadling code (Tom Rix). - Clean up non-kernel-doc comments in hibernation code (Jiapeng Chong). - Fix __setup handler error handling in system-wide suspend and hibernation core code (Randy Dunlap). - Add device name to suspend_report_result() (Youngjin Jang). - Make virtual guests honour ACPI S4 hardware signature by default (David Woodhouse). - Block power off of a parent PM domain unless child is in deepest state (Ulf Hansson). - Use dev_err_probe() to simplify error handling for generic PM domains (Ahmad Fatoum). - Fix sleep-in-atomic bug caused by genpd_debug_remove() (Shawn Guo). - Document Intel uncore frequency scaling (Srinivas Pandruvada). * pm-sleep: PM: hibernate: Honour ACPI hardware signature by default for virtual guests PM: sleep: Add device name to suspend_report_result() PM: suspend: fix return value of __setup handler PM: hibernate: fix __setup handler error handling PM: hibernate: Clean up non-kernel-doc comments PM: sleep: wakeup: Fix typos in comments PM: hibernate: fix load_image_and_restore() error path * pm-domains: PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove() PM: domains: use dev_err_probe() to simplify error handling PM: domains: Prevent power off for parent unless child is in deepest state * pm-docs: Documentation: admin-guide: pm: Document uncore frequency scaling
2022-03-17PCI: imx6: Assert i.MX8MM CLKREQ# even if no device presentRichard Zhu
The CLKREQ# signal is an open drain, active low signal that is driven low by the remote Endpoint device. But it might not be driven low if no Endpoint device is connected. On i.MX8MM PCIe, phy_init() may fail and system boot may hang if no Endpoint is connected to assert CLKREQ#. Handle this as on i.MX8MQ, where we explicitly assert CLKREQ# so the PHY can be initialized. Link: https://lore.kernel.org/r/1645672013-8949-1-git-send-email-hongxing.zhu@nxp.com Fixes: 178e244cb6e2 ("PCI: imx: Add the imx8mm pcie support") 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-17PCI: imx6: Invoke the PHY exit function after PHY power offRichard Zhu
To balance phy->init_count, invoke the phy_exit() after phy_power_off(). Link: https://lore.kernel.org/r/1646289275-17813-1-git-send-email-hongxing.zhu@nxp.com Fixes: 178e244cb6e2 ("PCI: imx: Add the imx8mm pcie support") 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-15xen/grant-table: remove readonly parameter from functionsJuergen Gross
The gnttab_end_foreign_access() family of functions is taking a "readonly" parameter, which isn't used. Remove it from the function parameters. Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220311103429.12845-3-jgross@suse.com Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2022-03-15Merge tag 'v5.17-rc8' into sched/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-03-14Merge tag 'v5.17-rc8' into irq/core, to fix conflictsIngo Molnar
Conflicts: drivers/pinctrl/pinctrl-starfive.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-03-14PCI: rcar: Use PCI_SET_ERROR_RESPONSE after read which triggered an exceptionMarek Vasut
In case the controller is transitioning to L1 in rcar_pcie_config_access(), any read/write access to PCIECDR triggers asynchronous external abort. This is because the transition to L1 link state must be manually finished by the driver. The PCIe IP can transition back from L1 state to L0 on its own. The current asynchronous external abort hook implementation restarts the instruction which finally triggered the fault, which can be a different instruction than the read/write instruction which started the faulting access. Usually the instruction which finally triggers the fault is one which has some data dependency on the result of the read/write. In case of read, the read value after fixup is undefined, while a read value of faulting read should be PCI_ERROR_RESPONSE. It is possible to enforce the fault using 'isb' instruction placed right after the read/write instruction which started the faulting access. Add custom register accessors which perform the read/write followed immediately by 'isb'. This way, the fault always happens on the 'isb' and in case of read, which is located one instruction before the 'isb', it is now possible to fix up the return value of the read in the asynchronous external abort hook and make that read return PCI_ERROR_RESPONSE. Link: https://lore.kernel.org/r/20220312212349.781799-2-marek.vasut@gmail.com Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Krzysztof Wilczyński <kw@linux.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2022-03-14PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access()Marek Vasut
In case the controller is transitioning to L1 in rcar_pcie_config_access(), any read/write access to PCIECDR triggers asynchronous external abort. This is because the transition to L1 link state must be manually finished by the driver. The PCIe IP can transition back from L1 state to L0 on its own. Avoid triggering the abort in rcar_pcie_config_access() by checking whether the controller is in the transition state, and if so, finish the transition right away. This prevents a lot of unnecessary exceptions, although not all of them. Link: https://lore.kernel.org/r/20220312212349.781799-1-marek.vasut@gmail.com Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Krzysztof Wilczyński <kw@linux.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2022-03-14Merge tag 'irqchip-5.18' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier: - Add support for the STM32MP13 variant - Move parent device away from struct irq_chip - Remove all instances of non-const strings assigned to struct irq_chip::name, enabling a nice cleanup for VIC and GIC) - Simplify the Qualcomm PDC driver - A bunch of SiFive PLIC cleanups - Add support for a new variant of the Meson GPIO block - Add support for the irqchip side of the Apple M1 PMU - Add support for the Apple M1 Pro/Max AICv2 irqchip - Add support for the Qualcomm MPM wakeup gadget - Move the Xilinx driver over to the generic irqdomain handling - Tiny speedup for IPIs on GICv3 systems - The usual odd cleanups Link: https://lore.kernel.org/all/20220313105142.704579-1-maz@kernel.org
2022-03-10Merge tag 'phy-for-5.18' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next Vinod writes: phy-for-5.18 - New support: - Mediatek tphy support for MT8186 - Qualcomm usb phy support for sc8180x and sc8280xp - Qualcomm ufs phy support for sc8180x and sc8280xp - Qualcomm usb phy support for MSM8953 - Cadence D-Phy Rx support - Sun4i support for USB phy - Rockchip naneng combo phy support for RK3568 - Qualcomm eDP PHY for sc7280 - Updates: - wake on support for Synopsis XHCI controllers - Yamilify Qualcomm USB HS phy binding - Charger detection support for TI tusb1210 * tag 'phy-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (53 commits) phy: qcom-qmp: add sc8280xp UFS PHY dt-bindings: phy: qcom,qmp: add sc8180x and sc8280xp ufs compatibles phy: qcom-snps: Add sc8280xp support dt-bindings: phy: qcom,usb-snps-femto-v2: Add sc8180x and sc8280xp dt-bindings: Revert "dt-bindings: soc: grf: add naneng combo phy register compatible" phy: dt-bindings: Add Cadence D-PHY Rx bindings phy: dt-bindings: cdns,dphy: add power-domains property phy: dt-bindings: Convert Cadence DPHY binding to YAML phy: cadence: Add Cadence D-PHY Rx driver dt-bindings: phy: renesas,usb2-phy: Document RZ/V2L phy bindings Revert "PCI: aardvark: Fix initialization with old Marvell's Arm Trusted Firmware" Revert "usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720" Revert "ata: ahci: mvebu: Make SATA PHY optional for Armada 3720" phy: marvell: phy-mvebu-a3700-comphy: Add native kernel implementation phy: marvell: phy-mvebu-a3700-comphy: Remove port from driver configuration phy: phy-brcm-usb: fixup BCM4908 support dt-bindings: phy: mediatek,tphy: Add compatible for MT8192 phy: ti: tusb1210: Add charger detection phy: ti: tusb1210: Add a delay between power-on and restoring the phy-parameters phy: ti: tusb1210: Drop tusb->vendor_specific2 != 0 check from tusb1210_power_on() ...
2022-03-10PCI: dwc: Restore MSI Receiver mask during resumeJisheng Zhang
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 Dooks
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 Martin
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 Helgaas
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 Helgaas
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 Chen
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 Helgaas
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 Chen
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 Chen
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 Chen
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 Chen
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 Helgaas
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 Chen
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 Helgaas
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 Jang
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 Romanovsky
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 Chen
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 Zhu
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 Tomlinson
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 Liu
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 Yang
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 Feng
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 Torvalds
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 Gunthorpe
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 Gunthorpe
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. Ruhl
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ár
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 Torvalds
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 Leroy
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 Deucher
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 Baryshkov
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 Baryshkov
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 Baryshkov
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ár
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ár
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ár
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ár
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>
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-30 19:40:09 +0000