PCI: aardvark: Fix support for Turris MOX and Compex wifi cards

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.

Fixes f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...")

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.

Fixes f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...")

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense.

In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register.

Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory.

Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect.

Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly.

Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.:
https://bugzilla.kernel.org/show_bug.cgi?id=196339

If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards.

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 4 ----
 1 file changed, 4 deletions(-)

Interpret zero value of max-link-speed property as invalid, as the device tree bindings documentation specifies.

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/of.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

From: Marek Behún <[email protected]>

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.

Signed-off-by Pali Rohár <[email protected]>

Signed-off-by Marek Behún <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 114 ++++++++++++++++++++------
 1 file changed, 89 insertions(+), 25 deletions(-)

drivers/pci/controller/pci-aardvark.c +8 -0

+static void advk_pcie_issue_perst(struct advk_pcie *pcie)
+{
+	u32 reg;
+
+	if (!pcie->reset_gpio)
+		return;
+
+	/* PERST does not work for some cards when link training is enabled */

Quoted 8 lines · On Thursday 30 April 2020 10:06:18 Pali Rohár wrote:

drivers/pci/controller/pci-aardvark.c +8 -0

+static void advk_pcie_issue_perst(struct advk_pcie *pcie)
+{
+	u32 reg;
+
+	if (!pcie->reset_gpio)
+		return;
+
+	/* PERST does not work for some cards when link training is enabled */

drivers/pci/controller/pci-aardvark.c static void advk_pcie_train_link(struct advk_pcie *pcie) · line 353

Quoted 10 lines

drivers/pci/controller/pci-aardvark.c +10 -0

+	reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
+	reg &= ~LINK_TRAINING_EN;
+	advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
+
+	/* 10ms delay is needed for some cards */
+	dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n");
+	gpiod_set_value_cansleep(pcie->reset_gpio, 1);
+	usleep_range(10000, 11000);
+	gpiod_set_value_cansleep(pcie->reset_gpio, 0);
+}

Just note about delay between changing GPIO reset:

In V2 there as only 1ms, but be figured out that it is not enough for WLE900VX cards when they were already initialized in u-boot.

I tried to find in PCI specs if there is a defined timeout for this operation. I found following 3 delay definitions which could be related:

TPVPERL - PERST# must remain active at least this long after power becomes valid TPERST - When asserted, PERST# must remain asserted at least this long
TPERSTCLK - PERST# must remain active at least this long after any supplied reference clock is stable

In another spec they have defined also minimal values:

TPVPERL - Power stable to PERST# inactive - Min 100 ms TPERST - PERST# active time - Min 100 us
TPERSTCLK - REFCLK stable before PERST# inactive - Min 100 us

After experimenting with those Compex WLE900VX cards, I know that 100us delay is not enough. And I'm not sure if TPVPERL is really relevant for this case. I understood that TPVPERL is needed when initializing power again. And because delaying boot by another 100ms is does not have to be acceptable if there is not strict reason for it, I rather decided to stay with just 10ms delay.

If you know what is the correct timeout between changing GPIO reset, please let me know and in future I can fix/reimplement it.

This register is applicable only when the controller is configured for Endpoint mode, which is not the case for the current version of this driver.

Attempting to remove this code though caused some ath10k cards to stop working, so for some unknown reason it is needed here.

This should be investigated and a comment explaining this should be put before the code, so we add a FIXME comment for now.

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 7 +++++++
 1 file changed, 7 insertions(+)

From: Marek Behún <[email protected]>

With recent proposed changes for U-Boot it is possible that bootloader won't initialize the PHY for this controller (currently the PHY is initialized regardless whether PCI is used in U-Boot, but with these proposed changes the PHY is initialized only on request).

Since the mvebu-a3700-comphy driver by Miquèl Raynal supports enabling PCIe PHY, and since Linux' functionality should be independent on what bootloader did, add code for enabling generic PHY if found in device OF node.

The mvebu-a3700-comphy driver does PHY powering via SMC calls to ARM Trusted Firmware. The corresponding code in ARM Trusted Firmware skips one register write which U-Boot does not: step 7 ("Enable TX"), see [1]. Instead ARM Trusted Firmware expects PCIe driver to do this step, probably because the register is in PCIe controller address space, instead of PHY address space. We therefore add this step into the advk_pcie_setup_hw function.

[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/marvell/comphy/phy-comphy-3700.c?h=v2.3-rc2#n836

Signed-off-by Marek Behún <[email protected]>

Cc Miquèl Raynal <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 69 +++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

PCI-E capability macros are already defined in linux/pci_regs.h. Remove their reimplementation in pcie-aardvark.

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 41 ++++++++++++---------------
 1 file changed, 18 insertions(+), 23 deletions(-)

drivers/pci/controller/pci-aardvark.c +18 -23

index 053ae6c19a3d..c53ae2511a9c 100644
@@ -34,17 +34,6 @@
 #define     PCIE_CORE_CMD_MEM_IO_REQ_EN				BIT(2)
 #define PCIE_CORE_DEV_REV_REG					0x8
 #define PCIE_CORE_PCIEXP_CAP					0xc0
-#define PCIE_CORE_DEV_CTRL_STATS_REG				0xc8
-#define     PCIE_CORE_DEV_CTRL_STATS_RELAX_ORDER_DISABLE	(0 << 4)
-#define     PCIE_CORE_DEV_CTRL_STATS_MAX_PAYLOAD_SZ_SHIFT	5
-#define     PCIE_CORE_DEV_CTRL_STATS_SNOOP_DISABLE		(0 << 11)
-#define     PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SIZE_SHIFT	12
-#define     PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SZ		0x2
-#define PCIE_CORE_LINK_CTRL_STAT_REG				0xd0
-#define     PCIE_CORE_LINK_L0S_ENTRY				BIT(0)
-#define     PCIE_CORE_LINK_TRAINING				BIT(5)
-#define     PCIE_CORE_LINK_SPEED_SHIFT				16
-#define     PCIE_CORE_LINK_WIDTH_SHIFT				20
 #define PCIE_CORE_ERR_CAPCTL_REG				0x118
 #define     PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX			BIT(5)
 #define     PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX_EN			BIT(6)

@@ -223,6 +212,11 @@ static inline u32 advk_readl(struct advk_pcie *pcie, u64 reg)
 	return readl(pcie->base + reg);
 }
 
+static inline u16 advk_read16(struct advk_pcie *pcie, u64 reg)
+{
+	return advk_readl(pcie, (reg & ~0x3)) >> ((reg & 0x3) * 8);
+}
+
 static int advk_pcie_link_up(struct advk_pcie *pcie)
 {
 	u32 val, ltssm_state;

@@ -286,16 +280,16 @@ static int advk_pcie_train_at_gen(struct advk_pcie *pcie, int gen)
 	 * Start link training immediately after enabling it.
 	 * This solves problems for some buggy cards.
 	 */
-	reg = advk_readl(pcie, PCIE_CORE_LINK_CTRL_STAT_REG);
-	reg |= PCIE_CORE_LINK_TRAINING;
-	advk_writel(pcie, reg, PCIE_CORE_LINK_CTRL_STAT_REG);
+	reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL);
+	reg |= PCI_EXP_LNKCTL_RL;
+	advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL);
 
 	ret = advk_pcie_wait_for_link(pcie);
 	if (ret)
 		return ret;
 
-	reg = advk_readl(pcie, PCIE_CORE_LINK_CTRL_STAT_REG);
-	neg_gen = (reg >> PCIE_CORE_LINK_SPEED_SHIFT) & 0xf;
+	reg = advk_read16(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKSTA);
+	neg_gen = reg & PCI_EXP_LNKSTA_CLS;
 
 	return neg_gen;
 }

@@ -385,13 +379,14 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
 		PCIE_CORE_ERR_CAPCTL_ECRC_CHCK_RCV;
 	advk_writel(pcie, reg, PCIE_CORE_ERR_CAPCTL_REG);
 
-	/* Set PCIe Device Control and Status 1 PF0 register */
-	reg = PCIE_CORE_DEV_CTRL_STATS_RELAX_ORDER_DISABLE |
-		(7 << PCIE_CORE_DEV_CTRL_STATS_MAX_PAYLOAD_SZ_SHIFT) |
-		PCIE_CORE_DEV_CTRL_STATS_SNOOP_DISABLE |
-		(PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SZ <<
-		 PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SIZE_SHIFT);
-	advk_writel(pcie, reg, PCIE_CORE_DEV_CTRL_STATS_REG);
+	/* Set PCIe Device Control register */
+	reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL);
+	reg &= ~PCI_EXP_DEVCTL_RELAX_EN;
+	reg &= ~PCI_EXP_DEVCTL_NOSNOOP_EN;
+	reg &= ~PCI_EXP_DEVCTL_READRQ;
+	reg |= PCI_EXP_DEVCTL_PAYLOAD; /* Set max payload size */
+	reg |= PCI_EXP_DEVCTL_READRQ_512B;
+	advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL);
 
 	/* Program PCIe Control 2 to disable strict ordering */
 	reg = PCIE_CORE_CTRL2_RESERVED |

Signature · 1 line

2.20.1

PCI-E capability macros are already defined in linux/pci_regs.h. Remove their reimplementation in pcie-aardvark.

Signed-off-by Pali Rohár <[email protected]>

---
 drivers/pci/controller/pci-aardvark.c | 41 ++++++++++++---------------
 1 file changed, 18 insertions(+), 23 deletions(-)

From: Marek Behún <[email protected]>

Document the possibility to reference a PHY and reset-gpios and to set max-link-speed property.

Signed-off-by Marek Behún <[email protected]>

Cc Rob Herring <[email protected]>

Cc [email protected]

---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 4 ++++
 1 file changed, 4 insertions(+)

Move the max-link-speed property of the PCIe node from board specific device tree files to the generic armada-37xx.dtsi.

Armada 37xx supports only PCIe gen2 speed so max-link-speed property should be in the genetic armada-37xx.dtsi file.

Hello,

this is the fourth version of the patch series for Armada 3720 PCIe controller (aardvark). It's main purpose is to fix some bugs regarding buggy ath10k cards, but we also found out some suspicious stuff about the driver and the SOC itself, which we try to address.

Patches are available also in my git branch pci-aardvark:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark

Changes since v3:
- do not change return value of of_pci_get_max_link_speed() function
- mark zero 'max-link-speed' as invalid
- silently use gen3 speed when 'max-link-speed' as invalid

Changes since v2:
- move PCIe max-link-speed property to armada-37xx.dtsi
- replace custom macros by standard linux/pci_regs.h macros
- increase PERST delay to 10ms (needed for initialized Compex WLE900VX)
- disable link training before PERST (needed for Compex WLE900VX)
- change of_pci_get_max_link_speed() function to signal -ENOENT
- handle errors from of_pci_get_max_link_speed() function
- updated comments, commit titles and messages

Changes since v1:
- commit titles and messages were reviewed and some of them were rewritten
- patches 1 and 5 from v1 which touch PCIe speed configuration were reworked into one patch
- patch 2 from v1 was removed, it is not needed anymore
- patch 7 from v1 now touches the device tree of armada-3720-db
- a patch was added that tries to enable PCIe PHY via generic-phy API (if a phandle to the PHY is found in the device tree)
- a patch describing the new PCIe node DT properties was added
- a patch was added that moves the PHY phandle from board device trees to armada-37xx.dtsi

Marek and Pali

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Hello,

this is the fourth version of the patch series for Armada 3720 PCIe controller (aardvark). It's main purpose is to fix some bugs regarding buggy ath10k cards, but we also found out some suspicious stuff about the driver and the SOC itself, which we try to address.

Patches are available also in my git branch pci-aardvark:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark

Quoted 7 lines · On Thursday 30 April 2020 10:06:13 Pali Rohár wrote:

Hello,

this is the fourth version of the patch series for Armada 3720 PCIe controller (aardvark). It's main purpose is to fix some bugs regarding buggy ath10k cards, but we also found out some suspicious stuff about the driver and the SOC itself, which we try to address.

Quoted 2 lines

Patches are available also in my git branch pci-aardvark:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark

Hello! Thanks everybody for review and testing of this patch series.

I would like to ask, is there something needed to fix / modify in this patch series? If everything is OK, would you Bjorn or Lorenzo take this patch series into your tree?

Quoted 13 lines · Pali Rohár

Quoted 9 lines · On Thursday 30 April 2020 10:06:13 Pali Rohár wrote:

Hello,

this is the fourth version of the patch series for Armada 3720 PCIe controller (aardvark). It's main purpose is to fix some bugs regarding buggy ath10k cards, but we also found out some suspicious stuff about the driver and the SOC itself, which we try to address.

Patches are available also in my git branch pci-aardvark:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-aardvark

Hello! Thanks everybody for review and testing of this patch series.

Quoted 3 lines

I would like to ask, is there something needed to fix / modify in this patch series? If everything is OK, would you Bjorn or Lorenzo take this patch series into your tree?

We need Thomas' ACK on the series. We don't have this HW and we comment on the generic code, Thomas owns it and must check that what you are changing is sound.

On patch 5 I share Rob's concerns - it does not make much sense to have something driver specific there, need to look further.

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Hello,

Quoted 7 lines · On Thu, 30 Apr 2020 10:06:13 +0200 Pali Rohár <[email protected]> wrote:

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Quoted 10 lines

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Thanks a lot for this work. For a number of reasons, I'm less involved in Marvell platform support in Linux, but I reviewed your series and followed the discussions around it, and I'm happy to give my:

Acked-by Thomas Petazzoni <[email protected]>

for the whole series. The changes all seem sensible, and have been tested by several folks.

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hello,

Quoted 23 lines

Hello,

Quoted 7 lines · On Thu, 30 Apr 2020 10:06:13 +0200 Pali Rohár <[email protected]> wrote:

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Quoted 10 lines

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Quoted 5 lines

Thanks a lot for this work. For a number of reasons, I'm less involved in Marvell platform support in Linux, but I reviewed your series and followed the discussions around it, and I'm happy to give my:

Acked-by Thomas Petazzoni <[email protected]>

With this acked-by for the series, the reviewed-by from Rob on the binding and the tested-by, I am pretty confident so I applied the patches 10, 11 and 12 on mvebu/dt64.

Thanks,

Gregory

Quoted 12 lines

for the whole series. The changes all seem sensible, and have been tested by several folks.

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Signature · 3 lines

Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Quoted 35 lines · On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote:

Hello,

Quoted 23 lines

Hello,

Quoted 7 lines · On Thu, 30 Apr 2020 10:06:13 +0200 Pali Rohár <[email protected]> wrote:

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Quoted 10 lines

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Quoted 5 lines

Thanks a lot for this work. For a number of reasons, I'm less involved in Marvell platform support in Linux, but I reviewed your series and followed the discussions around it, and I'm happy to give my:

Acked-by Thomas Petazzoni <[email protected]>

With this acked-by for the series, the reviewed-by from Rob on the binding and the tested-by, I am pretty confident so I applied the patches 10, 11 and 12 on mvebu/dt64.

Quoted 3 lines

Thanks,

Gregory

Thank you!

Lorenzo, would you now take remaining patches?

Quoted 36 lines · Pali Rohár

Quoted 35 lines · On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote:

Hello,

Quoted 23 lines

Hello,

Quoted 7 lines · On Thu, 30 Apr 2020 10:06:13 +0200 Pali Rohár <[email protected]> wrote:

Marek Behún (5):
PCI: aardvark: Improve link training
PCI: aardvark: Add PHY support
dt-bindings: PCI: aardvark: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property

Quoted 10 lines

Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to
read-only register
PCI: of: Zero max-link-speed value is invalid
PCI: aardvark: Issue PERST via GPIO
PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access
PCI: aardvark: Replace custom macros by standard linux/pci_regs.h
macros
arm64: dts: marvell: armada-37xx: Move PCIe max-link-speed property

Quoted 5 lines

Thanks a lot for this work. For a number of reasons, I'm less involved in Marvell platform support in Linux, but I reviewed your series and followed the discussions around it, and I'm happy to give my:

Acked-by Thomas Petazzoni <[email protected]>

With this acked-by for the series, the reviewed-by from Rob on the binding and the tested-by, I am pretty confident so I applied the patches 10, 11 and 12 on mvebu/dt64.

Quoted 7 lines

Quoted 3 lines

Thanks,

Gregory

Thank you!

Lorenzo, would you now take remaining patches?

Yes - even though I have reservations about patch (5) and the problem is related to a complete lack of programming model for these host controllers and a clear separation between what's done in the OS vs bootloader, PERST handling in this host bridge is *really* a mess.

I applied 1-9 to pci/aardvark.

Lorenzo