[PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Christian Marangi]

This small series introduce support for 2-lanes mode for Airoha AN7581
SoC. This is needed for correctly functionality of Eagle WiFi Card
normally attached to this SoC that require a 2-line PCIe card to
correctly work (and give the proper performance)

The first 2 patch address a limitation of the PCIe implementation
where the PERSTOUT reset were indirectly asserted and deasserted
all at the same time (for all the 3 PCIe card) with PCIe
enable and disable.
The 2 patch address this and introduce correct reset to control
reset line for the relevant PCIe line.

The last 2 patch add additional logic and support to assert
and deassert the PERSTOUT and also apply the required configuration
for 2-lanes mode.

2-lanes mode is implemented in DT by adding the required property
and by defining the "num-lanes" to 2.

Changes v5:
- Address formal comments from Bjorn
- Drop clk patch (handled in separate series)
- Add reference to clk changes
Changes v4:
- Improve DT split patch (drop unneeded property)
- Handle power_down PERSTOUT
Changes v3:
- Add Ack from Krzysztof
- Improve commit description of PCIe patch
- Use pcie->num_lanes instead of possible uninit variable num_lanes
Changes v2:
- Address typo regs -> reg in Documentation
- Address typo lan -> lane in Documentation
- Apply a suggested fix from Airoha for PCIe MUX configuration
  before PHY init
- Parse secondary reg in probe
- Add missing reset_status handling for inverted bits
- Move SCU to local handling in power_up
- Add check for max num-lanes for EN7581

Christian Marangi (2):
  dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
    2-lanes
  PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581

 .../bindings/pci/airoha,en7581-pcie.yaml      | 244 ++++++++++++++++++
 .../bindings/pci/mediatek-pcie-gen3.yaml      |  77 +-----
 drivers/pci/controller/pcie-mediatek-gen3.c   | 106 ++++++--
 3 files changed, 338 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml

-- 
2.53.0

[PATCH v5 1/2] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes

[Christian Marangi]

To permit proper documentation of required property to support PCIe
configured for 2-lanes mode, split the Airoha schema part from the
mediatek-gen3 schema to a dedicated schema.

A PCIe configured for 2-lanes mode require an additional reg for the
secondary PCIe to be configured and the airoha,scu phandle to correctly
configure the PCIe MUX.

Rework the mediatek-gen3 schema to drop any redundant constraint previsouly
introduced for Airoha PCIe properties.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
 .../bindings/pci/airoha,en7581-pcie.yaml      | 244 ++++++++++++++++++
 .../bindings/pci/mediatek-pcie-gen3.yaml      |  77 +-----
 2 files changed, 249 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
new file mode 100644
index 000000000000..78a181a3b599
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
@@ -0,0 +1,244 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/airoha,en7581-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gen3 PCIe controller on Airoha SoCs
+
+maintainers:
+  - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |+
+  PCIe Gen3 MAC controller for Airoha SoCs, it supports Gen3 speed
+  and compatible with Gen2, Gen1 speed.
+
+  This PCIe controller supports up to 256 MSI vectors, the MSI hardware
+  block diagram is as follows:
+
+                    +-----+
+                    | GIC |
+                    +-----+
+                       ^
+                       |
+                   port->irq
+                       |
+               +-+-+-+-+-+-+-+-+
+               |0|1|2|3|4|5|6|7| (PCIe intc)
+               +-+-+-+-+-+-+-+-+
+                ^ ^           ^
+                | |    ...    |
+        +-------+ +------+    +-----------+
+        |                |                |
+  +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
+  |0|1|...|30|31|  |0|1|...|30|31|  |0|1|...|30|31| (MSI sets)
+  +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
+   ^ ^      ^  ^    ^ ^      ^  ^    ^ ^      ^  ^
+   | |      |  |    | |      |  |    | |      |  |  (MSI vectors)
+   | |      |  |    | |      |  |    | |      |  |
+
+    (MSI SET0)       (MSI SET1)  ...   (MSI SET7)
+
+  With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
+  each set has its own address for MSI message, and supports 32 MSI vectors
+  to generate interrupt.
+
+properties:
+  compatible:
+    const: airoha,en7581-pcie
+
+  reg:
+    minItems: 1
+    maxItems: 2
+
+  reg-names:
+    minItems: 1
+    maxItems: 2
+
+  interrupts:
+    maxItems: 1
+
+  ranges:
+    maxItems: 1
+
+  resets:
+    minItems: 1
+    maxItems: 4
+
+  reset-names:
+    minItems: 1
+    maxItems: 4
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: sys-ck
+
+  phys:
+    maxItems: 1
+
+  phy-names:
+    items:
+      - const: pcie-phy
+
+  num-lanes:
+    enum: [1, 2]
+
+  mediatek,pbus-csr:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      - items:
+          - description: phandle to pbus-csr syscon
+          - description: offset of pbus-csr base address register
+          - description: offset of pbus-csr base address mask register
+    description:
+      Phandle with two arguments to the syscon node used to detect if
+      a given address is accessible on PCIe controller.
+
+  airoha,scu:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      - items:
+          - description: phandle to airoha SCU syscon
+    description:
+      Phandle to SCU syscon to configure PCIe MUX for 2 lines support.
+
+  '#interrupt-cells':
+    const: 1
+
+  interrupt-controller:
+    description: Interrupt controller node for handling INTx PCI interrupts.
+    type: object
+    properties:
+      '#address-cells':
+        const: 0
+      '#interrupt-cells':
+        const: 1
+      interrupt-controller: true
+
+    required:
+      - '#address-cells'
+      - '#interrupt-cells'
+      - interrupt-controller
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - ranges
+  - clocks
+  - clock-names
+  - '#interrupt-cells'
+  - interrupt-controller
+
+allOf:
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
+  - if:
+      properties:
+        num-lanes:
+          const: 2
+    then:
+      properties:
+        reg:
+          minItems: 2
+
+        reg-names:
+          items:
+            - const: pcie-mac
+            - const: sec-pcie-mac
+
+        resets:
+          minItems: 4
+
+        reset-names:
+          items:
+            - const: phy-lane0
+            - const: phy-lane1
+            - const: perstout
+            - const: sec-perstout
+
+      required:
+        - airoha,scu
+
+    else:
+      properties:
+        reg:
+          maxItems: 1
+
+        reg-names:
+          items:
+            - const: pcie-mac
+
+        resets:
+          minItems: 2
+          maxItems: 3
+
+        reset-names:
+          minItems: 2
+          items:
+            - enum: [ phy-lane0, phy-lane1, phy-lane2 ]
+            - enum: [ phy-lane1, perstout ]
+            - const: phy-lane2
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pcie@1fc00000 {
+            compatible = "airoha,en7581-pcie";
+            device_type = "pci";
+            #address-cells = <3>;
+            #size-cells = <2>;
+
+            reg = <0x0 0x1fc00000 0x0 0x1670>,
+                  <0x0 0x1fc20000 0x0 0x1670>;
+            reg-names = "pcie-mac", "sec-pcie-mac";
+
+            clocks = <&scuclk 7>;
+            clock-names = "sys-ck";
+
+            phys = <&pciephy>;
+            phy-names = "pcie-phy";
+
+            ranges = <0x02000000 0 0x20000000 0x0 0x20000000 0 0x4000000>;
+
+            resets = <&scuclk 48>,
+                     <&scuclk 49>,
+                     <&scuclk 53>,
+                     <&scuclk 54>;
+            reset-names = "phy-lane0", "phy-lane1",
+                          "perstout", "sec-perstout";
+
+            num-lanes = <2>;
+
+            mediatek,pbus-csr = <&pbus_csr 0x0 0x4>;
+
+            airoha,scu = <&scuclk>;
+
+            interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+            bus-range = <0x00 0xff>;
+            #interrupt-cells = <1>;
+            interrupt-map-mask = <0 0 0 0x7>;
+            interrupt-map = <0 0 0 1 &pcie_intc 0>,
+                            <0 0 0 2 &pcie_intc 1>,
+                            <0 0 0 3 &pcie_intc 2>,
+                            <0 0 0 4 &pcie_intc 3>;
+            pcie_intc: interrupt-controller {
+                      #address-cells = <0>;
+                      #interrupt-cells = <1>;
+                      interrupt-controller;
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 4db700fc36ba..510f1f2b1c5a 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -59,7 +59,6 @@ properties:
           - const: mediatek,mt8196-pcie
       - const: mediatek,mt8192-pcie
       - const: mediatek,mt8196-pcie
-      - const: airoha,en7581-pcie
 
   reg:
     maxItems: 1
@@ -83,20 +82,20 @@ properties:
 
   resets:
     minItems: 1
-    maxItems: 3
+    maxItems: 2
 
   reset-names:
     minItems: 1
-    maxItems: 3
+    maxItems: 2
     items:
-      enum: [ phy, mac, phy-lane0, phy-lane1, phy-lane2 ]
+      enum: [ phy, mac ]
 
   clocks:
-    minItems: 1
+    minItems: 4
     maxItems: 6
 
   clock-names:
-    minItems: 1
+    minItems: 4
     maxItems: 6
 
   assigned-clocks:
@@ -115,17 +114,6 @@ properties:
   power-domains:
     maxItems: 1
 
-  mediatek,pbus-csr:
-    $ref: /schemas/types.yaml#/definitions/phandle-array
-    items:
-      - items:
-          - description: phandle to pbus-csr syscon
-          - description: offset of pbus-csr base address register
-          - description: offset of pbus-csr base address mask register
-    description:
-      Phandle with two arguments to the syscon node used to detect if
-      a given address is accessible on PCIe controller.
-
   '#interrupt-cells':
     const: 1
 
@@ -177,16 +165,6 @@ allOf:
             - const: peri_26m
             - const: top_133m
 
-        resets:
-          minItems: 1
-          maxItems: 2
-
-        reset-names:
-          minItems: 1
-          maxItems: 2
-
-        mediatek,pbus-csr: false
-
   - if:
       properties:
         compatible:
@@ -208,16 +186,6 @@ allOf:
             - const: peri_26m
             - const: peri_mem
 
-        resets:
-          minItems: 1
-          maxItems: 2
-
-        reset-names:
-          minItems: 1
-          maxItems: 2
-
-        mediatek,pbus-csr: false
-
   - if:
       properties:
         compatible:
@@ -246,8 +214,6 @@ allOf:
             - const: phy
             - const: mac
 
-        mediatek,pbus-csr: false
-
   - if:
       properties:
         compatible:
@@ -257,7 +223,6 @@ allOf:
     then:
       properties:
         clocks:
-          minItems: 4
           maxItems: 4
 
         clock-names:
@@ -267,38 +232,6 @@ allOf:
             - const: peri_26m
             - const: top_133m
 
-        resets:
-          minItems: 1
-          maxItems: 2
-
-        reset-names:
-          minItems: 1
-          maxItems: 2
-
-        mediatek,pbus-csr: false
-
-  - if:
-      properties:
-        compatible:
-          const: airoha,en7581-pcie
-    then:
-      properties:
-        clocks:
-          maxItems: 1
-
-        clock-names:
-          items:
-            - const: sys-ck
-
-        resets:
-          minItems: 3
-
-        reset-names:
-          items:
-            - const: phy-lane0
-            - const: phy-lane1
-            - const: phy-lane2
-
 unevaluatedProperties: false
 
 examples:
-- 
2.53.0

[PATCH v5 2/2] PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581

[Christian Marangi]

The Airoha AN7581 SoC supports configuring the first PCIe0 lane to 2-lanes
mode (x2 link) by bonding it with the second PCIe lane (PCIe1). This is
done by configuring the PCIe MUX in the SCU register.

To correctly configure PCIe0 in x2 link, define in DT the following
additional properties:

  - additional reg, 'sec-pcie-mac' for the secondary PCIe.
  - PERSTOUT reset for both main and secondary PCIE0, called 'perstout' and
    'sec-perstout'
  - 'airoha,scu' property to correctly configure the SCU register for the
    PCIe MUX
  - 'num-lanes' set to '2' to enable PCIe0 in x2 link

In such configuration the EQ preset are configured to the same values.

To permit correct configuration of the PCIe link, additional logic is added
to assert and deassert the PERSTOUT resets. Support of these additional
reset was introduced in Airoha clk driver with commit
6712f48eb3a1 ("clk: en7523: add support for dedicated PCIe PERSTOUT reset")
and on backporting of this commit also the clk driver change will be
needed.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 106 ++++++++++++++++----
 1 file changed, 89 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index b0accd828589..c8300c47374b 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -32,6 +32,11 @@
 
 #include "../pci.h"
 
+/* AN7581 SCU register */
+#define SCU_PCIC			0x88
+#define SCU_PCIC_PCIE_CTRL		GENMASK(7, 0)
+
+/* PCIe register */
 #define PCIE_BASE_CFG_REG		0x14
 #define PCIE_BASE_CFG_SPEED		GENMASK(15, 8)
 
@@ -131,6 +136,7 @@
 #define PCIE_ATR_TLP_TYPE_IO		PCIE_ATR_TLP_TYPE(2)
 
 #define MAX_NUM_PHY_RESETS		3
+#define MAX_NUM_PERSTOUT_RESETS		2
 
 #define PCIE_MTK_RESET_TIME_US		10
 
@@ -203,9 +209,11 @@ struct mtk_msi_set {
 struct mtk_gen3_pcie {
 	struct device *dev;
 	void __iomem *base;
+	void __iomem *sec_base;
 	phys_addr_t reg_base;
 	struct reset_control *mac_reset;
 	struct reset_control_bulk_data phy_resets[MAX_NUM_PHY_RESETS];
+	struct reset_control_bulk_data perstout_resets[MAX_NUM_PERSTOUT_RESETS];
 	struct phy *phy;
 	struct clk_bulk_data *clks;
 	int num_clks;
@@ -928,6 +936,14 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
 	if (ret)
 		return dev_err_probe(dev, ret, "failed to get PHY bulk reset\n");
 
+	pcie->perstout_resets[0].id = "perstout";
+	pcie->perstout_resets[1].id = "sec-perstout";
+
+	ret = devm_reset_control_bulk_get_optional_exclusive(dev, MAX_NUM_PERSTOUT_RESETS,
+							     pcie->perstout_resets);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get PERSTOUT bulk reset\n");
+
 	pcie->mac_reset = devm_reset_control_get_optional_exclusive(dev, "mac");
 	if (IS_ERR(pcie->mac_reset))
 		return dev_err_probe(dev, PTR_ERR(pcie->mac_reset), "failed to get MAC reset\n");
@@ -949,18 +965,38 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
 			pcie->num_lanes = num_lanes;
 	}
 
+	/* Map secondary PCIe for 2-lanes mode for EN7581 */
+	if (pcie->num_lanes == 2 && device_is_compatible(dev, "airoha,en7581-pcie")) {
+		regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sec-pcie-mac");
+		if (!regs)
+			return -EINVAL;
+		pcie->sec_base = devm_ioremap_resource(dev, regs);
+		if (IS_ERR(pcie->sec_base))
+			return dev_err_probe(dev, PTR_ERR(pcie->sec_base), "failed to map secondary register base\n");
+	}
+
 	return 0;
 }
 
 static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
 {
 	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+	unsigned int num_lanes = max(1, pcie->num_lanes);
+	struct regmap *pbus_regmap, *scu;
 	struct device *dev = pcie->dev;
 	struct resource_entry *entry;
-	struct regmap *pbus_regmap;
 	u32 val, args[2], size;
 	resource_size_t addr;
-	int err;
+	int i, err;
+
+	if (num_lanes > 2)
+		return dev_err_probe(dev, -EINVAL, "unsupported num-lanes, maximum 2 lanes supported\n");
+
+	if (num_lanes == 2) {
+		scu = syscon_regmap_lookup_by_phandle(dev->of_node, "airoha,scu");
+		if (IS_ERR(scu))
+			return dev_err_probe(dev, PTR_ERR(scu), "failed to map SCU regmap\n");
+	}
 
 	/*
 	 * The controller may have been left out of reset by the bootloader
@@ -992,6 +1028,19 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
 	size = lower_32_bits(resource_size(entry->res));
 	regmap_write(pbus_regmap, args[1], GENMASK(31, __fls(size)));
 
+	/* Assert PERSTOUT for all relevant lanes */
+	err = reset_control_bulk_assert(MAX_NUM_PERSTOUT_RESETS,
+					pcie->perstout_resets);
+	if (err) {
+		dev_err(dev, "failed to assert PERSTOUTs\n");
+		return err;
+	}
+
+	/* Configure SCU MUX to disable PCIE1 for x2 lanes mode */
+	if (num_lanes == 2)
+		regmap_update_bits(scu, SCU_PCIC, SCU_PCIC_PCIE_CTRL,
+				   FIELD_PREP(SCU_PCIC_PCIE_CTRL, BIT(1)));
+
 	/*
 	 * Unlike the other MediaTek Gen3 controllers, the Airoha EN7581
 	 * requires PHY initialization and power-on before PHY reset deassert.
@@ -1024,18 +1073,6 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
 
-	val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
-	      FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
-	      FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
-	      FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
-	writel_relaxed(val, pcie->base + PCIE_EQ_PRESET_01_REG);
-
-	val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
-	      FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
-	      FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
-	      FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
-	writel_relaxed(val, pcie->base + PCIE_PIPE4_PIE8_REG);
-
 	err = clk_bulk_prepare_enable(pcie->num_clks, pcie->clks);
 	if (err) {
 		dev_err(dev, "failed to prepare clock\n");
@@ -1043,14 +1080,47 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
 	}
 
 	/*
-	 * Airoha EN7581 performs PCIe reset via clk callbacks since it has a
-	 * hw issue with PCIE_PE_RSTB signal. Add wait for the time needed to
-	 * complete the PCIe reset.
+	 * Old Airoha EN7581 clock driver performed PCIe reset via
+	 * clk callbacks since it has a hw issue with PCIE_PE_RSTB signal.
+	 * This is now handled by dedicated PERSTOUT resets with clk
+	 * driver only enabling the refclk.
+	 *
+	 * Wait is still needed for refclk to stabilize
 	 */
 	msleep(PCIE_T_PVPERL_MS);
 
+	/* Configure all the lanes to the same EQ config */
+	for (i = 0; i < num_lanes; i++) {
+		void __iomem *base = pcie->base;
+
+		if (i == 1)
+			base = pcie->sec_base;
+
+		val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
+			FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
+			FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
+			FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
+		writel_relaxed(val, base + PCIE_EQ_PRESET_01_REG);
+
+		val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
+			FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
+			FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
+			FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
+		writel_relaxed(val, base + PCIE_PIPE4_PIE8_REG);
+	}
+
+	/* Deassert PERSTOUT for all relevant lanes */
+	err = reset_control_bulk_deassert(MAX_NUM_PERSTOUT_RESETS,
+					  pcie->perstout_resets);
+	if (err) {
+		dev_err(dev, "failed to deassert PERSTOUTs\n");
+		goto err_perstout_deassert;
+	}
+
 	return 0;
 
+err_perstout_deassert:
+	clk_bulk_disable_unprepare(pcie->num_clks, pcie->clks);
 err_clk_prepare_enable:
 	pm_runtime_put_sync(dev);
 	pm_runtime_disable(dev);
@@ -1136,6 +1206,8 @@ static void mtk_pcie_power_down(struct mtk_gen3_pcie *pcie)
 
 	phy_power_off(pcie->phy);
 	phy_exit(pcie->phy);
+	reset_control_bulk_assert(MAX_NUM_PERSTOUT_RESETS,
+				  pcie->perstout_resets);
 	reset_control_bulk_assert(pcie->soc->phy_resets.num_resets,
 				  pcie->phy_resets);
 }
-- 
2.53.0

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Chen-Yu Tsai]

On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> This small series introduce support for 2-lanes mode for Airoha AN7581

Just a nitpick, but I would probably name this something else, like
"cross-controller lane-bonding mode" or "lane stealing"? PCIe already
has 2x lanes as a standard feature, so this naming is a bit confusing.
It's not like dual-LVDS display in which LVDS is only a single lane.


ChenYu

> SoC. This is needed for correctly functionality of Eagle WiFi Card
> normally attached to this SoC that require a 2-line PCIe card to
> correctly work (and give the proper performance)
>
> The first 2 patch address a limitation of the PCIe implementation
> where the PERSTOUT reset were indirectly asserted and deasserted
> all at the same time (for all the 3 PCIe card) with PCIe
> enable and disable.
> The 2 patch address this and introduce correct reset to control
> reset line for the relevant PCIe line.
>
> The last 2 patch add additional logic and support to assert
> and deassert the PERSTOUT and also apply the required configuration
> for 2-lanes mode.
>
> 2-lanes mode is implemented in DT by adding the required property
> and by defining the "num-lanes" to 2.
>
> Changes v5:
> - Address formal comments from Bjorn
> - Drop clk patch (handled in separate series)
> - Add reference to clk changes
> Changes v4:
> - Improve DT split patch (drop unneeded property)
> - Handle power_down PERSTOUT
> Changes v3:
> - Add Ack from Krzysztof
> - Improve commit description of PCIe patch
> - Use pcie->num_lanes instead of possible uninit variable num_lanes
> Changes v2:
> - Address typo regs -> reg in Documentation
> - Address typo lan -> lane in Documentation
> - Apply a suggested fix from Airoha for PCIe MUX configuration
>   before PHY init
> - Parse secondary reg in probe
> - Add missing reset_status handling for inverted bits
> - Move SCU to local handling in power_up
> - Add check for max num-lanes for EN7581
>
> Christian Marangi (2):
>   dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
>     2-lanes
>   PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
>
>  .../bindings/pci/airoha,en7581-pcie.yaml      | 244 ++++++++++++++++++
>  .../bindings/pci/mediatek-pcie-gen3.yaml      |  77 +-----
>  drivers/pci/controller/pcie-mediatek-gen3.c   | 106 ++++++--
>  3 files changed, 338 insertions(+), 89 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
>
> --
> 2.53.0
>
>

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Bjorn Helgaas]

On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > This small series introduce support for 2-lanes mode for Airoha AN7581
> 
> Just a nitpick, but I would probably name this something else, like
> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> has 2x lanes as a standard feature, so this naming is a bit confusing.
> It's not like dual-LVDS display in which LVDS is only a single lane.

I suggested the "2-lane" and "x2" terminology because I assumed the
result is what the PCIe spec would describe as a "x2 Link" consisting
of two Lanes. 

If that's not the case, maybe "cross-controller lane-bonding mode" or
"lane stealing" would be more accurate, but I don't know what those
mean, so if we use them I would also like to know what the result
looks like in standard PCIe terms.

> > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > normally attached to this SoC that require a 2-line PCIe card to
> > correctly work (and give the proper performance)
> >
> > The first 2 patch address a limitation of the PCIe implementation
> > where the PERSTOUT reset were indirectly asserted and deasserted
> > all at the same time (for all the 3 PCIe card) with PCIe
> > enable and disable.
> > The 2 patch address this and introduce correct reset to control
> > reset line for the relevant PCIe line.
> >
> > The last 2 patch add additional logic and support to assert
> > and deassert the PERSTOUT and also apply the required configuration
> > for 2-lanes mode.
> >
> > 2-lanes mode is implemented in DT by adding the required property
> > and by defining the "num-lanes" to 2.

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Christian Marangi (Ansuel)]

Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
<helgaas@kernel.org> ha scritto:
>
> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > This small series introduce support for 2-lanes mode for Airoha AN7581
> >
> > Just a nitpick, but I would probably name this something else, like
> > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > It's not like dual-LVDS display in which LVDS is only a single lane.
>
> I suggested the "2-lane" and "x2" terminology because I assumed the
> result is what the PCIe spec would describe as a "x2 Link" consisting
> of two Lanes.
>
> If that's not the case, maybe "cross-controller lane-bonding mode" or
> "lane stealing" would be more accurate, but I don't know what those
> mean, so if we use them I would also like to know what the result
> looks like in standard PCIe terms.
>

Mhhh I don't really like the term lane stealing. Also cross-controller
lane-bonding
might be a first. Even if correct it would complicate identification
of the feature
that at the end of the day configures the HW to provide a 2 lanes PCIe.

Consider that in such mode, the other PCIe controller gets disabled (this is
handled in DT) so it's effectively enabling the standard PCIe 2x lanes
and apply the HW configuration for it.

> > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > normally attached to this SoC that require a 2-line PCIe card to
> > > correctly work (and give the proper performance)
> > >
> > > The first 2 patch address a limitation of the PCIe implementation
> > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > all at the same time (for all the 3 PCIe card) with PCIe
> > > enable and disable.
> > > The 2 patch address this and introduce correct reset to control
> > > reset line for the relevant PCIe line.
> > >
> > > The last 2 patch add additional logic and support to assert
> > > and deassert the PERSTOUT and also apply the required configuration
> > > for 2-lanes mode.
> > >
> > > 2-lanes mode is implemented in DT by adding the required property
> > > and by defining the "num-lanes" to 2.

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Benjamin Larsson]

On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
> Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
> <helgaas@kernel.org> ha scritto:
>>
>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>
>>> Just a nitpick, but I would probably name this something else, like
>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>
>> I suggested the "2-lane" and "x2" terminology because I assumed the
>> result is what the PCIe spec would describe as a "x2 Link" consisting
>> of two Lanes.
>>
>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>> "lane stealing" would be more accurate, but I don't know what those
>> mean, so if we use them I would also like to know what the result
>> looks like in standard PCIe terms.
>>
> 
> Mhhh I don't really like the term lane stealing. Also cross-controller
> lane-bonding
> might be a first. Even if correct it would complicate identification
> of the feature
> that at the end of the day configures the HW to provide a 2 lanes PCIe.
> 
> Consider that in such mode, the other PCIe controller gets disabled (this is
> handled in DT) so it's effectively enabling the standard PCIe 2x lanes
> and apply the HW configuration for it.
> 
>>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
>>>> normally attached to this SoC that require a 2-line PCIe card to
>>>> correctly work (and give the proper performance)
>>>>
>>>> The first 2 patch address a limitation of the PCIe implementation
>>>> where the PERSTOUT reset were indirectly asserted and deasserted
>>>> all at the same time (for all the 3 PCIe card) with PCIe
>>>> enable and disable.
>>>> The 2 patch address this and introduce correct reset to control
>>>> reset line for the relevant PCIe line.
>>>>
>>>> The last 2 patch add additional logic and support to assert
>>>> and deassert the PERSTOUT and also apply the required configuration
>>>> for 2-lanes mode.
>>>>
>>>> 2-lanes mode is implemented in DT by adding the required property
>>>> and by defining the "num-lanes" to 2.
> 

Hi. Isnt this just pcie bifurcation?

Logically bifurcation would need to be disabled when using 2 lanes in 
one slot and enabled when 2 lanes are split between 2 pcie slots.

But I'm not really sure what value a bifurcation property would add. 
Isnt the current schema enough?

The mt7987 will need the same logic as it can also bifurcate one pcie slot.

MvH
Benjamin Larsson

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Christian Marangi (Ansuel)]

Il giorno dom 9 ago 2026 alle ore 16:08 Benjamin Larsson
<benjamin.larsson@genexis.eu> ha scritto:
>
> On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
> > Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
> > <helgaas@kernel.org> ha scritto:
> >>
> >> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> >>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >>>> This small series introduce support for 2-lanes mode for Airoha AN7581
> >>>
> >>> Just a nitpick, but I would probably name this something else, like
> >>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> >>> has 2x lanes as a standard feature, so this naming is a bit confusing.
> >>> It's not like dual-LVDS display in which LVDS is only a single lane.
> >>
> >> I suggested the "2-lane" and "x2" terminology because I assumed the
> >> result is what the PCIe spec would describe as a "x2 Link" consisting
> >> of two Lanes.
> >>
> >> If that's not the case, maybe "cross-controller lane-bonding mode" or
> >> "lane stealing" would be more accurate, but I don't know what those
> >> mean, so if we use them I would also like to know what the result
> >> looks like in standard PCIe terms.
> >>
> >
> > Mhhh I don't really like the term lane stealing. Also cross-controller
> > lane-bonding
> > might be a first. Even if correct it would complicate identification
> > of the feature
> > that at the end of the day configures the HW to provide a 2 lanes PCIe.
> >
> > Consider that in such mode, the other PCIe controller gets disabled (this is
> > handled in DT) so it's effectively enabling the standard PCIe 2x lanes
> > and apply the HW configuration for it.
> >
> >>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
> >>>> normally attached to this SoC that require a 2-line PCIe card to
> >>>> correctly work (and give the proper performance)
> >>>>
> >>>> The first 2 patch address a limitation of the PCIe implementation
> >>>> where the PERSTOUT reset were indirectly asserted and deasserted
> >>>> all at the same time (for all the 3 PCIe card) with PCIe
> >>>> enable and disable.
> >>>> The 2 patch address this and introduce correct reset to control
> >>>> reset line for the relevant PCIe line.
> >>>>
> >>>> The last 2 patch add additional logic and support to assert
> >>>> and deassert the PERSTOUT and also apply the required configuration
> >>>> for 2-lanes mode.
> >>>>
> >>>> 2-lanes mode is implemented in DT by adding the required property
> >>>> and by defining the "num-lanes" to 2.
> >
>
> Hi. Isnt this just pcie bifurcation?
>
> Logically bifurcation would need to be disabled when using 2 lanes in
> one slot and enabled when 2 lanes are split between 2 pcie slots.
>
> But I'm not really sure what value a bifurcation property would add.
> Isnt the current schema enough?
>
> The mt7987 will need the same logic as it can also bifurcate one pcie slot.
>

The documentation is not so kind on these kind of details... and no register
for bifurcation... maybe it's the mux one? But the mux settings comes from
reverse as in documentation that SCU register is a good 7:0 bits of
data value...

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Benjamin Larsson]

On 09/08/2026 16:14, Christian Marangi (Ansuel) wrote:
> Il giorno dom 9 ago 2026 alle ore 16:08 Benjamin Larsson
> <benjamin.larsson@genexis.eu> ha scritto:
>>
>> On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
>>> Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
>>> <helgaas@kernel.org> ha scritto:
>>>>
>>>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>>>
>>>>> Just a nitpick, but I would probably name this something else, like
>>>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>>>
>>>> I suggested the "2-lane" and "x2" terminology because I assumed the
>>>> result is what the PCIe spec would describe as a "x2 Link" consisting
>>>> of two Lanes.
>>>>
>>>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>>>> "lane stealing" would be more accurate, but I don't know what those
>>>> mean, so if we use them I would also like to know what the result
>>>> looks like in standard PCIe terms.
>>>>
>>>
>>> Mhhh I don't really like the term lane stealing. Also cross-controller
>>> lane-bonding
>>> might be a first. Even if correct it would complicate identification
>>> of the feature
>>> that at the end of the day configures the HW to provide a 2 lanes PCIe.
>>>
>>> Consider that in such mode, the other PCIe controller gets disabled (this is
>>> handled in DT) so it's effectively enabling the standard PCIe 2x lanes
>>> and apply the HW configuration for it.
>>>
>>>>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
>>>>>> normally attached to this SoC that require a 2-line PCIe card to
>>>>>> correctly work (and give the proper performance)
>>>>>>
>>>>>> The first 2 patch address a limitation of the PCIe implementation
>>>>>> where the PERSTOUT reset were indirectly asserted and deasserted
>>>>>> all at the same time (for all the 3 PCIe card) with PCIe
>>>>>> enable and disable.
>>>>>> The 2 patch address this and introduce correct reset to control
>>>>>> reset line for the relevant PCIe line.
>>>>>>
>>>>>> The last 2 patch add additional logic and support to assert
>>>>>> and deassert the PERSTOUT and also apply the required configuration
>>>>>> for 2-lanes mode.
>>>>>>
>>>>>> 2-lanes mode is implemented in DT by adding the required property
>>>>>> and by defining the "num-lanes" to 2.
>>>
>>
>> Hi. Isnt this just pcie bifurcation?
>>
>> Logically bifurcation would need to be disabled when using 2 lanes in
>> one slot and enabled when 2 lanes are split between 2 pcie slots.
>>
>> But I'm not really sure what value a bifurcation property would add.
>> Isnt the current schema enough?
>>
>> The mt7987 will need the same logic as it can also bifurcate one pcie slot.
>>
> 
> The documentation is not so kind on these kind of details... and no register
> for bifurcation... maybe it's the mux one? But the mux settings comes from
> reverse as in documentation that SCU register is a good 7:0 bits of
> data value...

Hi, yeah I think the SCU documentation is wrong for the AN7581. At least 
for the W1700k v1 device SoC version. It works without the SCU PCIC bit 
set there IIRC.

https://forum.openwrt.org/t/quantum-fiber-w1700k-support/222776/280

The vendor driver has this:
https://github.com/merbanan/airoha_pcie/blob/main/airoha_pcie/en7581/pcie-ecnt-phy_7581.c#L1671

Maybe this is the only bit that control the bifurcation?

MvH
Benjamin Larsson

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Chen-Yu Tsai]

On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > This small series introduce support for 2-lanes mode for Airoha AN7581
> >
> > Just a nitpick, but I would probably name this something else, like
> > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > It's not like dual-LVDS display in which LVDS is only a single lane.
>
> I suggested the "2-lane" and "x2" terminology because I assumed the
> result is what the PCIe spec would describe as a "x2 Link" consisting
> of two Lanes.
>
> If that's not the case, maybe "cross-controller lane-bonding mode" or
> "lane stealing" would be more accurate, but I don't know what those
> mean, so if we use them I would also like to know what the result
> looks like in standard PCIe terms.

Benjamin pointed out later in the thread that it is just bifurcation.

I would assume "PCIe bifurcation" is a standard term, so maybe we could
call this "Support un-bifurcated 2-lane operation"?

On the implementation side, having to reach into the second PCIe controller
is a bit messy :(


ChenYu

> > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > normally attached to this SoC that require a 2-line PCIe card to
> > > correctly work (and give the proper performance)
> > >
> > > The first 2 patch address a limitation of the PCIe implementation
> > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > all at the same time (for all the 3 PCIe card) with PCIe
> > > enable and disable.
> > > The 2 patch address this and introduce correct reset to control
> > > reset line for the relevant PCIe line.
> > >
> > > The last 2 patch add additional logic and support to assert
> > > and deassert the PERSTOUT and also apply the required configuration
> > > for 2-lanes mode.
> > >
> > > 2-lanes mode is implemented in DT by adding the required property
> > > and by defining the "num-lanes" to 2.

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Christian Marangi (Ansuel)]

Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
<wenst@chromium.org> ha scritto:
>
> On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > This small series introduce support for 2-lanes mode for Airoha AN7581
> > >
> > > Just a nitpick, but I would probably name this something else, like
> > > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > > It's not like dual-LVDS display in which LVDS is only a single lane.
> >
> > I suggested the "2-lane" and "x2" terminology because I assumed the
> > result is what the PCIe spec would describe as a "x2 Link" consisting
> > of two Lanes.
> >
> > If that's not the case, maybe "cross-controller lane-bonding mode" or
> > "lane stealing" would be more accurate, but I don't know what those
> > mean, so if we use them I would also like to know what the result
> > looks like in standard PCIe terms.
>
> Benjamin pointed out later in the thread that it is just bifurcation.
>

Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
team at times the SoC was created, and given how the internal documentation
these are just assumption and observation... Everyone can be correct and wrong.

> I would assume "PCIe bifurcation" is a standard term, so maybe we could
> call this "Support un-bifurcated 2-lane operation"?
>

And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
the standard meaning?

This terms is equally custom as the previous "cross-controller
lane-bonding mode"
and "lane stealing"

I want to be honest... I'm not following why we are trying in every
way possible to find
a standard meaning for an highly integrated PCIe controller for a vendor SoC.
It's not like there are devices shipped with PCIe slot where you can
insert whatever
card you want. (there is only a single RFB board but that is really to
debug stuff and
develop)

The SoC is designed to have WiFi cards attached and only a subset of them.
And some of them require 2 lanes mode to work with this special configuration.

Even the DT bindings are not that specific to the details... at the
end of the day
everything is modelled as simple as "num-lanes = <2>;"

And that is effectively what the HW gets configured to. If then a
robbery is done
internally to the HW to get the second lane with probably some criminal act and
some murder then those are just details. But unless we have a correct police
report on that (Documentation) we can't assume someone got shot in the
process.
(sorry for the joke around the stealing thing)

> On the implementation side, having to reach into the second PCIe controller
> is a bit messy :(
>

I can assure you vendor hide all kind of bad stuff behind single register...
It's just Airoha that loves to expose godzillion registers and configure
everything clearly... Something that most of the time is better than hiding
everything behind ATF with SCM commands (or even configure stuff
in bootloader from HW strap)

A bonding solution where 2 controllers are configured and then bonded might
also be problematic as for 2 lanes mode the configuration needs to be done
in the same time segment. (and that would introduce lots of complexity in
both DT and driver for the sake of just having an additional reset and
an additional reg)

Aside from these 2 point... I'm open to any kind of naming and change
but it seems sad to me to delay this feature for these details that would
only affect the commit description and nothing else... This is currently needed
for Eagle WiFi card to correctly works... With the current code it works but
sometimes it doesn't as the reset and configuration phase is not well defined.
This series fix exactly that to have stable functionality (tested on OpenWrt
from at least half a year)

> > > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > > normally attached to this SoC that require a 2-line PCIe card to
> > > > correctly work (and give the proper performance)
> > > >
> > > > The first 2 patch address a limitation of the PCIe implementation
> > > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > > all at the same time (for all the 3 PCIe card) with PCIe
> > > > enable and disable.
> > > > The 2 patch address this and introduce correct reset to control
> > > > reset line for the relevant PCIe line.
> > > >
> > > > The last 2 patch add additional logic and support to assert
> > > > and deassert the PERSTOUT and also apply the required configuration
> > > > for 2-lanes mode.
> > > >
> > > > 2-lanes mode is implemented in DT by adding the required property
> > > > and by defining the "num-lanes" to 2.

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Benjamin Larsson]

Hi.

On 10/08/2026 12:55, Christian Marangi (Ansuel) wrote:
> Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
>>
>> On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>
>>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>>
>>>> Just a nitpick, but I would probably name this something else, like
>>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>>
>>> I suggested the "2-lane" and "x2" terminology because I assumed the
>>> result is what the PCIe spec would describe as a "x2 Link" consisting
>>> of two Lanes.
>>>
>>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>>> "lane stealing" would be more accurate, but I don't know what those
>>> mean, so if we use them I would also like to know what the result
>>> looks like in standard PCIe terms.
>>
>> Benjamin pointed out later in the thread that it is just bifurcation.
>>
> 
> Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
> team at times the SoC was created, and given how the internal documentation
> these are just assumption and observation... Everyone can be correct and wrong.
> 
>> I would assume "PCIe bifurcation" is a standard term, so maybe we could
>> call this "Support un-bifurcated 2-lane operation"?
>>
> 
> And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
> the standard meaning?
> 
> This terms is equally custom as the previous "cross-controller
> lane-bonding mode"
> and "lane stealing"
> 
> I want to be honest... I'm not following why we are trying in every
> way possible to find
> a standard meaning for an highly integrated PCIe controller for a vendor SoC.
> It's not like there are devices shipped with PCIe slot where you can
> insert whatever
> card you want. (there is only a single RFB board but that is really to
> debug stuff and
> develop)
> 
> The SoC is designed to have WiFi cards attached and only a subset of them.
> And some of them require 2 lanes mode to work with this special configuration.
> 
> Even the DT bindings are not that specific to the details... at the
> end of the day
> everything is modelled as simple as "num-lanes = <2>;"
> 
Hi, I agree with Christian here. The property num-lanes will be able to 
describe all possible pcie configurations of the AN7581 and AN7563 SoCs 
(the AN7563 is using the same pci controller if I understand things 
correctly). Adding more properties will not make it less complex.

MvH
Benjamin Larsson

Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock

[Chen-Yu Tsai]

On Mon, Aug 10, 2026 at 6:55 PM Christian Marangi (Ansuel)
<ansuelsmth@gmail.com> wrote:
>
> Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
> >
> > On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > >
> > > On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > > This small series introduce support for 2-lanes mode for Airoha AN7581
> > > >
> > > > Just a nitpick, but I would probably name this something else, like
> > > > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > > > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > > > It's not like dual-LVDS display in which LVDS is only a single lane.
> > >
> > > I suggested the "2-lane" and "x2" terminology because I assumed the
> > > result is what the PCIe spec would describe as a "x2 Link" consisting
> > > of two Lanes.
> > >
> > > If that's not the case, maybe "cross-controller lane-bonding mode" or
> > > "lane stealing" would be more accurate, but I don't know what those
> > > mean, so if we use them I would also like to know what the result
> > > looks like in standard PCIe terms.
> >
> > Benjamin pointed out later in the thread that it is just bifurcation.
> >
>
> Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
> team at times the SoC was created, and given how the internal documentation
> these are just assumption and observation... Everyone can be correct and wrong.
>
> > I would assume "PCIe bifurcation" is a standard term, so maybe we could
> > call this "Support un-bifurcated 2-lane operation"?
> >
>
> And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
> the standard meaning?
>
> This terms is equally custom as the previous "cross-controller
> lane-bonding mode"
> and "lane stealing"
>
> I want to be honest... I'm not following why we are trying in every
> way possible to find
> a standard meaning for an highly integrated PCIe controller for a vendor SoC.
> It's not like there are devices shipped with PCIe slot where you can
> insert whatever
> card you want. (there is only a single RFB board but that is really to
> debug stuff and
> develop)
>
> The SoC is designed to have WiFi cards attached and only a subset of them.
> And some of them require 2 lanes mode to work with this special configuration.
>
> Even the DT bindings are not that specific to the details... at the
> end of the day
> everything is modelled as simple as "num-lanes = <2>;"
>
> And that is effectively what the HW gets configured to. If then a
> robbery is done
> internally to the HW to get the second lane with probably some criminal act and
> some murder then those are just details. But unless we have a correct police
> report on that (Documentation) we can't assume someone got shot in the
> process.
> (sorry for the joke around the stealing thing)
>
> > On the implementation side, having to reach into the second PCIe controller
> > is a bit messy :(
> >
>
> I can assure you vendor hide all kind of bad stuff behind single register...
> It's just Airoha that loves to expose godzillion registers and configure
> everything clearly... Something that most of the time is better than hiding
> everything behind ATF with SCM commands (or even configure stuff
> in bootloader from HW strap)
>
> A bonding solution where 2 controllers are configured and then bonded might
> also be problematic as for 2 lanes mode the configuration needs to be done
> in the same time segment. (and that would introduce lots of complexity in
> both DT and driver for the sake of just having an additional reset and
> an additional reg)
>
> Aside from these 2 point... I'm open to any kind of naming and change
> but it seems sad to me to delay this feature for these details that would
> only affect the commit description and nothing else... This is currently needed
> for Eagle WiFi card to correctly works... With the current code it works but
> sometimes it doesn't as the reset and configuration phase is not well defined.
> This series fix exactly that to have stable functionality (tested on OpenWrt
> from at least half a year)

It was not my intention to block this. Having worked on other MediaTek
SoCs on which the PCIe gen4 controller, supported by the same driver,
can do up to 2 lanes natively, the subject of the cover letter was a bit
confusing for me.

Now that you've explained it, everything is clear.

> > > > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > > > normally attached to this SoC that require a 2-line PCIe card to
> > > > > correctly work (and give the proper performance)
> > > > >
> > > > > The first 2 patch address a limitation of the PCIe implementation
> > > > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > > > all at the same time (for all the 3 PCIe card) with PCIe
> > > > > enable and disable.
> > > > > The 2 patch address this and introduce correct reset to control
> > > > > reset line for the relevant PCIe line.
> > > > >
> > > > > The last 2 patch add additional logic and support to assert
> > > > > and deassert the PERSTOUT and also apply the required configuration
> > > > > for 2-lanes mode.
> > > > >
> > > > > 2-lanes mode is implemented in DT by adding the required property
> > > > > and by defining the "num-lanes" to 2.