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

PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link

2020-06-24T15:48:53+00:00

[ Upstream commit 87dccf09323fc363bd0d072fcc12b96622ab8c69 ]

The vim3l board does not work with a standard PCIe switch (ASM1184e),
spitting all kind of errors - hinting at HW misconfiguration (no link,
port enumeration issues, etc).

According to the the Synopsys DWC PCIe Reference Manual, in the section
dedicated to the PLCR register, bit 7 is described (FAST_LINK_MODE) as:

"Sets all internal timers to fast mode for simulation purposes."

it is sound to set this bit from a simulation perspective, but on actual
silicon, which expects timers to have a nominal value, it is not.

Make sure the FAST_LINK_MODE bit is cleared when configuring the RC
to solve this problem.

Link: https://lore.kernel.org/r/20200429164230.309922-1-maz@kernel.org
Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Signed-off-by: Marc Zyngier 
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Neil Armstrong 
Acked-by: Rob Herring 
Signed-off-by: Sasha Levin

PCI: dwc: Fix inner MSI IRQ domain registration

2020-06-24T15:48:53+00:00

[ Upstream commit 0414b93e78d87ecc24ae1a7e61fe97deb29fa2f4 ]

On a system that uses the internal DWC MSI widget, I get this
warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected:

  debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present!

This is due to the fact that the DWC MSI code tries to register two
IRQ domains for the same firmware node, without telling the low
level code how to distinguish them (by setting a bus token). This
further confuses debugfs which tries to create corresponding
files for each domain.

Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is
the closest thing we have as to "generic MSI".

Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org
Signed-off-by: Marc Zyngier 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Jingoo Han 
Signed-off-by: Sasha Levin

PCI: dwc: pci-dra7xx: Use devm_platform_ioremap_resource_byname()

2020-06-24T15:48:53+00:00

[ Upstream commit c8a119779f5609de8dcd98630f71cc7f1b2e4e8c ]

platform_get_resource() may fail and return NULL, so we had better
check its return value to avoid a NULL pointer dereference a bit later
in the code. Fix it to use devm_platform_ioremap_resource_byname()
instead of calling platform_get_resource_byname() and devm_ioremap().

Link: https://lore.kernel.org/r/20200429015027.134485-1-weiyongjun1@huawei.com
Signed-off-by: Wei Yongjun 
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

PCI: aardvark: Issue PERST via GPIO

2020-06-24T15:48:48+00:00

[ Upstream commit 5169a9851daaa2782a7bd2bb83d5b1bd224b2879 ]

Add support for issuing PERST via GPIO specified in 'reset-gpios'
property (as described in PCI device tree bindings).

Some buggy cards (e.g. Compex WLE900VX or WLE1216) are not detected
after reboot when PERST is not issued during driver initialization.

If bootloader already enabled link training then issuing PERST has no
effect for some buggy cards (e.g. Compex WLE900VX) and these cards are
not detected. We therefore clear the LINK_TRAINING_EN register before.

It was observed that Compex WLE900VX card needs to be in PERST reset
for at least 10ms if bootloader enabled link training.

Tested on Turris MOX.

Link: https://lore.kernel.org/r/20200430080625.26070-6-pali@kernel.org
Tested-by: Tomasz Maciej Nowak 
Signed-off-by: Pali Rohár 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Thomas Petazzoni 
Signed-off-by: Sasha Levin

PCI: aardvark: Improve link training

2020-06-24T15:48:48+00:00

[ Upstream commit 43fc679ced18006b12d918d7a8a4af392b7fbfe7 ]

Currently the aardvark driver trains link in PCIe gen2 mode. This may
cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or
even not detected. Moreover when ASPM code tries to retrain link second
time, these cards may stop responding and link goes down. If gen1 is
used this does not happen.

Unconditionally forcing gen1 is not a good solution since it may have
performance impact on gen2 cards.

To overcome this, read 'max-link-speed' property (as defined in PCI
device tree bindings) and use this as max gen mode. Then iteratively try
link training at this mode or lower until successful. After successful
link training choose final controller gen based on Negotiated Link Speed
from Link Status register, which should match card speed.

Link: https://lore.kernel.org/r/20200430080625.26070-5-pali@kernel.org
Tested-by: Tomasz Maciej Nowak 
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Rob Herring 
Acked-by: Thomas Petazzoni 
Signed-off-by: Sasha Levin

PCI: aardvark: Train link immediately after enabling training

2020-06-24T15:48:48+00:00

[ Upstream commit 6964494582f56a3882c2c53b0edbfe99eb32b2e1 ]

Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link
training and starting link training causes detection issues with some
buggy cards (such as Compex WLE900VX).

Move the code which enables link training immediately before the one
which starts link traning.

This fixes detection issues of Compex WLE900VX card on Turris MOX after
cold boot.

Link: https://lore.kernel.org/r/20200430080625.26070-2-pali@kernel.org
Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...")
Tested-by: Tomasz Maciej Nowak 
Signed-off-by: Pali Rohár 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Rob Herring 
Acked-by: Thomas Petazzoni 
Signed-off-by: Sasha Levin

PCI: brcmstb: Assert fundamental reset on initialization

2020-06-24T15:48:42+00:00

[ Upstream commit 22e21e51ce755399fd42055a3f668ee4af370881 ]

While preparing the driver for upstream this detail was missed.

If not asserted during the initialization process, devices connected on
the bus will not be made aware of the internal reset happening. This,
potentially resulting in unexpected behavior.

Link: https://lore.kernel.org/r/20200507172020.18000-1-nsaenzjulienne@suse.de
Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Florian Fainelli 
Signed-off-by: Sasha Levin

PCI: rcar: Fix incorrect programming of OB windows

2020-06-24T15:48:41+00:00

[ Upstream commit 2b9f217433e31d125fb697ca7974d3de3ecc3e92 ]

The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between
a CPU address (which is determined by the window number 'x') and a
programmed PCI address - Thus allowing the controller to translate CPU
accesses into PCI accesses.

However the existing code incorrectly writes the CPU address - lets fix
this by writing the PCI address instead.

For memory transactions, existing DT users describe a 1:1 identity mapping
and thus this change should have no effect. However the same isn't true for
I/O.

Link: https://lore.kernel.org/r/20191004132941.6660-1-andrew.murray@arm.com
Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver")
Tested-by: Marek Vasut 
Signed-off-by: Andrew Murray 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Marek Vasut 
Signed-off-by: Sasha Levin

PCI: v3-semi: Fix a memory leak in v3_pci_probe() error handling paths

2020-06-24T15:48:41+00:00

[ Upstream commit bca718988b9008d0d5f504e2d318178fc84958c1 ]

If we fails somewhere in 'v3_pci_probe()', we need to free 'host'.

Use the managed version of 'pci_alloc_host_bridge()' to do that easily.
The use of managed resources is already widely used in this driver.

Link: https://lore.kernel.org/r/20200418081637.1585-1-christophe.jaillet@wanadoo.fr
Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver")
Signed-off-by: Christophe JAILLET 
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Linus Walleij 
Signed-off-by: Sasha Levin

PCI: vmd: Filter resource type bits from shadow register

2020-06-24T15:48:28+00:00

[ Upstream commit 3e5095eebe015d5a4d566aa5e03c8621add5f0a7 ]

Versions of VMD with the Host Physical Address shadow register use this
register to calculate the bus address offset needed to do guest
passthrough of the domain. This register shadows the Host Physical
Address registers including the resource type bits. After calculating
the offset, the extra resource type bits lead to the VMD resources being
over-provisioned at the front and under-provisioned at the back.

Example:
pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]

Expected:
pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]

If other devices are mapped in the over-provisioned front, it could lead
to resource conflict issues with VMD or those devices.

Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com
Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
Signed-off-by: Jon Derrick 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin