BMC/Intel-BMC/linux.git/drivers/pci/controller, branch dev-5.15-intel

PCI: hv: Propagate coherence from VMbus device to PCI device

2022-04-20T07:34:15+00:00

[ Upstream commit 8d21732475c637c7efcdb91dc927a4c594e97898 ] PCI pass-thru devices in a Hyper-V VM are represented as a VMBus device and as a PCI device. The coherence of the VMbus device is set based on the VMbus node in ACPI, but the PCI device has no ACPI node and defaults to not hardware coherent. This results in extra software coherence management overhead on ARM64 when devices are hardware coherent. Fix this by setting up the PCI host bus so that normal PCI mechanisms will propagate the coherence of the VMbus device to the PCI device. There's no effect on x86/x64 where devices are always hardware coherent. Signed-off-by: Michael Kelley Acked-by: Boqun Feng Acked-by: Robin Murphy Link: https://lore.kernel.org/r/1648138492-2191-3-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

PCI: aardvark: Fix support for MSI interrupts

2022-04-13T18:59:04+00:00

[ Upstream commit b0b0b8b897f8e12b2368e868bd7cdc5742d5c5a9 ] Aardvark hardware supports Multi-MSI and MSI_FLAG_MULTI_PCI_MSI is already set for the MSI chip. But when allocating MSI interrupt numbers for Multi-MSI, the numbers need to be properly aligned, otherwise endpoint devices send MSI interrupt with incorrect numbers. Fix this issue by using function bitmap_find_free_region() instead of bitmap_find_next_zero_area(). To ensure that aligned MSI interrupt numbers are used by endpoint devices, we cannot use Linux virtual irq numbers (as they are random and not properly aligned). Instead we need to use the aligned hwirq numbers. This change fixes receiving MSI interrupts on Armada 3720 boards and allows using NVMe disks which use Multi-MSI feature with 3 interrupts. Without this NVMe disks freeze booting as linux nvme-core.c is waiting 60s for an interrupt. Link: https://lore.kernel.org/r/20220110015018.26359-4-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin

PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup"

2022-04-08T12:24:18+00:00

commit 1874b6d7ab1bdc900e8398026350313ac29caddb upstream. 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 Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Rob Herring Cc: Toan Le Cc: Lorenzo Pieralisi Cc: Krzysztof Wilczyński Cc: Bjorn Helgaas Cc: Stéphane Graber Cc: dann frazier [dannf: minor context adjustment] Signed-off-by: dann frazier Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix reading PCI_EXP_RTSTA_PME bit on emulated bridge

2022-04-08T12:23:30+00:00

[ Upstream commit 735f5ae49e1b44742cc63ca9b5c1ffde3e94ba91 ] The emulated bridge returns incorrect value for PCI_EXP_RTSTA register during readout in advk_pci_bridge_emul_pcie_conf_read() function: the correct bit is BIT(16), but we are setting BIT(23), because the code does *value = (isr0 & PCIE_MSG_PM_PME_MASK) << 16 where PCIE_MSG_PM_PME_MASK is BIT(7). The code should probably have been something like *value = (!!(isr0 & PCIE_MSG_PM_PME_MASK)) << 16, but we are better of using an if() and using the proper macro for this bit. Link: https://lore.kernel.org/r/20220110015018.26359-15-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin

PCI: aardvark: Fix reading MSI interrupt number

2022-04-08T12:23:29+00:00

[ Upstream commit 805dfc18dd3d4dd97a987d4406593b5a225b1253 ] In advk_pcie_handle_msi() it is expected that when bit i in the W1C register PCIE_MSI_STATUS_REG is cleared, the PCIE_MSI_PAYLOAD_REG is updated to contain the MSI number corresponding to index i. Experiments show that this is not so, and instead PCIE_MSI_PAYLOAD_REG always contains the number of the last received MSI, overall. Do not read PCIE_MSI_PAYLOAD_REG register for determining MSI interrupt number. Since Aardvark already forbids more than 32 interrupts and uses own allocated hwirq numbers, the msi_idx already corresponds to the received MSI number. Link: https://lore.kernel.org/r/20220110015018.26359-3-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin

PCI: xgene: Revert "PCI: xgene: Fix IB window setup"

2022-04-08T12:23:04+00:00

commit 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 upstream. 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 Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Rob Herring Cc: Toan Le Cc: Lorenzo Pieralisi Cc: Krzysztof Wilczyński Cc: Bjorn Helgaas Cc: Stéphane Graber Cc: dann frazier Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails

2022-04-08T12:23:04+00:00

commit f81f095e87715e198471f4653952fe5e3f824874 upstream. The intention of commit 886a9c134755 ("PCI: dwc: Move link handling into common code") was to standardize the behavior of link down as explained in its commit log: "The behavior for a link down was inconsistent as some drivers would fail probe in that case while others succeed. Let's standardize this to succeed as there are usecases where devices (and the link) appear later even without hotplug. For example, a reconfigured FPGA device." The pci-imx6 still fails to probe when the link is not present, which causes the following warning: imx6q-pcie 8ffc000.pcie: Phy link never came up imx6q-pcie: probe of 8ffc000.pcie failed with error -110 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 30 at drivers/regulator/core.c:2257 _regulator_put.part.0+0x1b8/0x1dc Modules linked in: CPU: 0 PID: 30 Comm: kworker/u2:2 Not tainted 5.15.0-next-20211103 #1 Hardware name: Freescale i.MX6 SoloX (Device Tree) Workqueue: events_unbound async_run_entry_fn [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack_lvl+0x58/0x70) [] (dump_stack_lvl) from [] (__warn+0xd4/0x154) [] (__warn) from [] (warn_slowpath_fmt+0x74/0xa8) [] (warn_slowpath_fmt) from [] (_regulator_put.part.0+0x1b8/0x1dc) [] (_regulator_put.part.0) from [] (regulator_put+0x2c/0x3c) [] (regulator_put) from [] (release_nodes+0x50/0x178) Fix this problem by ignoring the dw_pcie_wait_for_link() error like it is done on the other dwc drivers. Tested on imx6sx-sdb and imx6q-sabresd boards. Link: https://lore.kernel.org/r/20220106103645.2790803-1-festevam@gmail.com Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code") Signed-off-by: Fabio Estevam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Reviewed-by: Richard Zhu Cc: Signed-off-by: Greg Kroah-Hartman

PCI: fu740: Force 2.5GT/s for initial device probe

2022-04-08T12:22:57+00:00

commit a382c757ec5ef83137a86125f43a4c43dc2ab50b upstream. 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 Signed-off-by: Bjorn Helgaas Acked-by: Palmer Dabbelt Signed-off-by: Dimitri John Ledkov Signed-off-by: Greg Kroah-Hartman

PCI: mvebu: Fix device enumeration regression

2022-03-08T18:12:42+00:00

[ Upstream commit c49ae619905eebd3f54598a84e4cd2bd58ba8fe9 ] 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 Signed-off-by: Pali Rohár Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: mvebu: Fix support for DEVCAP2, DEVCTL2 and LNKCTL2 registers on emulated bridge

2022-03-08T18:12:36+00:00

[ Upstream commit 4ab34548c55fbbb3898306a47dfaccd4860e1ccb ] Armada XP and new hardware supports access to DEVCAP2, DEVCTL2 and LNKCTL2 configuration registers of PCIe core via PCIE_CAP_PCIEXP. So export them via emulated software root bridge. Pre-XP hardware does not support these registers and returns zeros. Link: https://lore.kernel.org/r/20211125124605.25915-16-pali@kernel.org Fixes: 1f08673eef12 ("PCI: mvebu: Convert to PCI emulated bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin