[PATCH net-next v5 0/3] Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC

[PATCH net-next v5 0/3] Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Hi All,

This patch series adds support for the GBETH (Gigabit Ethernet) glue layer
driver for the Renesas RZ/V2H(P) SoC. The GBETH IP is integrated with
the Synopsys DesignWare MAC (version 5.20). The changes include updating
the device tree bindings, documenting the GBETH bindings, and adding the
DWMAC glue layer for the Renesas GBETH.

v4->v5
- Rebased the changes on net-next

v3->v4
- Fixed maxItems for interrupt-names property
- Maintained reverse christmas tree order in renesas_gbeth_clks_config
- Returned err in case of success in renesas_gbeth_probe()

v2->v3
- Fixed review comments from Rob and Russell

v1->v2
- Updated commit description for patch 2/3
- Updated tx/rx queue completion interrupt names
- Added clks_config callback

v1:
https://lore.kernel.org/all/20250302181808.728734-1-prabhakar.mahadev-lad.rj@bp.renesas.com/

Cheers,
Prabhakar

Lad Prabhakar (3):
  dt-bindings: net: dwmac: Increase 'maxItems' for 'interrupts' and
    'interrupt-names'
  dt-bindings: net: Document support for Renesas RZ/V2H(P) GBETH
  net: stmmac: Add DWMAC glue layer for Renesas GBETH

 .../bindings/net/renesas,r9a09g057-gbeth.yaml | 201 ++++++++++++++++++
 .../devicetree/bindings/net/snps,dwmac.yaml   |  25 ++-
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  11 +
 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 .../stmicro/stmmac/dwmac-renesas-gbeth.c      | 165 ++++++++++++++
 5 files changed, 394 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c

-- 
2.49.0

[PATCH net-next v5 1/3] dt-bindings: net: dwmac: Increase 'maxItems' for 'interrupts' and 'interrupt-names'

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Increase the `maxItems` value for the `interrupts` and `interrupt-names`
properties to 11 to support additional per-channel Tx/Rx completion
interrupts on the Renesas RZ/V2H(P) SoC, which features the
`snps,dwmac-5.20` IP.

Refactor the `interrupt-names` property by replacing repeated `enum`
entries with a `oneOf` list. Add support for per-channel receive and
transmit completion interrupts using regex patterns.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
v4->v5
- No change

v3->v4
- Fixed maxItems for interrupt-names property
- Added RB tag from Rob

v2->v3
- Dropped adding `additionalItems`
- Moved interrupts description into interrupt-names
- Replaced enum with a oneOf and added Rx/Tx regex patterns

v1->v2
- No change
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 24 ++++++++++++-------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 78b3030dc56d..4d4fcaeca8a8 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -114,19 +114,25 @@ properties:
 
   interrupts:
     minItems: 1
-    items:
-      - description: Combined signal for various interrupt events
-      - description: The interrupt to manage the remote wake-up packet detection
-      - description: The interrupt that occurs when Rx exits the LPI state
-      - description: The interrupt that occurs when HW safety error triggered
+    maxItems: 11
 
   interrupt-names:
     minItems: 1
+    maxItems: 11
     items:
-      - const: macirq
-      - enum: [eth_wake_irq, eth_lpi, sfty]
-      - enum: [eth_wake_irq, eth_lpi, sfty]
-      - enum: [eth_wake_irq, eth_lpi, sfty]
+      oneOf:
+        - description: Combined signal for various interrupt events
+          const: macirq
+        - description: The interrupt to manage the remote wake-up packet detection
+          const: eth_wake_irq
+        - description: The interrupt that occurs when Rx exits the LPI state
+          const: eth_lpi
+        - description: The interrupt that occurs when HW safety error triggered
+          const: sfty
+        - description: Per channel receive completion interrupt
+          pattern: '^rx-queue-[0-3]$'
+        - description: Per channel transmit completion interrupt
+          pattern: '^tx-queue-[0-3]$'
 
   clocks:
     minItems: 1
-- 
2.49.0

[PATCH net-next v5 2/3] dt-bindings: net: Document support for Renesas RZ/V2H(P) GBETH

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

GBETH IP on the Renesas RZ/V2H(P) SoC is integrated with Synopsys
DesignWare MAC (version 5.20). Document the device tree bindings for
the GBETH glue layer.

Generic compatible string 'renesas,rzv2h-gbeth' is added since this
module is identical on both the RZ/V2H(P) and RZ/G3E SoCs.

The Rx/Tx clocks supplied for GBETH on the RZ/V2H(P) SoC is depicted
below:

                      Rx / Tx
-------+------------- on / off -------
       |
       |            Rx-180 / Tx-180
       +---- not ---- on / off -------

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
v4->v5
- No change

v3->v4
- No change

v2->v3
- Dropped interrupts description from interrupts property as
  snps,dwmac.yaml already describes it.
- Dropped snps,en-tx-lpi-clockgating as this is being marked
  as deprecated.
- Updated Rx/Tx interrupt names to match the regex from patch 1/3
- Listed Rx interrupts before Tx interrupts in example node for
  consistency.

v1->v2
- Updated commit description
- Updated interrupts description for clarity
- Updated interrupt-names for clarity
- Updated example node
---
 .../bindings/net/renesas,r9a09g057-gbeth.yaml | 201 ++++++++++++++++++
 .../devicetree/bindings/net/snps,dwmac.yaml   |   1 +
 2 files changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml

diff --git a/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml b/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml
new file mode 100644
index 000000000000..02a6793c26f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml
@@ -0,0 +1,201 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,r9a09g057-gbeth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GBETH glue layer for Renesas RZ/V2H(P) (and similar SoCs)
+
+maintainers:
+  - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+select:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - renesas,r9a09g057-gbeth
+          - renesas,rzv2h-gbeth
+  required:
+    - compatible
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - renesas,r9a09g057-gbeth # RZ/V2H(P)
+      - const: renesas,rzv2h-gbeth
+      - const: snps,dwmac-5.20
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: CSR clock
+      - description: AXI system clock
+      - description: PTP clock
+      - description: TX clock
+      - description: RX clock
+      - description: TX clock phase-shifted by 180 degrees
+      - description: RX clock phase-shifted by 180 degrees
+
+  clock-names:
+    items:
+      - const: stmmaceth
+      - const: pclk
+      - const: ptp_ref
+      - const: tx
+      - const: rx
+      - const: tx-180
+      - const: rx-180
+
+  interrupts:
+    minItems: 11
+
+  interrupt-names:
+    items:
+      - const: macirq
+      - const: eth_wake_irq
+      - const: eth_lpi
+      - const: rx-queue-0
+      - const: rx-queue-1
+      - const: rx-queue-2
+      - const: rx-queue-3
+      - const: tx-queue-0
+      - const: tx-queue-1
+      - const: tx-queue-2
+      - const: tx-queue-3
+
+  resets:
+    items:
+      - description: AXI power-on system reset
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - interrupts
+  - interrupt-names
+  - resets
+
+allOf:
+  - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/renesas-cpg-mssr.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    ethernet@15c30000 {
+        compatible = "renesas,r9a09g057-gbeth", "renesas,rzv2h-gbeth", "snps,dwmac-5.20";
+        reg = <0x15c30000 0x10000>;
+        clocks =  <&cpg CPG_MOD 0xbd>, <&cpg CPG_MOD 0xbc>,
+                  <&ptp_clock>, <&cpg CPG_MOD 0xb8>,
+                  <&cpg CPG_MOD 0xb9>, <&cpg CPG_MOD 0xba>,
+                  <&cpg CPG_MOD 0xbb>;
+        clock-names = "stmmaceth", "pclk", "ptp_ref",
+                      "tx", "rx", "tx-180", "rx-180";
+        resets = <&cpg 0xb0>;
+        interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 767 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 772 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 745 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 768 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 770 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 771 IRQ_TYPE_LEVEL_HIGH>;
+        interrupt-names = "macirq", "eth_wake_irq", "eth_lpi",
+                          "rx-queue-0", "rx-queue-1", "rx-queue-2",
+                          "rx-queue-3", "tx-queue-0", "tx-queue-1",
+                          "tx-queue-2", "tx-queue-3";
+        phy-mode = "rgmii-id";
+        snps,multicast-filter-bins = <256>;
+        snps,perfect-filter-entries = <128>;
+        rx-fifo-depth = <8192>;
+        tx-fifo-depth = <8192>;
+        snps,fixed-burst;
+        snps,force_thresh_dma_mode;
+        snps,axi-config = <&stmmac_axi_setup>;
+        snps,mtl-rx-config = <&mtl_rx_setup>;
+        snps,mtl-tx-config = <&mtl_tx_setup>;
+        snps,txpbl = <32>;
+        snps,rxpbl = <32>;
+        phy-handle = <&phy0>;
+
+        stmmac_axi_setup: stmmac-axi-config {
+            snps,lpi_en;
+            snps,wr_osr_lmt = <0xf>;
+            snps,rd_osr_lmt = <0xf>;
+            snps,blen = <16 8 4 0 0 0 0>;
+        };
+
+        mtl_rx_setup: rx-queues-config {
+            snps,rx-queues-to-use = <4>;
+            snps,rx-sched-sp;
+
+            queue0 {
+                snps,dcb-algorithm;
+                snps,priority = <0x1>;
+                snps,map-to-dma-channel = <0>;
+            };
+
+            queue1 {
+                snps,dcb-algorithm;
+                snps,priority = <0x2>;
+                snps,map-to-dma-channel = <1>;
+            };
+
+            queue2 {
+                snps,dcb-algorithm;
+                snps,priority = <0x4>;
+                snps,map-to-dma-channel = <2>;
+            };
+
+            queue3 {
+                snps,dcb-algorithm;
+                snps,priority = <0x8>;
+                snps,map-to-dma-channel = <3>;
+            };
+        };
+
+        mtl_tx_setup: tx-queues-config {
+            snps,tx-queues-to-use = <4>;
+
+            queue0 {
+                snps,dcb-algorithm;
+                snps,priority = <0x1>;
+            };
+
+            queue1 {
+                snps,dcb-algorithm;
+                snps,priority = <0x2>;
+            };
+
+            queue2 {
+                snps,dcb-algorithm;
+                snps,priority = <0x4>;
+            };
+
+            queue3 {
+                snps,dcb-algorithm;
+                snps,priority = <0x1>;
+            };
+        };
+
+        mdio {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            compatible = "snps,dwmac-mdio";
+
+            phy0: ethernet-phy@0 {
+                reg = <0>;
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4d4fcaeca8a8..b525eca53850 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -75,6 +75,7 @@ properties:
         - qcom,sm8150-ethqos
         - renesas,r9a06g032-gmac
         - renesas,rzn1-gmac
+        - renesas,rzv2h-gbeth
         - rockchip,px30-gmac
         - rockchip,rk3128-gmac
         - rockchip,rk3228-gmac
-- 
2.49.0

[PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add the DWMAC glue layer for the GBETH IP found in the Renesas RZ/V2H(P)
SoC.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v4->v5
- No change

v3->v4
- Maintained reverse christmas tree order in renesas_gbeth_clks_config
- Returned err in case of success in renesas_gbeth_probe()

v2->v3
- Handle clks from plat_dat
- Replaced STMMAC_FLAG_EN_TX_LPI_CLOCKGATING flag with
  STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP.

v1->v2
- Dropped __initconst for renesas_gbeth_clks array
- Added clks_config callback
- Dropped STMMAC_FLAG_RX_CLK_RUNS_IN_LPI flag as this needs
  investigation.
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  11 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 .../stmicro/stmmac/dwmac-renesas-gbeth.c      | 165 ++++++++++++++++++
 3 files changed, 177 insertions(+)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 3c820ef56775..2c99b23f0faa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -131,6 +131,17 @@ config DWMAC_QCOM_ETHQOS
 	  This selects the Qualcomm ETHQOS glue layer support for the
 	  stmmac device driver.
 
+config DWMAC_RENESAS_GBETH
+	tristate "Renesas RZ/V2H(P) GBETH support"
+	default ARCH_RENESAS
+	depends on OF && (ARCH_RENESAS || COMPILE_TEST)
+	help
+	  Support for Gigabit Ethernet Interface (GBETH) on Renesas
+	  RZ/V2H(P) SoCs.
+
+	  This selects the Renesas RZ/V2H(P) Soc specific glue layer support
+	  for the stmmac device driver.
+
 config DWMAC_ROCKCHIP
 	tristate "Rockchip dwmac support"
 	default ARCH_ROCKCHIP
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 594883fb4164..91050215511b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DWMAC_LPC18XX)	+= dwmac-lpc18xx.o
 obj-$(CONFIG_DWMAC_MEDIATEK)	+= dwmac-mediatek.o
 obj-$(CONFIG_DWMAC_MESON)	+= dwmac-meson.o dwmac-meson8b.o
 obj-$(CONFIG_DWMAC_QCOM_ETHQOS)	+= dwmac-qcom-ethqos.o
+obj-$(CONFIG_DWMAC_RENESAS_GBETH) += dwmac-renesas-gbeth.o
 obj-$(CONFIG_DWMAC_ROCKCHIP)	+= dwmac-rk.o
 obj-$(CONFIG_DWMAC_RZN1)	+= dwmac-rzn1.o
 obj-$(CONFIG_DWMAC_S32)		+= dwmac-s32.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
new file mode 100644
index 000000000000..a0f7cacea810
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dwmac-renesas-gbeth.c - DWMAC Specific Glue layer for Renesas GBETH
+ *
+ * The Rx and Tx clocks are supplied as follows for the GBETH IP.
+ *
+ *                         Rx / Tx
+ *   -------+------------- on / off -------
+ *          |
+ *          |            Rx-180 / Tx-180
+ *          +---- not ---- on / off -------
+ *
+ * Copyright (C) 2025 Renesas Electronics Corporation
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#include "dwmac4.h"
+#include "stmmac_platform.h"
+
+struct renesas_gbeth {
+	struct plat_stmmacenet_data *plat_dat;
+	struct reset_control *rstc;
+	struct device *dev;
+	void __iomem *regs;
+};
+
+static const char *const renesas_gbeth_clks[] = {
+	"tx", "tx-180", "rx", "rx-180",
+};
+
+static struct clk *renesas_gbeth_find_clk(struct plat_stmmacenet_data *plat_dat,
+					  const char *name)
+{
+	for (unsigned int i = 0; i < plat_dat->num_clks; i++)
+		if (!strcmp(plat_dat->clks[i].id, name))
+			return plat_dat->clks[i].clk;
+
+	return NULL;
+}
+
+static int renesas_gbeth_clks_config(void *priv, bool enabled)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct renesas_gbeth *gbeth = priv;
+	int ret;
+
+	plat_dat = gbeth->plat_dat;
+	if (enabled) {
+		ret = reset_control_deassert(gbeth->rstc);
+		if (ret) {
+			dev_err(gbeth->dev, "Reset deassert failed\n");
+			return ret;
+		}
+
+		ret = clk_bulk_prepare_enable(plat_dat->num_clks, plat_dat->clks);
+		if (ret)
+			reset_control_assert(gbeth->rstc);
+	} else {
+		clk_bulk_disable_unprepare(plat_dat->num_clks, plat_dat->clks);
+		ret = reset_control_assert(gbeth->rstc);
+		if (ret)
+			dev_err(gbeth->dev, "Reset assert failed\n");
+	}
+
+	return ret;
+}
+
+static int renesas_gbeth_probe(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct stmmac_resources stmmac_res;
+	struct device *dev = &pdev->dev;
+	struct renesas_gbeth *gbeth;
+	unsigned int i;
+	int err;
+
+	err = stmmac_get_platform_resources(pdev, &stmmac_res);
+	if (err)
+		return dev_err_probe(dev, err,
+				     "failed to get resources\n");
+
+	plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac);
+	if (IS_ERR(plat_dat))
+		return dev_err_probe(dev, PTR_ERR(plat_dat),
+				     "dt configuration failed\n");
+
+	gbeth = devm_kzalloc(dev, sizeof(*gbeth), GFP_KERNEL);
+	if (!gbeth)
+		return -ENOMEM;
+
+	plat_dat->num_clks = ARRAY_SIZE(renesas_gbeth_clks);
+	plat_dat->clks = devm_kcalloc(dev, plat_dat->num_clks,
+				      sizeof(*plat_dat->clks), GFP_KERNEL);
+	if (!plat_dat->clks)
+		return -ENOMEM;
+
+	for (i = 0; i < plat_dat->num_clks; i++)
+		plat_dat->clks[i].id = renesas_gbeth_clks[i];
+
+	err = devm_clk_bulk_get(dev, plat_dat->num_clks, plat_dat->clks);
+	if (err < 0)
+		return err;
+
+	plat_dat->clk_tx_i = renesas_gbeth_find_clk(plat_dat, "tx");
+	if (!plat_dat->clk_tx_i)
+		return dev_err_probe(dev, -EINVAL,
+				     "error finding tx clock\n");
+
+	gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(gbeth->rstc))
+		return PTR_ERR(gbeth->rstc);
+
+	gbeth->dev = dev;
+	gbeth->regs = stmmac_res.addr;
+	gbeth->plat_dat = plat_dat;
+	plat_dat->bsp_priv = gbeth;
+	plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+	plat_dat->clks_config = renesas_gbeth_clks_config;
+	plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
+			   STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
+			   STMMAC_FLAG_SPH_DISABLE;
+
+	err = renesas_gbeth_clks_config(gbeth, true);
+	if (err)
+		return err;
+
+	err = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
+	if (err)
+		renesas_gbeth_clks_config(gbeth, false);
+
+	return err;
+}
+
+static void renesas_gbeth_remove(struct platform_device *pdev)
+{
+	stmmac_dvr_remove(&pdev->dev);
+
+	renesas_gbeth_clks_config(get_stmmac_bsp_priv(&pdev->dev), false);
+}
+
+static const struct of_device_id renesas_gbeth_match[] = {
+	{ .compatible = "renesas,rzv2h-gbeth", },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, renesas_gbeth_match);
+
+static struct platform_driver renesas_gbeth_driver = {
+	.probe  = renesas_gbeth_probe,
+	.remove = renesas_gbeth_remove,
+	.driver = {
+		.name		= "renesas-gbeth",
+		.pm		= &stmmac_pltfr_pm_ops,
+		.of_match_table	= renesas_gbeth_match,
+	},
+};
+module_platform_driver(renesas_gbeth_driver);
+
+MODULE_AUTHOR("Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>");
+MODULE_DESCRIPTION("Renesas GBETH DWMAC Specific Glue layer");
+MODULE_LICENSE("GPL");
-- 
2.49.0

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Russell King (Oracle)]

On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> +static struct clk *renesas_gbeth_find_clk(struct plat_stmmacenet_data *plat_dat,
> +					  const char *name)
> +{
> +	for (unsigned int i = 0; i < plat_dat->num_clks; i++)
> +		if (!strcmp(plat_dat->clks[i].id, name))
> +			return plat_dat->clks[i].clk;
> +
> +	return NULL;
> +}

In addition to Jakub's request, I'll ask that you hold off for a week
because I have the following that I'd like to submit:

bbc73b8b6dfd net: stmmac: provide stmmac_pltfr_find_clk()

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index c73eff6a56b8..43c869f64c39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -709,6 +709,17 @@ devm_stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 #endif /* CONFIG_OF */
 EXPORT_SYMBOL_GPL(devm_stmmac_probe_config_dt);

+struct clk *stmmac_pltfr_find_clk(struct plat_stmmacenet_data *plat_dat,
+                                 const char *name)
+{
+       for (int i = 0; i < plat_dat->num_clks; i++)
+               if (strcmp(plat_dat->clks[i].id, name) == 0)
+                       return plat_dat->clks[i].clk;
+
+       return NULL;
+}
+EXPORT_SYMBOL_GPL(stmmac_pltfr_find_clk);
+
...

which will avoid glue drivers duplicating this functionality. This will
be part of the first sets of patches I'm going to be submitting.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Lad, Prabhakar]

On Mon, Apr 7, 2025 at 6:58 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > +static struct clk *renesas_gbeth_find_clk(struct plat_stmmacenet_data *plat_dat,
> > +                                       const char *name)
> > +{
> > +     for (unsigned int i = 0; i < plat_dat->num_clks; i++)
> > +             if (!strcmp(plat_dat->clks[i].id, name))
> > +                     return plat_dat->clks[i].clk;
> > +
> > +     return NULL;
> > +}
>
> In addition to Jakub's request, I'll ask that you hold off for a week
> because I have the following that I'd like to submit:
>
Ack, please add me in Cc while you post this patch.

Cheers,
Prabhakar

> bbc73b8b6dfd net: stmmac: provide stmmac_pltfr_find_clk()
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index c73eff6a56b8..43c869f64c39 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -709,6 +709,17 @@ devm_stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
>  #endif /* CONFIG_OF */
>  EXPORT_SYMBOL_GPL(devm_stmmac_probe_config_dt);
>
> +struct clk *stmmac_pltfr_find_clk(struct plat_stmmacenet_data *plat_dat,
> +                                 const char *name)
> +{
> +       for (int i = 0; i < plat_dat->num_clks; i++)
> +               if (strcmp(plat_dat->clks[i].id, name) == 0)
> +                       return plat_dat->clks[i].clk;
> +
> +       return NULL;
> +}
> +EXPORT_SYMBOL_GPL(stmmac_pltfr_find_clk);
> +
> ...
>
> which will avoid glue drivers duplicating this functionality. This will
> be part of the first sets of patches I'm going to be submitting.
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Russell King (Oracle)]

On Mon, Apr 07, 2025 at 07:07:49PM +0100, Lad, Prabhakar wrote:
> On Mon, Apr 7, 2025 at 6:58 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > > +static struct clk *renesas_gbeth_find_clk(struct plat_stmmacenet_data *plat_dat,
> > > +                                       const char *name)
> > > +{
> > > +     for (unsigned int i = 0; i < plat_dat->num_clks; i++)
> > > +             if (!strcmp(plat_dat->clks[i].id, name))
> > > +                     return plat_dat->clks[i].clk;
> > > +
> > > +     return NULL;
> > > +}
> >
> > In addition to Jakub's request, I'll ask that you hold off for a week
> > because I have the following that I'd like to submit:
> >
> Ack, please add me in Cc while you post this patch.

FYI, the patch was merged last Thursday, so please update to replace
the above with stmmac_pltfr_find_clk() which will do this for you.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Lad, Prabhakar]

Hi Russell,

On Mon, Apr 14, 2025 at 3:31 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Apr 07, 2025 at 07:07:49PM +0100, Lad, Prabhakar wrote:
> > On Mon, Apr 7, 2025 at 6:58 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > > > +static struct clk *renesas_gbeth_find_clk(struct plat_stmmacenet_data *plat_dat,
> > > > +                                       const char *name)
> > > > +{
> > > > +     for (unsigned int i = 0; i < plat_dat->num_clks; i++)
> > > > +             if (!strcmp(plat_dat->clks[i].id, name))
> > > > +                     return plat_dat->clks[i].clk;
> > > > +
> > > > +     return NULL;
> > > > +}
> > >
> > > In addition to Jakub's request, I'll ask that you hold off for a week
> > > because I have the following that I'd like to submit:
> > >
> > Ack, please add me in Cc while you post this patch.
>
> FYI, the patch was merged last Thursday, so please update to replace
> the above with stmmac_pltfr_find_clk() which will do this for you.
>
Thanks, I'll rebase my changes on top of it and send out v6.

Cheers,
Prabhakar

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Paul Barker]

[-- Attachment #1.1.1: Type: text/plain, Size: 1465 bytes --]

Hi Prabhakar,

On 07/04/2025 13:03, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> 
> Add the DWMAC glue layer for the GBETH IP found in the Renesas RZ/V2H(P)
> SoC.
> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

[snip]

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
> new file mode 100644
> index 000000000000..a0f7cacea810
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
> @@ -0,0 +1,165 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dwmac-renesas-gbeth.c - DWMAC Specific Glue layer for Renesas GBETH
> + *
> + * The Rx and Tx clocks are supplied as follows for the GBETH IP.
> + *
> + *                         Rx / Tx
> + *   -------+------------- on / off -------
> + *          |
> + *          |            Rx-180 / Tx-180
> + *          +---- not ---- on / off -------
> + *
> + * Copyright (C) 2025 Renesas Electronics Corporation
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +#include "dwmac4.h"

I'm looking at this while working on RZ/T2H Ethernet support, clangd
says inclusion of dwmac4.h is not needed here and compilation succeeds
with the include removed.

Thanks,

-- 
Paul Barker

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3577 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Lad, Prabhakar]

Hi Paul,

On Mon, Apr 14, 2025 at 2:13 PM Paul Barker
<paul.barker.ct@bp.renesas.com> wrote:
>
> Hi Prabhakar,
>
> On 07/04/2025 13:03, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add the DWMAC glue layer for the GBETH IP found in the Renesas RZ/V2H(P)
> > SoC.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> [snip]
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
> > new file mode 100644
> > index 000000000000..a0f7cacea810
> > --- /dev/null
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
> > @@ -0,0 +1,165 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * dwmac-renesas-gbeth.c - DWMAC Specific Glue layer for Renesas GBETH
> > + *
> > + * The Rx and Tx clocks are supplied as follows for the GBETH IP.
> > + *
> > + *                         Rx / Tx
> > + *   -------+------------- on / off -------
> > + *          |
> > + *          |            Rx-180 / Tx-180
> > + *          +---- not ---- on / off -------
> > + *
> > + * Copyright (C) 2025 Renesas Electronics Corporation
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/reset.h>
> > +
> > +#include "dwmac4.h"
>
> I'm looking at this while working on RZ/T2H Ethernet support, clangd
> says inclusion of dwmac4.h is not needed here and compilation succeeds
> with the include removed.
>
Agreed, I will drop this.

Cheers,
Prabhakar

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Russell King (Oracle)]

On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> +	gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(gbeth->rstc))
> +		return PTR_ERR(gbeth->rstc);
> +
> +	gbeth->dev = dev;
> +	gbeth->regs = stmmac_res.addr;
> +	gbeth->plat_dat = plat_dat;
> +	plat_dat->bsp_priv = gbeth;
> +	plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> +	plat_dat->clks_config = renesas_gbeth_clks_config;
> +	plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
> +			   STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
> +			   STMMAC_FLAG_SPH_DISABLE;
> +
> +	err = renesas_gbeth_clks_config(gbeth, true);
> +	if (err)
> +		return err;
> +
> +	err = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
> +	if (err)
> +		renesas_gbeth_clks_config(gbeth, false);
> +
> +	return err;
> +}
> +
> +static void renesas_gbeth_remove(struct platform_device *pdev)
> +{
> +	stmmac_dvr_remove(&pdev->dev);
> +
> +	renesas_gbeth_clks_config(get_stmmac_bsp_priv(&pdev->dev), false);
> +}

Would calling renesas_gbeth_clks_config() in the suspend/resume paths
cause problems?

If not, please consider using plat_dat->init() and plat_dat->exit()
to control these clocks, and then use devm_stmmac_pltfr_probe()
which will call the ->init and ->exit functions around the probe
as necessary and at removal time (and you won't need the remove
method.)

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Lad, Prabhakar]

Hi Russell,

On Mon, Apr 14, 2025 at 5:57 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > +     gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
> > +     if (IS_ERR(gbeth->rstc))
> > +             return PTR_ERR(gbeth->rstc);
> > +
> > +     gbeth->dev = dev;
> > +     gbeth->regs = stmmac_res.addr;
> > +     gbeth->plat_dat = plat_dat;
> > +     plat_dat->bsp_priv = gbeth;
> > +     plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> > +     plat_dat->clks_config = renesas_gbeth_clks_config;
> > +     plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
> > +                        STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
> > +                        STMMAC_FLAG_SPH_DISABLE;
> > +
> > +     err = renesas_gbeth_clks_config(gbeth, true);
> > +     if (err)
> > +             return err;
> > +
> > +     err = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
> > +     if (err)
> > +             renesas_gbeth_clks_config(gbeth, false);
> > +
> > +     return err;
> > +}
> > +
> > +static void renesas_gbeth_remove(struct platform_device *pdev)
> > +{
> > +     stmmac_dvr_remove(&pdev->dev);
> > +
> > +     renesas_gbeth_clks_config(get_stmmac_bsp_priv(&pdev->dev), false);
> > +}
>
> Would calling renesas_gbeth_clks_config() in the suspend/resume paths
> cause problems?
>
> If not, please consider using plat_dat->init() and plat_dat->exit()
> to control these clocks, and then use devm_stmmac_pltfr_probe()
> which will call the ->init and ->exit functions around the probe
> as necessary and at removal time (and you won't need the remove
> method.)
>
I'll test this on the platform which can support suspend/resume and
update accordingly.

Cheers,
Prabhakar

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Lad, Prabhakar]

Hi Russell,

On Mon, Apr 14, 2025 at 7:14 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi Russell,
>
> On Mon, Apr 14, 2025 at 5:57 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > > +     gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
> > > +     if (IS_ERR(gbeth->rstc))
> > > +             return PTR_ERR(gbeth->rstc);
> > > +
> > > +     gbeth->dev = dev;
> > > +     gbeth->regs = stmmac_res.addr;
> > > +     gbeth->plat_dat = plat_dat;
> > > +     plat_dat->bsp_priv = gbeth;
> > > +     plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> > > +     plat_dat->clks_config = renesas_gbeth_clks_config;
> > > +     plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
> > > +                        STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
> > > +                        STMMAC_FLAG_SPH_DISABLE;
> > > +
> > > +     err = renesas_gbeth_clks_config(gbeth, true);
> > > +     if (err)
> > > +             return err;
> > > +
> > > +     err = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
> > > +     if (err)
> > > +             renesas_gbeth_clks_config(gbeth, false);
> > > +
> > > +     return err;
> > > +}
> > > +
> > > +static void renesas_gbeth_remove(struct platform_device *pdev)
> > > +{
> > > +     stmmac_dvr_remove(&pdev->dev);
> > > +
> > > +     renesas_gbeth_clks_config(get_stmmac_bsp_priv(&pdev->dev), false);
> > > +}
> >
> > Would calling renesas_gbeth_clks_config() in the suspend/resume paths
> > cause problems?
> >
> > If not, please consider using plat_dat->init() and plat_dat->exit()
> > to control these clocks, and then use devm_stmmac_pltfr_probe()
> > which will call the ->init and ->exit functions around the probe
> > as necessary and at removal time (and you won't need the remove
> > method.)
> >
On the RZ/G3E, the upstream support for testing S2R is not yet in a
usable state. So for now, I'll switch to using init/exit callbacks and
drop the PM callback.

Cheers,
Prabhakar

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi All,

> -----Original Message-----
> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> Sent: 15 April 2025 13:33
> Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> Hi Russell,
> 
> On Mon, Apr 14, 2025 at 7:14 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> >
> > Hi Russell,
> >
> > On Mon, Apr 14, 2025 at 5:57 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 01:03:17PM +0100, Prabhakar wrote:
> > > > +     gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
> > > > +     if (IS_ERR(gbeth->rstc))
> > > > +             return PTR_ERR(gbeth->rstc);
> > > > +
> > > > +     gbeth->dev = dev;
> > > > +     gbeth->regs = stmmac_res.addr;
> > > > +     gbeth->plat_dat = plat_dat;
> > > > +     plat_dat->bsp_priv = gbeth;
> > > > +     plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> > > > +     plat_dat->clks_config = renesas_gbeth_clks_config;
> > > > +     plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
> > > > +                        STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
> > > > +                        STMMAC_FLAG_SPH_DISABLE;
> > > > +
> > > > +     err = renesas_gbeth_clks_config(gbeth, true);
> > > > +     if (err)
> > > > +             return err;
> > > > +
> > > > +     err = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
> > > > +     if (err)
> > > > +             renesas_gbeth_clks_config(gbeth, false);
> > > > +
> > > > +     return err;
> > > > +}
> > > > +
> > > > +static void renesas_gbeth_remove(struct platform_device *pdev) {
> > > > +     stmmac_dvr_remove(&pdev->dev);
> > > > +
> > > > +     renesas_gbeth_clks_config(get_stmmac_bsp_priv(&pdev->dev),
> > > > +false); }
> > >
> > > Would calling renesas_gbeth_clks_config() in the suspend/resume
> > > paths cause problems?
> > >
> > > If not, please consider using plat_dat->init() and plat_dat->exit()
> > > to control these clocks, and then use devm_stmmac_pltfr_probe()
> > > which will call the ->init and ->exit functions around the probe as
> > > necessary and at removal time (and you won't need the remove
> > > method.)
> > >
> On the RZ/G3E, the upstream support for testing S2R is not yet in a usable state. So for now, I'll
> switch to using init/exit callbacks and drop the PM callback.

FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
I have done below changes on top of [1] to make STR working.

[1] https://lore.kernel.org/all/20250417084015.74154-4-prabhakar.mahadev-lad.rj@bp.renesas.com/

static int renesas_gbeth_init(struct platform_device *pdev, void *priv)
 {
+       struct net_device *ndev = platform_get_drvdata(pdev);
        struct plat_stmmacenet_data *plat_dat;
        struct renesas_gbeth *gbeth = priv;
        int ret;
@@ -50,6 +52,11 @@ static int renesas_gbeth_init(struct platform_device *pdev, void *priv)
        if (ret)
                reset_control_assert(gbeth->rstc);
 
+       if (gbeth->suspend) {
+               gbeth->suspend = false;
+               phy_init_hw(ndev->phydev);
+       }
+
        return ret;
 }
 
@@ -66,6 +73,8 @@ static void renesas_gbeth_exit(struct platform_device *pdev, void *priv)
        ret = reset_control_assert(gbeth->rstc);
        if (ret)
                dev_err(gbeth->dev, "Reset assert failed\n");
+
+       gbeth->suspend = true;
 }
 
 static int renesas_gbeth_probe(struct platform_device *pdev)
@@ -136,6 +145,7 @@ static struct platform_driver renesas_gbeth_driver = {
        .probe  = renesas_gbeth_probe,
        .driver = {
                .name           = "renesas-gbeth",
+               .pm             = &stmmac_pltfr_pm_ops,
                .of_match_table = renesas_gbeth_match,
        },
 };

Cheers,
Biju

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Andrew Lunn]

> > On the RZ/G3E, the upstream support for testing S2R is not yet in a usable state. So for now, I'll
> > switch to using init/exit callbacks and drop the PM callback.
> 
> FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> I have done below changes on top of [1] to make STR working.

Can you explain why you need to reinitialise the PHY? The MAC driver
should not need to do this, so something is wrong somewhere. If we
understand the 'Why?' we can probably tell you a better way to do
this.

	Andrew

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 21 April 2025 15:02
> Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> > > On the RZ/G3E, the upstream support for testing S2R is not yet in a
> > > usable state. So for now, I'll switch to using init/exit callbacks and drop the PM callback.
> >
> > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > I have done below changes on top of [1] to make STR working.
> 
> Can you explain why you need to reinitialise the PHY? The MAC driver should not need to do this, so
> something is wrong somewhere. If we understand the 'Why?' we can probably tell you a better way to do
> this.

Without this change bind/unbind works. But for the STR case, without reinitializing the PHY, even though
the IP link is UP, I am not able to talk the NFS server or ping the host properly.

I checked clock/reset before and after reset everything set as expected.

Only change during STR is, on wakeup we need to restore direction (MII/RGMII) of IO block 
for ET0/1_TXC_TXCLK (IO attribute) in the pin control driver. After that looks like PHY init
is required to talk to server. 

Cheers,
Biju

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> Sent: 21 April 2025 15:22
> Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 21 April 2025 15:02
> > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer
> > for Renesas GBETH
> >
> > > > On the RZ/G3E, the upstream support for testing S2R is not yet in
> > > > a usable state. So for now, I'll switch to using init/exit callbacks and drop the PM callback.
> > >
> > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > I have done below changes on top of [1] to make STR working.
> >
> > Can you explain why you need to reinitialise the PHY? The MAC driver
> > should not need to do this, so something is wrong somewhere. If we
> > understand the 'Why?' we can probably tell you a better way to do this.
> 
> Without this change bind/unbind works. But for the STR case, without reinitializing the PHY, even
> though the IP link is UP, I am not able to talk the NFS server or ping the host properly.
> 
> I checked clock/reset before and after reset everything set as expected.

Typo 'after reset'->'after STR'

> 
> Only change during STR is, on wakeup we need to restore direction (MII/RGMII) of IO block for
> ET0/1_TXC_TXCLK (IO attribute) in the pin control driver. After that looks like PHY init is required
> to talk to server.
> 
> Cheers,
> Biju

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Andrew Lunn]

On Mon, Apr 21, 2025 at 02:22:01PM +0000, Biju Das wrote:
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 21 April 2025 15:02
> > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> > 
> > > > On the RZ/G3E, the upstream support for testing S2R is not yet in a
> > > > usable state. So for now, I'll switch to using init/exit callbacks and drop the PM callback.
> > >
> > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > I have done below changes on top of [1] to make STR working.
> > 
> > Can you explain why you need to reinitialise the PHY? The MAC driver should not need to do this, so
> > something is wrong somewhere. If we understand the 'Why?' we can probably tell you a better way to do
> > this.
> 
> Without this change bind/unbind works. But for the STR case, without reinitializing the PHY, even though
> the IP link is UP, I am not able to talk the NFS server or ping the host properly.
> 
> I checked clock/reset before and after reset everything set as expected.
> 
> Only change during STR is, on wakeup we need to restore direction (MII/RGMII) of IO block 
> for ET0/1_TXC_TXCLK (IO attribute) in the pin control driver. After that looks like PHY init
> is required to talk to server. 

When talking about suspend/resume, is this with or without WoL?

If WoL is enabled for the PHY, the PHY is left running while the
system is suspended, and so all its clocks and reset lines also need
to be left enabled etc. On resume, there should not be any need to
touch the PHY.

If WoL is not enabled in the PHY, it should get powered off. On
resume, phylib should be reinitializing the PHY.

Which of these two cases need the reinitialisation?

The reasons i can think of for the PHY needing a reinitialization are:

1) It lost power when it did not expect to loose power
2) Got reset when it did not expect to be reset
3) Clock not ticking when it should of been ticking.

So you cannot just check clock/reset before and after, you need to
look at the order of events. The loss of power, or a reset after
phylib resumed the PHY would not be good. Similarly, if the needed
clocks are not ticking while phylib resumes it would also not be good.

I would also suggest you check the datasheet for the PHY, and does it
document anything about the clock input TXC_TXCLK is connected to?
Does it need to be ticking while configuring the PHY? Any action which
needs to be taken after this starts ticking? Is the pinctrl resume
being called before the PHY resume?

	Andrew

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 21 April 2025 16:12
> Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> On Mon, Apr 21, 2025 at 02:22:01PM +0000, Biju Das wrote:
> > Hi Andrew,
> >
> > > -----Original Message-----
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Sent: 21 April 2025 15:02
> > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue
> > > layer for Renesas GBETH
> > >
> > > > > On the RZ/G3E, the upstream support for testing S2R is not yet
> > > > > in a usable state. So for now, I'll switch to using init/exit callbacks and drop the PM
> callback.
> > > >
> > > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > > I have done below changes on top of [1] to make STR working.
> > >
> > > Can you explain why you need to reinitialise the PHY? The MAC driver
> > > should not need to do this, so something is wrong somewhere. If we
> > > understand the 'Why?' we can probably tell you a better way to do this.
> >
> > Without this change bind/unbind works. But for the STR case, without
> > reinitializing the PHY, even though the IP link is UP, I am not able to talk the NFS server or ping
> the host properly.
> >
> > I checked clock/reset before and after reset everything set as expected.
> >
> > Only change during STR is, on wakeup we need to restore direction
> > (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute) in the pin
> > control driver. After that looks like PHY init is required to talk to server.
> 
> When talking about suspend/resume, is this with or without WoL?

Without WoL.

> 
> If WoL is enabled for the PHY, the PHY is left running while the system is suspended, and so all its
> clocks and reset lines also need to be left enabled etc. On resume, there should not be any need to
> touch the PHY.

OK.

> 
> If WoL is not enabled in the PHY, it should get powered off. On resume, phylib should be
> reinitializing the PHY.

OK.

> 
> Which of these two cases need the reinitialisation?
> 
> The reasons i can think of for the PHY needing a reinitialization are:
> 
> 1) It lost power when it did not expect to loose power
> 2) Got reset when it did not expect to be reset
> 3) Clock not ticking when it should of been ticking.

OK.

> 
> So you cannot just check clock/reset before and after, you need to look at the order of events. The
> loss of power, or a reset after phylib resumed the PHY would not be good. Similarly, if the needed
> clocks are not ticking while phylib resumes it would also not be good.
> 
> I would also suggest you check the datasheet for the PHY, and does it document anything about the
> clock input TXC_TXCLK is connected to?

It is connected to TX_CTL on micrel phy.

> Does it need to be ticking while configuring the PHY? Any action which needs to be taken after this
> starts ticking? Is the pinctrl resume being called before the PHY resume?

Pinctrl resume is called before PHY resume

Previously STR did not work, because of not restoring direction (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute)
.Because of this, the direction of IO block is set to IN (input) MII mode instead of OUT(output) RGMII mode.

Now everything works. Thanks for your detailed pointers.

Cheers,
Biju

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Biju Das
> Sent: 21 April 2025 18:26
> Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 21 April 2025 16:12
> > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer
> > for Renesas GBETH
> >
> > On Mon, Apr 21, 2025 at 02:22:01PM +0000, Biju Das wrote:
> > > Hi Andrew,
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn <andrew@lunn.ch>
> > > > Sent: 21 April 2025 15:02
> > > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue
> > > > layer for Renesas GBETH
> > > >
> > > > > > On the RZ/G3E, the upstream support for testing S2R is not yet
> > > > > > in a usable state. So for now, I'll switch to using init/exit
> > > > > > callbacks and drop the PM
> > callback.
> > > > >
> > > > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > > > I have done below changes on top of [1] to make STR working.
> > > >
> > > > Can you explain why you need to reinitialise the PHY? The MAC
> > > > driver should not need to do this, so something is wrong
> > > > somewhere. If we understand the 'Why?' we can probably tell you a better way to do this.
> > >
> > > Without this change bind/unbind works. But for the STR case, without
> > > reinitializing the PHY, even though the IP link is UP, I am not able
> > > to talk the NFS server or ping
> > the host properly.
> > >
> > > I checked clock/reset before and after reset everything set as expected.
> > >
> > > Only change during STR is, on wakeup we need to restore direction
> > > (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute) in the
> > > pin control driver. After that looks like PHY init is required to talk to server.
> >
> > When talking about suspend/resume, is this with or without WoL?
> 
> Without WoL.
> 
> >
> > If WoL is enabled for the PHY, the PHY is left running while the
> > system is suspended, and so all its clocks and reset lines also need
> > to be left enabled etc. On resume, there should not be any need to touch the PHY.
> 
> OK.
> 
> >
> > If WoL is not enabled in the PHY, it should get powered off. On
> > resume, phylib should be reinitializing the PHY.
> 
> OK.
> 
> >
> > Which of these two cases need the reinitialisation?
> >
> > The reasons i can think of for the PHY needing a reinitialization are:
> >
> > 1) It lost power when it did not expect to loose power
> > 2) Got reset when it did not expect to be reset
> > 3) Clock not ticking when it should of been ticking.
> 
> OK.
> 
> >
> > So you cannot just check clock/reset before and after, you need to
> > look at the order of events. The loss of power, or a reset after
> > phylib resumed the PHY would not be good. Similarly, if the needed clocks are not ticking while
> phylib resumes it would also not be good.
> >
> > I would also suggest you check the datasheet for the PHY, and does it
> > document anything about the clock input TXC_TXCLK is connected to?
> 
> It is connected to TX_CTL on micrel phy.
> 
> > Does it need to be ticking while configuring the PHY? Any action which
> > needs to be taken after this starts ticking? Is the pinctrl resume being called before the PHY
> resume?
> 
> Pinctrl resume is called before PHY resume
> 
> Previously STR did not work, because of not restoring direction (MII/RGMII) of IO block for
> ET0/1_TXC_TXCLK (IO attribute) .Because of this, the direction of IO block is set to IN (input) MII
> mode instead of OUT(output) RGMII mode.
> 
> Now everything works. Thanks for your detailed pointers.

I need to debug this issue further as without reinitializing the PHY, the STR wakeup is not stable
(Linkup, but not able to contact the server).

[   34.572232] dwmac4: Master AXI performs fixed burst length
[   34.572232] renesas-gbeth 15c30000.ethernet eth0: No Safety Features support found
[   34.572232] renesas-gbeth 15c30000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   34.572232] renesas-gbeth 15c30000.ethernet eth0: configuring for phy/rgmii-id link mode
[   34.572232] OOM killer enabled.
[   34.572232] Restarting tasks ... done.
[   34.572232] random: crng reseeded on system resumption
[   34.572232] PM: suspend exit

root@smarc-rzg3e:~#
root@smarc-rzg3e:~# ls
[   34.572232] renesas-gbeth 15c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
root@smarc-rzg3e:~# [   34.572232] mmc2: Skipping voltage switch

root@smarc-rzg3e:~#
root@smarc-rzg3e:~#
root@smarc-rzg3e:~# ping 192.168.10.1

[   34.572232] nfs: server 192.168.10.1 not responding, still trying


Cheers,
Biju

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> Sent: 21 April 2025 18:50
> Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Biju Das
> > Sent: 21 April 2025 18:26
> > Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer
> > for Renesas GBETH
> >
> > Hi Andrew,
> >
> > > -----Original Message-----
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Sent: 21 April 2025 16:12
> > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue
> > > layer for Renesas GBETH
> > >
> > > On Mon, Apr 21, 2025 at 02:22:01PM +0000, Biju Das wrote:
> > > > Hi Andrew,
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Lunn <andrew@lunn.ch>
> > > > > Sent: 21 April 2025 15:02
> > > > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue
> > > > > layer for Renesas GBETH
> > > > >
> > > > > > > On the RZ/G3E, the upstream support for testing S2R is not
> > > > > > > yet in a usable state. So for now, I'll switch to using
> > > > > > > init/exit callbacks and drop the PM
> > > callback.
> > > > > >
> > > > > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > > > > I have done below changes on top of [1] to make STR working.
> > > > >
> > > > > Can you explain why you need to reinitialise the PHY? The MAC
> > > > > driver should not need to do this, so something is wrong
> > > > > somewhere. If we understand the 'Why?' we can probably tell you a better way to do this.
> > > >
> > > > Without this change bind/unbind works. But for the STR case,
> > > > without reinitializing the PHY, even though the IP link is UP, I
> > > > am not able to talk the NFS server or ping
> > > the host properly.
> > > >
> > > > I checked clock/reset before and after reset everything set as expected.
> > > >
> > > > Only change during STR is, on wakeup we need to restore direction
> > > > (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute) in the
> > > > pin control driver. After that looks like PHY init is required to talk to server.
> > >
> > > When talking about suspend/resume, is this with or without WoL?
> >
> > Without WoL.
> >
> > >
> > > If WoL is enabled for the PHY, the PHY is left running while the
> > > system is suspended, and so all its clocks and reset lines also need
> > > to be left enabled etc. On resume, there should not be any need to touch the PHY.
> >
> > OK.
> >
> > >
> > > If WoL is not enabled in the PHY, it should get powered off. On
> > > resume, phylib should be reinitializing the PHY.
> >
> > OK.
> >
> > >
> > > Which of these two cases need the reinitialisation?
> > >
> > > The reasons i can think of for the PHY needing a reinitialization are:
> > >
> > > 1) It lost power when it did not expect to loose power
> > > 2) Got reset when it did not expect to be reset
> > > 3) Clock not ticking when it should of been ticking.
> >
> > OK.
> >
> > >
> > > So you cannot just check clock/reset before and after, you need to
> > > look at the order of events. The loss of power, or a reset after
> > > phylib resumed the PHY would not be good. Similarly, if the needed
> > > clocks are not ticking while
> > phylib resumes it would also not be good.
> > >
> > > I would also suggest you check the datasheet for the PHY, and does
> > > it document anything about the clock input TXC_TXCLK is connected to?
> >
> > It is connected to TX_CTL on micrel phy.
> >
> > > Does it need to be ticking while configuring the PHY? Any action
> > > which needs to be taken after this starts ticking? Is the pinctrl
> > > resume being called before the PHY
> > resume?
> >
> > Pinctrl resume is called before PHY resume
> >
> > Previously STR did not work, because of not restoring direction
> > (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute) .Because of
> > this, the direction of IO block is set to IN (input) MII mode instead of OUT(output) RGMII mode.
> >
> > Now everything works. Thanks for your detailed pointers.
> 
> I need to debug this issue further as without reinitializing the PHY, the STR wakeup is not stable
> (Linkup, but not able to contact the server).

Looks like the issue is timing related. By comparing the working and non-working logs

On Working case, PHY resume happens after proper initialization of gbeth.

whereas on non-working case, 2 times PHY resume is called, one before proper initialization
and other after that. 

Working case logs: code change, see[1]
--------------------------------------

[   33.928696] CPU3: Booted secondary processor 0x0000000300 [0x412fd050]
[   33.928696] CPU3 is up
[   33.928696] ########rzg2l_pinctrl_resume_noirq 3216
[   33.928696] ########renesas_gbeth_init 55
[   33.928696] dwmac4: Master AXI performs fixed burst length
[   33.928696] renesas-gbeth 15c30000.ethernet eth0: No Safety Features support found
[   33.928696] renesas-gbeth 15c30000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   33.928696] renesas-gbeth 15c30000.ethernet eth0: configuring for phy/rgmii-id link mode
[   33.928696] ########kszphy_resume 2181
[   33.928696] OOM killer enabled.

[   33.928696] Restarting tasks ... done.
root@smarc-rzg3e[   33.928696] random: crng reseeded on system resumption
:~# [   33.928696] PM: suspend exit

root@smarc-rzg3e:~# [   33.928696] renesas-gbeth 15c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

root@smarc-rzg3e:~# [   33.928696] mmc2: Skipping voltage switch

root@smarc-rzg3e:~# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.381 ms
^C
--- 192.168.10.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.381/0.381/0.381/0.000 ms
root@smarc-rzg3e:~#

No working case logs:  code change, see[2]
-----------------------------------------

[   42.485978] CPU3: Booted secondary processor 0x0000000300 [0x412fd050]
[   42.485978] CPU3 is up
[   42.485978] ########rzg2l_pinctrl_resume_noirq 3216
[   42.485978] ########renesas_gbeth_init 55
[   42.485978] ########kszphy_resume 2181
[   42.485978] dwmac4: Master AXI performs fixed burst length
[   42.485978] renesas-gbeth 15c30000.ethernet eth0: No Safety Features support found
[   42.485978] renesas-gbeth 15c30000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   42.485978] renesas-gbeth 15c30000.ethernet eth0: configuring for phy/rgmii-id link mode
[   42.485978] ########kszphy_resume 2181
[   42.485978] OOM killer enabled.
[   42.485978] Restarting tasks ... done.

[   42.485978] random: crng reseeded on system resumption
[   42.485978] PM: suspend exit
root@smarc-rzg3e:~# [   42.485978] renesas-gbeth 15c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

root@smarc-rzg3e:~# [   42.485978] mmc2: Skipping voltage switch
ping 192.168.10.1
[   42.485978] nfs: server 192.168.10.1 not responding, still trying


[1]
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
index df4ca897a60c..021f34116a4f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
@@ -25,6 +25,8 @@ struct renesas_gbeth {
        struct plat_stmmacenet_data *plat_dat;
        struct reset_control *rstc;
        struct device *dev;
+
+       bool suspend;
 };
 
 static const char *const renesas_gbeth_clks[] = {
@@ -49,6 +51,14 @@ static int renesas_gbeth_init(struct platform_device *pdev, void *priv)
                                      plat_dat->clks);
        if (ret)
                reset_control_assert(gbeth->rstc);
+               
+       pr_err("########%s %d",__func__,__LINE__);
+       if (gbeth->suspend) {
+               struct net_device *ndev = platform_get_drvdata(pdev);
+
+               gbeth->suspend = false;
+               phy_init_hw(ndev->phydev);
+       }
 
        return ret;
 }
@@ -66,6 +76,8 @@ static void renesas_gbeth_exit(struct platform_device *pdev, void *priv)
        ret = reset_control_assert(gbeth->rstc);
        if (ret)
                dev_err(gbeth->dev, "Reset assert failed\n");
+
+       gbeth->suspend = true;
 }
 
 static int renesas_gbeth_probe(struct platform_device *pdev)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 71fb4410c31b..741b5a7f7b93 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -2178,6 +2178,8 @@ static int kszphy_resume(struct phy_device *phydev)
                        phydev->drv->config_intr(phydev);
        }
 
+       pr_err("########%s %d",__func__,__LINE__);
+       
        return 0;
 }
 
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index 4ea798cf78cf..e94f3fa7bb64 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -3213,6 +3213,7 @@ static int rzg2l_pinctrl_resume_noirq(struct device *dev)
        int i;
        int ret;
 
+       pr_err("########%s %d",__func__,__LINE__);
        if (!atomic_read(&pctrl->wakeup_path)) {
                ret = clk_prepare_enable(pctrl->clk);
                if (ret)

[2]
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
index df4ca897a60c..c31c6c715818 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
@@ -25,6 +25,8 @@ struct renesas_gbeth {
        struct plat_stmmacenet_data *plat_dat;
        struct reset_control *rstc;
        struct device *dev;
+
+       bool suspend;
 };
 
 static const char *const renesas_gbeth_clks[] = {
@@ -49,6 +51,14 @@ static int renesas_gbeth_init(struct platform_device *pdev, void *priv)
                                      plat_dat->clks);
        if (ret)
                reset_control_assert(gbeth->rstc);
+               
+       pr_err("########%s %d",__func__,__LINE__);
+       //if (gbeth->suspend) {
+       //      struct net_device *ndev = platform_get_drvdata(pdev);
+
+       //      gbeth->suspend = false;
+       //      phy_init_hw(ndev->phydev);
+       //}
 
        return ret;
 }
@@ -66,6 +76,8 @@ static void renesas_gbeth_exit(struct platform_device *pdev, void *priv)
        ret = reset_control_assert(gbeth->rstc);
        if (ret)
                dev_err(gbeth->dev, "Reset assert failed\n");
+
+       gbeth->suspend = true;
 }
 
 static int renesas_gbeth_probe(struct platform_device *pdev)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 71fb4410c31b..741b5a7f7b93 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -2178,6 +2178,8 @@ static int kszphy_resume(struct phy_device *phydev)
                        phydev->drv->config_intr(phydev);
        }
 
+       pr_err("########%s %d",__func__,__LINE__);
+       
        return 0;
 }
 
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index 4ea798cf78cf..e94f3fa7bb64 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -3213,6 +3213,7 @@ static int rzg2l_pinctrl_resume_noirq(struct device *dev)
        int i;
        int ret;
 
+       pr_err("########%s %d",__func__,__LINE__);
        if (!atomic_read(&pctrl->wakeup_path)) {
                ret = clk_prepare_enable(pctrl->clk);
                if (ret)

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 21 April 2025 15:02
> Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> > > On the RZ/G3E, the upstream support for testing S2R is not yet in a
> > > usable state. So for now, I'll switch to using init/exit callbacks and drop the PM callback.
> >
> > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > I have done below changes on top of [1] to make STR working.
> 
> Can you explain why you need to reinitialise the PHY? The MAC driver should not need to do this, so
> something is wrong somewhere. If we understand the 'Why?' we can probably tell you a better way to do
> this.

You are right, reinitialization of PHY is not required.

I can confirm STR works only by adding just [1] + Restoring the direction (MII/RGMII) of IO block for
ET0/1_TXC_TXCLK (IO attribute) in the pinctrl driver.

[1]:
+		.pm		= &stmmac_pltfr_pm_ops,


Logs:
  34.081297] PM: suspend entry (deep)
[   34.086010] Filesystems sync: 0.000 seconds
[   34.094746] Freezing user space processes
[   34.101104] Freezing user space processes completed (elapsed 0.002 seconds)
[   34.108164] OOM killer disabled.
[   34.111468] Freezing remaining freezable tasks
[   34.117478] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[   34.124888] printk: Suspending console(s) (use no_console_suspend to debug)
NOTICE:  BL2: v2.10.5(release):9aa8ec5-dirty
NOTICE:  BL2: Built : 14:47:04, Feb  7 2025
NOTICE:  BL2: SYS_LSI_MODE: 0x13e06
NOTICE:  BL2: SYS_LSI_DEVID: 0x8679447
NOTICE:  BL2: SYS_LSI_PRR: 0x0
NOTICE:  BL2: Booting BL31
[   34.202183] renesas-gbeth 15c30000.ethernet eth0: Link is Down
[   34.328938] Disabling non-boot CPUs ...
[   34.338285] psci: CPU3 killed (polled 4 ms)
[   34.352108] psci: CPU2 killed (polled 0 ms)
[   34.368492] psci: CPU1 killed (polled 0 ms)
[   34.378137] Enabling non-boot CPUs ...
[   34.378137] Detected VIPT I-cache on CPU1
[   34.378137] GICv3: CPU1: found redistributor 100 region 0:0x0000000014960000
[   34.378137] CPU1: Booted secondary processor 0x0000000100 [0x412fd050]
[   34.378137] CPU1 is up
[   34.378137] Detected VIPT I-cache on CPU2
[   34.378137] GICv3: CPU2: found redistributor 200 region 0:0x0000000014980000
[   34.378137] CPU2: Booted secondary processor 0x0000000200 [0x412fd050]
[   34.378137] CPU2 is up
[   34.378137] Detected VIPT I-cache on CPU3
[   34.378137] GICv3: CPU3: found redistributor 300 region 0:0x00000000149a0000
[   34.378137] CPU3: Booted secondary processor 0x0000000300 [0x412fd050]
[   34.378137] CPU3 is up
[   34.378137] dwmac4: Master AXI performs fixed burst length
[   34.378137] renesas-gbeth 15c30000.ethernet eth0: No Safety Features support found
[   34.378137] renesas-gbeth 15c30000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   34.378137] renesas-gbeth 15c30000.ethernet eth0: configuring for phy/rgmii-id link mode
[   34.378137] OOM killer enabled.
[   34.378137] Restarting tasks ... done.
[   34.378137] random: crng reseeded on system resumption
[   34.378137] PM: suspend exit

root@smarc-rzg3e:~# ping[   34.378137] renesas-gbeth 15c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
 [   34.378137] mmc2: Skipping voltage switch

root@smarc-rzg3e:~# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.751 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.858 ms
^C
--- 192.168.10.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss,

Cheers,
Biju

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Russell King (Oracle)]

On Mon, Apr 21, 2025 at 01:45:50PM +0000, Biju Das wrote:
> Hi All,
> FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.

Which "mainline" are you using?

Reading your emails, I suspect v6.14 rather than something post-dating
v6.15-rc1, since your latest email suggests that the PHY driver's
->resume method is not being called early in stmmac's resume. However,
commits 367f1854d442 and ef43e5132895 made this happen, which were
merged during the merge window, and are thus in v6.15-rc1.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Russell,

> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 21 April 2025 20:00
> Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> On Mon, Apr 21, 2025 at 01:45:50PM +0000, Biju Das wrote:
> > Hi All,
> > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> 
> Which "mainline" are you using?
> 
> Reading your emails, I suspect v6.14 rather than something post-dating v6.15-rc1, since your latest
> email suggests that the PHY driver's
> ->resume method is not being called early in stmmac's resume. However,
> commits 367f1854d442 and ef43e5132895 made this happen, which were merged during the merge window, and
> are thus in v6.15-rc1.

I am using Linux version 6.15.0-rc2-next-20250417 + renesas_defconfig with CONFIG_PROVE_LOCKING enabled.

Cheers,
Biju

RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Biju Das]

Hi Russell,

> -----Original Message-----
> From: Biju Das
> Sent: 21 April 2025 20:06
> Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> 
> Hi Russell,
> 
> > -----Original Message-----
> > From: Russell King <linux@armlinux.org.uk>
> > Sent: 21 April 2025 20:00
> > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer
> > for Renesas GBETH
> >
> > On Mon, Apr 21, 2025 at 01:45:50PM +0000, Biju Das wrote:
> > > Hi All,
> > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> >
> > Which "mainline" are you using?
> >
> > Reading your emails, I suspect v6.14 rather than something post-dating
> > v6.15-rc1, since your latest email suggests that the PHY driver's
> > ->resume method is not being called early in stmmac's resume. However,
> > commits 367f1854d442 and ef43e5132895 made this happen, which were
> > merged during the merge window, and are thus in v6.15-rc1.
> 
> I am using Linux version 6.15.0-rc2-next-20250417 + renesas_defconfig with CONFIG_PROVE_LOCKING
> enabled.

For me, it looks like issue related to timing, see[1] for details

[1] https://lore.kernel.org/all/TY3PR01MB1134690619EC6CADD07CD2DE186B82@TY3PR01MB11346.jpnprd01.prod.outlook.com/

Please let me know, if you have any patch that I can try out to fix the random timing issue.

Cheers,
Biju

Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

[Russell King (Oracle)]

On Mon, Apr 21, 2025 at 07:23:52PM +0000, Biju Das wrote:
> Hi Russell,
> 
> > -----Original Message-----
> > From: Biju Das
> > Sent: 21 April 2025 20:06
> > Subject: RE: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> > 
> > Hi Russell,
> > 
> > > -----Original Message-----
> > > From: Russell King <linux@armlinux.org.uk>
> > > Sent: 21 April 2025 20:00
> > > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer
> > > for Renesas GBETH
> > >
> > > On Mon, Apr 21, 2025 at 01:45:50PM +0000, Biju Das wrote:
> > > > Hi All,
> > > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > >
> > > Which "mainline" are you using?
> > >
> > > Reading your emails, I suspect v6.14 rather than something post-dating
> > > v6.15-rc1, since your latest email suggests that the PHY driver's
> > > ->resume method is not being called early in stmmac's resume. However,
> > > commits 367f1854d442 and ef43e5132895 made this happen, which were
> > > merged during the merge window, and are thus in v6.15-rc1.
> > 
> > I am using Linux version 6.15.0-rc2-next-20250417 + renesas_defconfig with CONFIG_PROVE_LOCKING
> > enabled.
> 
> For me, it looks like issue related to timing, see[1] for details
> 
> [1] https://lore.kernel.org/all/TY3PR01MB1134690619EC6CADD07CD2DE186B82@TY3PR01MB11346.jpnprd01.prod.outlook.com/
> 
> Please let me know, if you have any patch that I can try out to fix the random timing issue.

That's the email that provoked me to reply this evening (I wouldn't have
because I'm still on vacation.)

So, this is how things are supposed to be working:
- stmmac_phy_setup() sets phylink_config.mac_managed_pm and
  phylink_config.mac_requires_rxc to be true. The former disables phylib
  based power management.

- You've hooked in stmmac_pltfr_pm_ops.
- On resume, this will call stmmac_pltfr_resume().
- stmmac_pltfr_resume() will call your ->init function followed by
  stmmac_resume().
- stmmac_resume() will call phylink_prepare_resume().
- phylink_prepare_resume() will call phy_resume() to resume the PHY
  if pl->config->mac_requires_rxc && phydev && phydev->suspended is
  true. The first and second will be true. The third... depends.

For phydev->suspended to be true, phy_suspend() needs to have been
called. Neither mdio_bus_phy_suspend() nor mdio_bus_phy_resume()
should be having any effect as phydev->mac_managed_pm should be
set (as a result of phylink_config.mac_managed_pm having been set.)

phy_suspend() also gets called from phy_detach() and
_phy_state_machine_post_work() when the work is PHY_STATE_WORK_SUSPEND.
This happens when we halt the PHY, which will happen if phy_stop() is
called.

phylink_suspend() will do this only when WoL is not active - calling
it when WoL is active will prevent WoL from working as the PHY needs
to stay awake to (1) detect WoL packets if it is programmed to do
so, or (2) pass packets to the MAC in the case where the MAC is doing
WoL.

So, phy_resume() should be getting called for the !WoL case, which will
result in the PHY driver's ->resume method being called - in your case
kszphy_resume().

This will occur synchronously, and after gbeth's ->init function has
been called, and as its all in the same thread of execution, it should
be 100% reliable.

For the WoL case, we assume that the PHY retains its settings since it
needs to remain powered up, and because it hasn't been suspended or
shutdown, it should be retaining all settings when the system wakes up.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v5 0/3] Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC

[Jakub Kicinski]

On Mon,  7 Apr 2025 13:03:14 +0100 Prabhakar wrote:
> This patch series adds support for the GBETH (Gigabit Ethernet) glue layer
> driver for the Renesas RZ/V2H(P) SoC. The GBETH IP is integrated with
> the Synopsys DesignWare MAC (version 5.20). The changes include updating
> the device tree bindings, documenting the GBETH bindings, and adding the
> DWMAC glue layer for the Renesas GBETH.

This was posted prior to the "net-next is OPEN" announcement:
https://lore.kernel.org/all/20250407055403.7a8f40df@kernel.org/

In the interest of fairness towards those who correctly wait 
for the tree to be open I will ask you to repost this again,
in a couple of days.

Thanks!
-- 
pw-bot: defer

Re: [PATCH net-next v5 0/3] Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC

[Lad, Prabhakar]

Hi Jakub,

On Mon, Apr 7, 2025 at 6:44 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  7 Apr 2025 13:03:14 +0100 Prabhakar wrote:
> > This patch series adds support for the GBETH (Gigabit Ethernet) glue layer
> > driver for the Renesas RZ/V2H(P) SoC. The GBETH IP is integrated with
> > the Synopsys DesignWare MAC (version 5.20). The changes include updating
> > the device tree bindings, documenting the GBETH bindings, and adding the
> > DWMAC glue layer for the Renesas GBETH.
>
> This was posted prior to the "net-next is OPEN" announcement:
> https://lore.kernel.org/all/20250407055403.7a8f40df@kernel.org/
>
> In the interest of fairness towards those who correctly wait
> for the tree to be open I will ask you to repost this again,
> in a couple of days.
>
Are you ok for me to now respin this series?

Cheers,
Prabhakar

Re: [PATCH net-next v5 0/3] Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC

[Jakub Kicinski]

On Mon, 14 Apr 2025 09:52:03 +0100 Lad, Prabhakar wrote:
> > On Mon,  7 Apr 2025 13:03:14 +0100 Prabhakar wrote:  
> > > This patch series adds support for the GBETH (Gigabit Ethernet) glue layer
> > > driver for the Renesas RZ/V2H(P) SoC. The GBETH IP is integrated with
> > > the Synopsys DesignWare MAC (version 5.20). The changes include updating
> > > the device tree bindings, documenting the GBETH bindings, and adding the
> > > DWMAC glue layer for the Renesas GBETH.  
> >
> > This was posted prior to the "net-next is OPEN" announcement:
> > https://lore.kernel.org/all/20250407055403.7a8f40df@kernel.org/
> >
> > In the interest of fairness towards those who correctly wait
> > for the tree to be open I will ask you to repost this again,
> > in a couple of days.
> >  
> Are you ok for me to now respin this series?

yessir