linux-stable.git/drivers/pci/controller, branch v5.4.136

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

2021-07-20T14:10:50+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:10:50+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: tegra: Add missing MODULE_DEVICE_TABLE

2021-07-20T14:10:47+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: aardvark: Implement workaround for the readback value of VEND_ID

2021-07-19T06:53:17+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-19T06:53:17+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

PCI: hv: Add check for hyperv_initialized in init_hv_pci_drv()

2021-07-14T14:53:18+00:00

[ Upstream commit 7d815f4afa87f2032b650ae1bba7534b550a6b8b ]

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 
Reported-and-tested-by: Mohammad Alqayeem 
Reviewed-by: Wei Liu 
Link: https://lore.kernel.org/r/1621984653-1210-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

PCI: aardvark: Fix kernel panic during PIO transfer

2021-06-23T12:41:29+00:00

commit f18139966d072dab8e4398c95ce955a9742e04f7 upstream.

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/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
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/20210608203655.31228-1-pali@kernel.org
Signed-off-by: Pali Rohár 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Marek Behún 
Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock")
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Don't rely on jiffies while holding spinlock

2021-06-23T12:41:29+00:00

commit 7fbcb5da811be7d47468417c7795405058abb3da upstream.

advk_pcie_wait_pio() can be called while holding a spinlock (from
pci_bus_read_config_dword()), then depends on jiffies in order to
timeout while polling on PIO state registers. In the case the PIO
transaction failed, the timeout will never happen and will also cause
the cpu to stall.

This decrements a variable and wait instead of using jiffies.

Signed-off-by: Remi Pommarel 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Andrew Murray 
Acked-by: Thomas Petazzoni 
Signed-off-by: Greg Kroah-Hartman

PCI: thunder: Fix compile testing

2021-05-22T09:38:28+00:00

[ Upstream commit 16f7ae5906dfbeff54f74ec75d0563bb3a87ab0b ]

Compile-testing these drivers is currently broken. Enabling it causes a
couple of build failures though:

  drivers/pci/controller/pci-thunder-ecam.c:119:30: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
  drivers/pci/controller/pci-thunder-pem.c:54:2: error: implicit declaration of function 'writeq' [-Werror,-Wimplicit-function-declaration]
  drivers/pci/controller/pci-thunder-pem.c:392:8: error: implicit declaration of function 'acpi_get_rc_resources' [-Werror,-Wimplicit-function-declaration]

Fix them with the obvious one-line changes.

Link: https://lore.kernel.org/r/20210308152501.2135937-2-arnd@kernel.org
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Kuppuswamy Sathyanarayanan 
Reviewed-by: Robert Richter 
Signed-off-by: Sasha Levin

PCI: iproc: Fix return value of iproc_msi_irq_domain_alloc()

2021-05-19T08:08:25+00:00

[ Upstream commit 1e83130f01b04c16579ed5a5e03d729bcffc4c5d ]

IRQ domain alloc function should return zero on success. Non-zero value
indicates failure.

Link: https://lore.kernel.org/r/20210303142202.25780-1-pali@kernel.org
Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
Signed-off-by: Pali Rohár 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Krzysztof Wilczyński 
Acked-by: Ray Jui 
Acked-by: Marc Zyngier 
Signed-off-by: Sasha Levin