aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2021-06-28PCI: tegra194: Fix tegra_pcie_ep_raise_msi_irq() ill-defined shiftJon Hunter1-1/+1
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/[email protected] Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-25PCI: aardvark: Implement workaround for the readback value of VEND_IDPali Rohár1-0/+11
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/[email protected] Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Marek Behún <[email protected]> Cc: [email protected]
2021-06-25PCI: aardvark: Fix checking for PIO Non-posted RequestPali Rohár1-1/+1
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Marek Behún <[email protected]> Cc: [email protected]
2021-06-24PCI: tegra194: Fix host initialization during resumeVidya Sagar1-0/+2
Commit 275e88b06a27 ("PCI: tegra: Fix host link initialization") broke host initialization during resume as it misses out calling the API dw_pcie_setup_rc() which is required for host and MSI initialization. Link: https://lore.kernel.org/r/[email protected] Fixes: 275e88b06a27 ("PCI: tegra: Fix host link initialization") Tested-by: Jon Hunter <[email protected]> Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-24PCI: tegra: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
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/[email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zou Wei <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Vidya Sagar <[email protected]> Acked-by: Thierry Reding <[email protected]>
2021-06-24PCI: imx6: Enable PHY internal regulator when supplied >3VRichard Zhu1-0/+20
The i.MX8MQ PCIe PHY needs 1.8V in default but can be supplied by either a 1.8V or a 3.3V regulator. The "vph-supply" DT property tells us which external regulator supplies the PHY. If that regulator supplies anything over 3V, enable the PHY's internal 3.3V-to-1.8V regulator. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lucas Stach <[email protected]>
2021-06-24PCI: imx6: Limit DBI register length for imx6qp PCIeRichard Zhu1-0/+1
Define the length of the DBI registers and limit config space to its length. This makes sure that the kernel does not access registers beyond that point that otherwise would lead to an abort on the i.MX 6QuadPlus. See commit 075af61c19cd ("PCI: imx6: Limit DBI register length") that resolves a similar issue on the i.MX 6Quad PCIe. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]>
2021-06-24PCI: imx6: Remove imx6_pcie_probe() redundant error messageZhen Lei1-3/+1
When devm_ioremap_resource() fails, __devm_ioremap_resource() prints an error message including the device name, failure cause, and possibly resource information. Remove the error message from imx6_pcie_probe() since it's redundant. Link: https://lore.kernel.org/r/[email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhen Lei <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]> Acked-by: Richard Zhu <[email protected]>
2021-06-24PCI: intel-gw: Fix INTx enableMartin Blumenstingl1-4/+6
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/[email protected] Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver") Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Rahul Tanwar <[email protected]>
2021-06-24PCI: Export pci_dev_trylock() and pci_dev_unlock()Luis Chamberlain1-2/+4
Other places in the kernel use this form, and so just provide a common path for it. Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
2021-06-23Backmerge tag 'v5.13-rc7' into drm-nextDave Airlie7-132/+271
Backmerge Linux 5.13-rc7 to make some pulls from later bases apply, and to bake in the conflicts so far.
2021-06-22PCI: iproc: Support multi-MSI only on uniprocessor kernelSandor Bodo-Merle1-1/+7
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/[email protected] Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Marc Zyngier <[email protected]> Signed-off-by: Sandor Bodo-Merle <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Marc Zyngier <[email protected]> Acked-by: Pali Rohár <[email protected]> Acked-by: Ray Jui <[email protected]>
2021-06-22PCI: iproc: Fix multi-MSI base vector number allocationSandor Bodo-Merle1-10/+11
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/[email protected] Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Pali Rohár <[email protected]> Signed-off-by: Sandor Bodo-Merle <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Marc Zyngier <[email protected]> Acked-by: Pali Rohár <[email protected]> Acked-by: Ray Jui <[email protected]>
2021-06-22Revert "PCI: PM: Do not read power state in pci_enable_device_flags()"Rafael J. Wysocki1-3/+13
Revert commit 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") that is reported to cause PCI device initialization issues on some systems. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213481 Link: https://lore.kernel.org/linux-acpi/[email protected] Reported-by: Michael <[email protected]> Reported-by: Salvatore Bonaccorso <[email protected]> Fixes: 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()") Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-06-22PCI: mediatek-gen3: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Link: https://lore.kernel.org/r/[email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zou Wei <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]>
2021-06-21Merge tag 'v5.13-rc7' into usb-nextGreg Kroah-Hartman6-131/+262
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-20PCI: hv: Add check for hyperv_initialized in init_hv_pci_drv()Haiyang Zhang1-0/+3
Add check for hv_is_hyperv_initialized() at the top of init_hv_pci_drv(), so if the pci-hyperv driver is force-loaded on non Hyper-V platforms, the init_hv_pci_drv() will exit immediately, without any side effects, like assignments to hvpci_block_ops, etc. Signed-off-by: Haiyang Zhang <[email protected]> Reported-and-tested-by: Mohammad Alqayeem <[email protected]> Reviewed-by: Wei Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2021-06-18Merge tag 'pci-v5.13-fixes-2' of ↵Linus Torvalds6-131/+262
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: - Clear 64-bit flag for host bridge windows below 4GB to fix a resource allocation regression added in -rc1 (Punit Agrawal) - Fix tegra194 MCFG quirk build regressions added in -rc1 (Jon Hunter) - Avoid secondary bus resets on TI KeyStone C667X devices (Antti Järvinen) - Avoid secondary bus resets on some NVIDIA GPUs (Shanker Donthineni) - Work around FLR erratum on Huawei Intelligent NIC VF (Chiqijun) - Avoid broken ATS on AMD Navi14 GPU (Evan Quan) - Trust Broadcom BCM57414 NIC to isolate functions even though it doesn't advertise ACS support (Sriharsha Basavapatna) - Work around AMD RS690 BIOSes that don't configure DMA above 4GB (Mikel Rychliski) - Fix panic during PIO transfer on Aardvark controller (Pali Rohár) * tag 'pci-v5.13-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: aardvark: Fix kernel panic during PIO transfer PCI: Add AMD RS690 quirk to enable 64-bit DMA PCI: Add ACS quirk for Broadcom BCM57414 NIC PCI: Mark AMD Navi14 GPU ATS as broken PCI: Work around Huawei Intelligent NIC VF FLR erratum PCI: Mark some NVIDIA GPUs to avoid bus reset PCI: Mark TI C667X to avoid bus reset PCI: tegra194: Fix MCFG quirk build regressions PCI: of: Clear 64-bit flag for non-prefetchable memory below 4GB
2021-06-18PCI: aardvark: Fix kernel panic during PIO transferPali Rohár1-9/+40
Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError Interrupt To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet. If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out. In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler. Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/[email protected]/ https://lore.kernel.org/linux-pci/[email protected]/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541 But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet. After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Marek Behún <[email protected]> Cc: [email protected] # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock")
2021-06-18PCI: Add ACS quirk for Broadcom BCM57414 NICSriharsha Basavapatna1-0/+2
The Broadcom BCM57414 NIC may be a multi-function device. While it does not advertise an ACS capability, peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for this device so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. [bhelgaas: commit log] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sriharsha Basavapatna <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected]
2021-06-18PCI: Mark AMD Navi14 GPU ATS as brokenEvan Quan1-1/+3
Observed unexpected GPU hang during runpm stress test on 0x7341 rev 0x00. Further debugging shows broken ATS is related. Disable ATS on this part. Similar issues on other devices: 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") Suggested-by: Alex Deucher <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Evan Quan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]> Cc: [email protected]
2021-06-18PCI: Work around Huawei Intelligent NIC VF FLR erratumChiqijun1-0/+65
pcie_flr() starts a Function Level Reset (FLR), waits 100ms (the maximum time allowed for FLR completion by PCIe r5.0, sec 6.6.2), and waits for the FLR to complete. It assumes the FLR is complete when a config read returns valid data. When we do an FLR on several Huawei Intelligent NIC VFs at the same time, firmware on the NIC processes them serially. The VF may respond to config reads before the firmware has completed its reset processing. If we bind a driver to the VF (e.g., by assigning the VF to a virtual machine) in the interval between the successful config read and completion of the firmware reset processing, the NIC VF driver may fail to load. Prevent this driver failure by waiting for the NIC firmware to complete its reset processing. Not all NIC firmware supports this feature. [bhelgaas: commit log] Link: https://support.huawei.com/enterprise/en/doc/EDOC1100063073/87950645/vm-oss-occasionally-fail-to-load-the-in200-driver-when-the-vf-performs-flr Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chiqijun <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Alex Williamson <[email protected]> Cc: [email protected]
2021-06-18PCI: Mark some NVIDIA GPUs to avoid bus resetShanker Donthineni1-0/+12
Some NVIDIA GPU devices do not work with SBR. Triggering SBR leaves the device inoperable for the current system boot. It requires a system hard-reboot to get the GPU device back to normal operating condition post-SBR. For the affected devices, enable NO_BUS_RESET quirk to avoid the issue. This issue will be fixed in the next generation of hardware. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shanker Donthineni <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Sinan Kaya <[email protected]> Cc: [email protected]
2021-06-18PCI: Mark TI C667X to avoid bus resetAntti Järvinen1-0/+10
Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS automatically disables LTSSM when Secondary Bus Reset is received and device stops working. Prevent bus reset for these devices. With this change, the device can be assigned to VMs with VFIO, but it will leak state between VMs. Reference: https://e2e.ti.com/support/processors/f/791/t/954382 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Antti Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kishon Vijay Abraham I <[email protected]> Cc: [email protected]
2021-06-18PCI: tegra194: Fix MCFG quirk build regressionsJon Hunter3-121/+128
7f100744749e ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata") caused a few build regressions: - 7f100744749e removed the Makefile rule for CONFIG_PCIE_TEGRA194, so pcie-tegra.c can no longer be built as a module. Restore that rule. - 7f100744749e added "#ifdef CONFIG_PCIE_TEGRA194" around the native driver, but that's only set when the driver is built-in (for a module, CONFIG_PCIE_TEGRA194_MODULE is defined). The ACPI quirk is completely independent of the rest of the native driver, so move the quirk to its own file and remove the #ifdef in the native driver. - 7f100744749e added symbols that are always defined but used only when CONFIG_PCIEASPM, which causes warnings when CONFIG_PCIEASPM is not set: drivers/pci/controller/dwc/pcie-tegra194.c:259:18: warning: ‘event_cntr_data_offset’ defined but not used [-Wunused-const-variable=] drivers/pci/controller/dwc/pcie-tegra194.c:250:18: warning: ‘event_cntr_ctrl_offset’ defined but not used [-Wunused-const-variable=] drivers/pci/controller/dwc/pcie-tegra194.c:243:27: warning: ‘pcie_gen_freq’ defined but not used [-Wunused-const-variable=] Fixes: 7f100744749e ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2021-06-18PCI: of: Clear 64-bit flag for non-prefetchable memory below 4GBPunit Agrawal1-0/+2
Alexandru and Qu reported this resource allocation failure on ROCKPro64 v2 and ROCK Pi 4B, both based on the RK3399: pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff 64bit] pci 0000:00:00.0: PCI bridge to [bus 01] pci 0000:00:00.0: BAR 14: no space for [mem size 0x00100000] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] "BAR 14" is the PCI bridge's 32-bit non-prefetchable window, and our PCI allocation code isn't smart enough to allocate it in a host bridge window marked as 64-bit, even though this should work fine. A DT host bridge description includes the windows from the CPU address space to the PCI bus space. On a few architectures (microblaze, powerpc, sparc), the DT may also describe PCI devices themselves, including their BARs. Before 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses"), of_bus_pci_get_flags() ignored the fact that some DT addresses described 64-bit windows and BARs. That was a problem because the virtio virtual NIC has a 32-bit BAR and a 64-bit BAR, and the driver couldn't distinguish them. 9d57e61bf723 set IORESOURCE_MEM_64 for those 64-bit DT ranges, which fixed the virtio driver. But it also set IORESOURCE_MEM_64 for host bridge windows, which exposed the fact that the PCI allocator isn't smart enough to put 32-bit resources in those 64-bit windows. Clear IORESOURCE_MEM_64 from host bridge windows since we don't need that information. Suggested-by: Bjorn Helgaas <[email protected]> Fixes: 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses") Link: https://lore.kernel.org/r/[email protected] Reported-at: https://lore.kernel.org/lkml/[email protected]/ Reported-at: https://lore.kernel.org/lkml/YMyTUv7Jsd89PGci@m4/T/#u Reported-by: Alexandru Elisei <[email protected]> Reported-by: Qu Wenruo <[email protected]> Tested-by: Alexandru Elisei <[email protected]> Tested-by: Domenico Andreoli <[email protected]> Signed-off-by: Punit Agrawal <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
2021-06-17PCI: ixp4xx: Add a new driver for IXP4xxLinus Walleij3-0/+680
This adds a new PCI controller driver for the Intel IXP4xx (IX425, IXP435 etc), based on the XScale microarchitecture. This replaces the old driver in arch/arm/mach-ixp4xx/common-pci.c which utilized the ARM-specific BIOS32 PCI framework, and all parameterization for such things as memory and IO space as well as interrupt swizzling is done from the device tree. The plan is to phase out and delete the old driver piecemal. The __raw_writel() and __raw_readl() are used for accessing the PCI controller for the same reason that these accessors are used in the timer, IRQ and GPIO drivers: the platform will alter its address bus pattern based on whether the system is booted in big- or little-endian mode. For this reason all register on IXP4xx must always be accessed in native (CPU) endianness. This driver supports 64MB of PCI memory space, but not the indirect access of 1GB that is available in the old driver. We can address that later if and only if there are users that need all 1GB of PCI address space. Krzysztof reports having to use indirect MMIO only once for a VGA card. There is work ongoing for general indirect MMIO. (In practice the indirect MMIO is performed by writing address and writing and reading values into/from a controller register.) Tested by booting the NSLU2, attaching a USB stick, mounting and browsing the drive. Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Cc: Arnd Bergmann <[email protected]> Cc: Imre Kaloz <[email protected]> Cc: Krzysztof Halasa <[email protected]> Cc: Zoltan HERPAI <[email protected]> Cc: Raylynn Knight <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2021-06-16PCI: Dynamically map ECAM regionsRussell King1-8/+46
Attempting to boot 32-bit ARM kernels under QEMU's 3.x virt models fails when we have more than 512M of RAM in the model as we run out of vmalloc space for the PCI ECAM regions. This failure will be silent when running libvirt, as the console in that situation is a PCI device. In this configuration, the kernel maps the whole ECAM, which QEMU sets up for 256 buses, even when maybe only seven buses are in use. Each bus uses 1M of ECAM space, and ioremap() adds an additional guard page between allocations. The kernel vmap allocator will align these regions to 512K, resulting in each mapping eating 1.5M of vmalloc space. This means we need 384M of vmalloc space just to map all of these, which is very wasteful of resources. Fix this by only mapping the ECAM for buses we are going to be using. In my setups, this is around seven buses in most guests, which is 10.5M of vmalloc space - way smaller than the 384M that would otherwise be required. This also means that the kernel can boot without forcing extra RAM into highmem with the vmalloc= argument, or decreasing the virtual RAM available to the guest. Suggested-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Russell King <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]>
2021-06-16PCI: pciehp: Ignore Link Down/Up caused by DPCLukas Wunner3-5/+109
Downstream Port Containment (PCIe r5.0, sec. 6.2.10) disables the link upon an error and attempts to re-enable it when instructed by the DPC driver. A slot which is both DPC- and hotplug-capable is currently powered off by pciehp once DPC is triggered (due to the link change) and powered back up on successful recovery. That's undesirable, the slot should remain powered so the hotplugged device remains bound to its driver. DPC notifies the driver of the error and of successful recovery in pcie_do_recovery() and the driver may then restore the device to working state. Moreover, Sinan points out that turning off slot power by pciehp may foil recovery by DPC: Power off/on is a cold reset concurrently to DPC's warm reset. Sathyanarayanan reports extended delays or failure in link retraining by DPC if pciehp brings down the slot. Fix by detecting whether a Link Down event is caused by DPC and awaiting recovery if so. On successful recovery, ignore both the Link Down and the subsequent Link Up event. Afterwards, check whether the link is down to detect surprise-removal or another DPC event immediately after DPC recovery. Ensure that the corresponding DLLSC event is not ignored by synthesizing it and invoking irq_wake_thread() to trigger a re-run of pciehp_ist(). The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and dpc_handler(), race against each other. If pciehp is faster than DPC, it will wait until DPC recovery completes. Recovery consists of two steps: The first step (waiting for link disablement) is recognizable by pciehp through a set DPC Trigger Status bit. The second step (waiting for link retraining) is recognizable through a newly introduced PCI_DPC_RECOVERING flag. If DPC is faster than pciehp, neither of the two flags will be set and pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag. The flag is zero if DPC didn't occur at all, hence DLLSC events are not ignored by default. pciehp waits up to 4 seconds before assuming that DPC recovery failed and bringing down the slot. This timeout is not taken from the spec (it doesn't mandate one) but based on a report from Yicong Yang that DPC may take a bit more than 3 seconds on HiSilicon's Kunpeng platform. The timeout is necessary because the DPC Trigger Status bit may never clear: On Root Ports which support RP Extensions for DPC, the DPC driver polls the DPC RP Busy bit for up to 1 second before giving up on DPC recovery. Without the timeout, pciehp would then wait indefinitely for DPC to complete. This commit draws inspiration from previous attempts to synchronize DPC with pciehp: By Sinan Kaya, August 2018: https://lore.kernel.org/linux-pci/[email protected]/ By Ethan Zhao, October 2020: https://lore.kernel.org/linux-pci/[email protected]/ By Kuppuswamy Sathyanarayanan, March 2021: https://lore.kernel.org/linux-pci/59cb30f5e5ac6d65427ceaadf1012b2ba8dbf66c.1615606143.git.sathyanarayanan.kuppuswamy@linux.intel.com/ Link: https://lore.kernel.org/r/0be565d97438fe2a6d57354b3aa4e8626952a00b.1619857124.git.lukas@wunner.de Reported-by: Sinan Kaya <[email protected]> Reported-by: Ethan Zhao <[email protected]> Reported-by: Kuppuswamy Sathyanarayanan <[email protected]> Tested-by: Kuppuswamy Sathyanarayanan <[email protected]> Tested-by: Yicong Yang <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: Dan Williams <[email protected]> Cc: Ashok Raj <[email protected]> Cc: Keith Busch <[email protected]>
2021-06-16PCI/P2PDMA: Simplify distance calculationChristoph Hellwig1-117/+73
Merge __calc_map_type_and_dist() and calc_map_type_and_dist_warn() into calc_map_type_and_dist() to simplify the code a bit. This now means we add the devfn strings to the acs_buf unconditionally even if the buffer is not printed, but that is not a lot of overhead and keeps the code much simpler. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2021-06-14Merge tag 'v5.13-rc6' into usb-nextGreg Kroah-Hartman2-1/+9
We want the usb fixes in here as well, and this resolves some merge issues with: drivers/usb/dwc3/debugfs.c drivers/usb/dwc3/gadget.c Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10PCI/P2PDMA: Avoid pci_get_slot(), which may sleepLogan Gunthorpe1-2/+32
In order to use upstream_bridge_distance_warn() from a dma_map function, it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it might sleep. In order to avoid this, try to get the host bridge's device from the first element in the device list. It should be impossible for the host bridge's device to go away while references are held on child devices, so the first element should not be able to change and, thus, this should be safe. Introduce a static function called pci_host_bridge_dev() to obtain the host bridge's root device. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/P2PDMA: Refactor pci_p2pdma_map_type()Logan Gunthorpe1-18/+12
All callers of pci_p2pdma_map_type() have a struct dev_pgmap and a struct device (of the client doing the DMA transfer). Thus move the conversion to struct pci_devs for the provider and client into this function. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/P2PDMA: Warn if host bridge not in whitelistLogan Gunthorpe1-6/+11
If the host bridge is not in the whitelist print a warning in the calc_map_type_and_dist_warn() path detailing the vendor and device IDs that would need to be added to the whitelist. Suggested-by: Don Dutile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/P2PDMA: Use correct calc_map_type_and_dist() return typeLogan Gunthorpe1-5/+5
Instead of using an int for the return value of this function, use the correct enum pci_p2pdma_map_type. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/P2PDMA: Collect acs list in stack buffer to avoid sleepingLogan Gunthorpe1-5/+2
In order to call the calc_map_type_and_dist_warn() function from a dma_map operation, the function must not sleep. The only reason it sleeps is to allocate memory for the seq_buf to print a verbose warning telling the user how to disable ACS for that path. Instead of allocating the memory with kmalloc(), allocate a smaller buffer on the stack. A 128 byte buffer is enough to print 10 PCI device names. A system with 10 bridge ports between two devices that have ACS enabled would be unusually large, so this should still be a reasonable limit. This also cleans up the awkward (and broken) return with -ENOMEM which contradicts the return type and the caller was not prepared for. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/P2PDMA: Rename upstream_bridge_distance() and rework docLogan Gunthorpe1-35/+38
The function upstream_bridge_distance() has evolved such that its name is no longer entirely reflective of what the function does. It not only calculates the distance between two peers but also calculates how the DMA addresses for those two peers should be mapped. Rename it to calc_map_type_and_dist() and rework the documentation to better describe the two pieces of information the function returns. [bhelgaas: tweak comment wording] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Logan Gunthorpe <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-10PCI/IOV: Clarify error message for unbound devicesMoritz Fischer1-2/+9
Be more verbose to disambiguate the error case when trying to configure SR-IOV with no driver bound vs. a driver that does not implement the .sriov_configure() callback. Link: https://lore.kernel.org/r/[email protected] Reported-by: Brian Foley <[email protected]> Signed-off-by: Moritz Fischer <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]>
2021-06-07PCI: Leave Apple Thunderbolt controllers on for s2idle or standbyKonstantin Kharlamov1-0/+11
On Macbook 2013, resuming from suspend-to-idle or standby resulted in the external monitor no longer being detected, a stacktrace, and errors like this in dmesg: pcieport 0000:06:00.0: can't change power state from D3hot to D0 (config space inaccessible) The reason is that we know how to turn power to the Thunderbolt controller *off* via the SXIO/SXFP/SXLF methods, but we don't know how to turn power back on. We have to rely on firmware to turn the power back on. When going to the "suspend-to-idle" or "standby" system sleep states, firmware is not involved either on the suspend side or the resume side, so we can't use SXIO/SXFP/SXLF to turn the power off. Skip SXIO/SXFP/SXLF when firmware isn't involved in suspend, e.g., when we're going to the "suspend-to-idle" or "standby" system sleep states. Fixes: 1df5172c5c25 ("PCI: Suspend/resume quirks for Apple thunderbolt") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212767 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Konstantin Kharlamov <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Cc: [email protected]
2021-06-04PCI: Coalesce host bridge contiguous aperturesKai-Heng Feng1-4/+46
Built-in graphics on HP EliteDesk 805 G6 doesn't work because graphics can't get the BAR it needs: pci_bus 0000:00: root bus resource [mem 0x10020200000-0x100303fffff window] pci_bus 0000:00: root bus resource [mem 0x10030400000-0x100401fffff window] pci 0000:00:08.1: bridge window [mem 0xd2000000-0xd23fffff] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100401fffff 64bit pref] pci 0000:00:08.1: can't claim BAR 15 [mem 0x10030000000-0x100401fffff 64bit pref]: no compatible bridge window pci 0000:00:08.1: [mem 0x10030000000-0x100401fffff 64bit pref] clipped to [mem 0x10030000000-0x100303fffff 64bit pref] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100303fffff 64bit pref] pci 0000:07:00.0: can't claim BAR 0 [mem 0x10030000000-0x1003fffffff 64bit pref]: no compatible bridge window pci 0000:07:00.0: can't claim BAR 2 [mem 0x10040000000-0x100401fffff 64bit pref]: no compatible bridge window However, the root bus has two contiguous apertures that can contain the child resource requested. Coalesce contiguous apertures so we can allocate from the entire contiguous region. [bhelgaas: fold in https://lore.kernel.org/r/[email protected]] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212013 Suggested-by: Bjorn Helgaas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-04PCI/sysfs: Add 'devspec' newlineKrzysztof Wilczyński1-1/+1
Previously, when the value of the "devspec" sysfs attribute was read from the user space there was no newline present, and utilities such as "cat" wouldn't display the result of the read correctly. Append a newline character in the show() function to match other "devspec" attributes. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2021-06-04PCI/sysfs: Fix 'resource_alignment' newline issuesKrzysztof Wilczyński1-14/+20
The value of the "resource_alignment" can be specified using a kernel command-line argument ("pci=resource_alignment=") or through the corresponding sysfs attribute under the /sys/bus/pci path. Previously, when the value was set via the kernel command-line argument, and then subsequently accessed through sysfs attribute, the value read back was not correct: # grep -oE 'pci=resource_alignment.+' /proc/cmdline pci=resource_alignment=20@00:1f.2 # cat /sys/bus/pci/resource_alignment 20@00:1f. This was also true when the value was set through the sysfs attribute without including a trailing newline: # echo -n 20@00:1f.2 > /sys/bus/pci/resource_alignment # cat /sys/bus/pci/resource_alignment 20@00:1f. When it was set through the sysfs attribute *including* a newline, reading it back worked as intended: # echo 20@00:1f.2 > /sys/bus/pci/resource_alignment # cat /sys/bus/pci/resource_alignment 20@00:1f.2 To fix this inconsistency, append a trailing newline in the show() function and strip the trailing line in the store() function if one is present. Also, allow for the value previously set using either a command-line argument or through the sysfs object to be cleared at run-time. [bhelgaas: fold in kfree fix from https://lore.kernel.org/linux-pci/[email protected]] Fixes: e499081da1a2 ("PCI: Force trailing new line to resource_alignment_param in sysfs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2021-06-03PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functionsKrzysztof Wilczyński12-70/+75
The sysfs_emit() and sysfs_emit_at() functions were introduced to make it less ambiguous which function is preferred when writing to the output buffer in a device attribute's "show" callback [1]. Convert the PCI sysfs object "show" functions from sprintf(), snprintf() and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the latter is aware of the PAGE_SIZE buffer and correctly returns the number of bytes written into the buffer. No functional change intended. [1] Documentation/filesystems/sysfs.rst Related commit: ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions"). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2021-06-03PCI/sysfs: Rely on lengths from scnprintf(), dsm_label_utf16s_to_utf8s()Krzysztof Wilczyński1-8/+10
scnprintf() returns the number of bytes written into the buffer. Change dsm_label_utf16s_to_utf8s() to do the same. Rely on those values instead of using strlen() to compute the buffer length. No functional change intended. [bhelgaas: reorder patch in series, len++ to include newline added by dsm_label_utf16s_to_utf8s(), commit log] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2021-06-03PCI/sysfs: Fix dsm_label_utf16s_to_utf8s() buffer overrunKrzysztof Wilczyński1-1/+1
"utf16s_to_utf8s(..., buf, PAGE_SIZE)" puts up to PAGE_SIZE bytes into "buf" and returns the number of bytes it actually put there. If it wrote PAGE_SIZE bytes, the newline added by dsm_label_utf16s_to_utf8s() would overrun "buf". Reduce the size available for utf16s_to_utf8s() to use so there is always space for the newline. [bhelgaas: reorder patch in series, commit log] Fixes: 6058989bad05 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs") Link: https://lore.kernel.org/r/[email protected] Reported-by: Joe Perches <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2021-06-03PCI: hv: Remove bus device removal unused refcount/functionsLong Li1-31/+3
With the new method of flushing/stopping the workqueue before doing bus removal, the old mechanism of using refcount and wait for completion is no longer needed. Remove those dead code. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Long Li <[email protected]> [[email protected]: Reworded subject] Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2021-06-03PCI: hv: Fix a race condition when removing the deviceLong Li1-7/+23
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/[email protected] Signed-off-by: Long Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2021-06-03PCI: mediatek: Remove redundant error printing in mtk_pcie_subsys_powerup()Zhen Lei1-3/+1
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Link: https://lore.kernel.org/r/[email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhen Lei <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Krzysztof Wilczyński <[email protected]>
2021-06-03PCI: ftpci100: Rename macro name collisionRandy Dunlap1-15/+15
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Cc: Jiaxun Yang <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Krzysztof Wilczyński <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: [email protected]
2021-06-03PCI: mobiveil: Remove unused readl and writel functionsKrzysztof Wilczyński1-11/+0
The PCIe host controller driver for Layerscape 4th generation SoC was added in the commit d29ad70a813b ("PCI: mobiveil: Add PCIe Gen4 RC driver for Layerscape SoCs"). At this time two static functions were introduced that appear to currently have no users. Since nothing is using neither of these functions at the moment they can be safely removed. This resolves the following build time warnings: drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c:45:19: warning: unused function 'ls_pcie_g4_lut_readl' [-Wunused-function] drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c:50:20: warning: unused function 'ls_pcie_g4_lut_writel' [-Wunused-function] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.