kernel/git/stable/linux.git/drivers/pci/controller, branch linux-5.12.y

PCI: tegra194: Fix tegra_pcie_ep_raise_msi_irq() ill-defined shift

2021-07-20T14:02:20+00:00

[ Upstream commit f67092eff2bd40650aad54a1a1910160f41d864a ] tegra_pcie_ep_raise_msi_irq() shifted a signed 32-bit value left by 31 bits. The behavior of this is implementation-defined. Replace the shift by BIT(), which is well-defined. Found by cppcheck: $ cppcheck --enable=all drivers/pci/controller/dwc/pcie-tegra194.c Checking drivers/pci/controller/dwc/pcie-tegra194.c ... drivers/pci/controller/dwc/pcie-tegra194.c:1829:23: portability: Shifting signed 32-bit value by 31 bits is implementation-defined behaviour. See condition at line 1826. [shiftTooManyBitsSigned] appl_writel(pcie, (1 << irq), APPL_MSI_CTRL_1); ^ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210618160219.303092-1-jonathanh@nvidia.com Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Jon Hunter Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: intel-gw: Fix INTx enable

2021-07-20T14:02:20+00:00

[ Upstream commit 655832d12f2251e04031294f547c86935a0a126d ] The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however was taking (for example) "13" as raw value instead of taking BIT(13). Define the legacy PCI interrupt bits using the BIT() macro and then use these in PCIE_APP_IRN_INT. Link: https://lore.kernel.org/r/20210106135540.48420-1-martin.blumenstingl@googlemail.com Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver") Signed-off-by: Martin Blumenstingl Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Rahul Tanwar Signed-off-by: Sasha Levin

PCI: iproc: Support multi-MSI only on uniprocessor kernel

2021-07-20T14:02:20+00:00

[ Upstream commit 2dc0a201d0f59e6818ef443609f0850a32910844 ] The interrupt affinity scheme used by this driver is incompatible with multi-MSI as it implies moving the doorbell address to that of another MSI group. This isn't possible for multi-MSI, as all the MSIs must have the same doorbell address. As such it is restricted to systems with a single CPU. Link: https://lore.kernel.org/r/20210622152630.40842-2-sbodomerle@gmail.com Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Marc Zyngier Signed-off-by: Sandor Bodo-Merle Signed-off-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Acked-by: Pali Rohár Acked-by: Ray Jui Signed-off-by: Sasha Levin

PCI: iproc: Fix multi-MSI base vector number allocation

2021-07-20T14:02:20+00:00

[ Upstream commit e673d697b9a234fc3544ac240e173cef8c82b349 ] Commit fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") introduced multi-MSI support with a broken allocation mechanism (it failed to reserve the proper number of bits from the inner domain). Natural alignment of the base vector number was also not guaranteed. Link: https://lore.kernel.org/r/20210622152630.40842-1-sbodomerle@gmail.com Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Pali Rohár Signed-off-by: Sandor Bodo-Merle Signed-off-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Acked-by: Pali Rohár Acked-by: Ray Jui Signed-off-by: Sasha Levin

PCI: rockchip: Register IRQ handlers after device and data are ready

2021-07-20T14:02:16+00:00

[ Upstream commit 3cf5f7ab230e2b886e493c7a8449ed50e29d2b98 ] An IRQ handler may be called at any time after it is registered, so anything it relies on must be ready before registration. rockchip_pcie_subsys_irq_handler() and rockchip_pcie_client_irq_handler() read registers in the PCIe controller, but we registered them before turning on clocks to the controller. If either is called before the clocks are turned on, the register reads fail and the machine hangs. Similarly, rockchip_pcie_legacy_int_handler() uses rockchip->irq_domain, but we installed it before initializing irq_domain. Register IRQ handlers after their data structures are initialized and clocks are enabled. Found by enabling CONFIG_DEBUG_SHIRQ, which calls the IRQ handler when it is being unregistered. An error during the probe path might cause this unregistration and IRQ handler execution before the device or data structure init has finished. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210608080409.1729276-1-javierm@redhat.com Reported-by: Peter Robinson Tested-by: Peter Robinson Signed-off-by: Javier Martinez Canillas Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Shawn Lin Signed-off-by: Sasha Levin

PCI: tegra: Add missing MODULE_DEVICE_TABLE

2021-07-20T14:02:15+00:00

[ Upstream commit 7bf475a4614a9722b9b989e53184a02596cf16d1 ] Add missing MODULE_DEVICE_TABLE definition so we generate correct modalias for automatic loading of this driver when it is built as a module. Link: https://lore.kernel.org/r/1620792422-16535-1-git-send-email-zou_wei@huawei.com Reported-by: Hulk Robot Signed-off-by: Zou Wei Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Vidya Sagar Acked-by: Thierry Reding Signed-off-by: Sasha Levin

PCI: hv: Fix a race condition when removing the device

2021-07-20T14:02:13+00:00

[ Upstream commit 94d22763207ac6633612b8d8e0ca4fba0f7aa139 ] On removing the device, any work item (hv_pci_devices_present() or hv_pci_eject_device()) scheduled on workqueue hbus->wq may still be running and race with hv_pci_remove(). This can happen because the host may send PCI_EJECT or PCI_BUS_RELATIONS(2) and decide to rescind the channel immediately after that. Fix this by flushing/destroying the workqueue of hbus before doing hbus remove. Link: https://lore.kernel.org/r/1620806800-30983-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Long Li Signed-off-by: Lorenzo Pieralisi Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

PCI: ftpci100: Rename macro name collision

2021-07-20T14:02:13+00:00

[ Upstream commit 5be967d5016ac5ffb9c4d0df51b48441ee4d5ed1 ] PCI_IOSIZE is defined in mach-loongson64/spaces.h, so change the name of the PCI_* macros in pci-ftpci100.c to use FTPCI_* so that they are more localized and won't conflict with other drivers or arches. ../drivers/pci/controller/pci-ftpci100.c:37: warning: "PCI_IOSIZE" redefined 37 | #define PCI_IOSIZE 0x00 | In file included from ../arch/mips/include/asm/addrspace.h:13, ... from ../drivers/pci/controller/pci-ftpci100.c:15: arch/mips/include/asm/mach-loongson64/spaces.h:11: note: this is the location of the previous definition 11 | #define PCI_IOSIZE SZ_16M Suggested-by: Linus Walleij Link: https://lore.kernel.org/r/20210517234117.3660-1-rdunlap@infradead.org Reported-by: kernel test robot Signed-off-by: Randy Dunlap Signed-off-by: Lorenzo Pieralisi Reviewed-by: Linus Walleij Cc: Jiaxun Yang Cc: Linus Walleij Cc: Krzysztof Wilczyński Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Signed-off-by: Sasha Levin

PCI: aardvark: Implement workaround for the readback value of VEND_ID

2021-07-19T08:01:25+00:00

commit 7f71a409fe3d9358da07c77f15bb5b7960f12253 upstream. Marvell Armada 3700 Functional Errata, Guidelines, and Restrictions document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243): The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it should read 11ABh. The firmware can write the correct value, 11ABh, through VEND_ID (RD0076044h [15:0]). Implement this workaround in aardvark driver for both PCI vendor id and PCI subsystem vendor id. This change affects and fixes PCI vendor id of emulated PCIe root bridge. After this change emulated PCIe root bridge has correct vendor id. Link: https://lore.kernel.org/r/20210624222621.4776-5-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix checking for PIO Non-posted Request

2021-07-19T08:01:25+00:00

commit 8ceeac307a79f68c0d0c72d6e48b82fa424204ec upstream. PIO_NON_POSTED_REQ for PIO_STAT register is incorrectly defined. Bit 10 in register PIO_STAT indicates the response is to a non-posted request. Link: https://lore.kernel.org/r/20210624213345.3617-2-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman