From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Prepare for adding RZ/T2H SoC support by making the driver configuration
selectable via OF match data. While the RZ/V2H(P) and RZ/T2H use the same
version of the Synopsys DesignWare MAC (version 5.20), the hardware is
synthesized with different options. To accommodate these differences,
introduce a struct holding per-SoC configuration such as clock list,
number of clocks, TX clock rate control, and STMMAC flags, and retrieve
it from the device tree match entry during probe.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- No changes
---
.../stmicro/stmmac/dwmac-renesas-gbeth.c | 57 +++++++++++++++----
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
index df4ca897a60c..022e595a9e1b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-renesas-gbeth.c
@@ -16,12 +16,34 @@
#include <linux/clk.h>
#include <linux/device.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/reset.h>
+#include <linux/types.h>
#include "stmmac_platform.h"
+/**
+ * struct renesas_gbeth_of_data - OF data for Renesas GBETH
+ *
+ * @clks: Array of clock names
+ * @num_clks: Number of clocks
+ * @stmmac_flags: Flags for the stmmac driver
+ * @handle_reset: Flag to indicate if reset control is
+ * handled by the glue driver or core driver.
+ * @set_clk_tx_rate: Flag to indicate if Tx clock is fixed or
+ * set_clk_tx_rate is needed.
+ */
+struct renesas_gbeth_of_data {
+ const char * const *clks;
+ u8 num_clks;
+ u32 stmmac_flags;
+ bool handle_reset;
+ bool set_clk_tx_rate;
+};
+
struct renesas_gbeth {
+ const struct renesas_gbeth_of_data *of_data;
struct plat_stmmacenet_data *plat_dat;
struct reset_control *rstc;
struct device *dev;
@@ -70,6 +92,7 @@ static void renesas_gbeth_exit(struct platform_device *pdev, void *priv)
static int renesas_gbeth_probe(struct platform_device *pdev)
{
+ const struct renesas_gbeth_of_data *of_data;
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct device *dev = &pdev->dev;
@@ -91,14 +114,17 @@ static int renesas_gbeth_probe(struct platform_device *pdev)
if (!gbeth)
return -ENOMEM;
- plat_dat->num_clks = ARRAY_SIZE(renesas_gbeth_clks);
+ of_data = of_device_get_match_data(&pdev->dev);
+ gbeth->of_data = of_data;
+
+ plat_dat->num_clks = of_data->num_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];
+ plat_dat->clks[i].id = of_data->clks[i];
err = devm_clk_bulk_get(dev, plat_dat->num_clks, plat_dat->clks);
if (err < 0)
@@ -109,25 +135,36 @@ static int renesas_gbeth_probe(struct platform_device *pdev)
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);
+ if (of_data->handle_reset) {
+ gbeth->rstc = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(gbeth->rstc))
+ return PTR_ERR(gbeth->rstc);
+ }
gbeth->dev = dev;
gbeth->plat_dat = plat_dat;
plat_dat->bsp_priv = gbeth;
- plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ if (of_data->set_clk_tx_rate)
+ plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
plat_dat->init = renesas_gbeth_init;
plat_dat->exit = renesas_gbeth_exit;
- plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
- STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
- STMMAC_FLAG_SPH_DISABLE;
+ plat_dat->flags |= gbeth->of_data->stmmac_flags;
return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
}
+static const struct renesas_gbeth_of_data renesas_gbeth_of_data = {
+ .clks = renesas_gbeth_clks,
+ .num_clks = ARRAY_SIZE(renesas_gbeth_clks),
+ .handle_reset = true,
+ .set_clk_tx_rate = true,
+ .stmmac_flags = STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
+ STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP |
+ STMMAC_FLAG_SPH_DISABLE,
+};
+
static const struct of_device_id renesas_gbeth_match[] = {
- { .compatible = "renesas,rzv2h-gbeth", },
+ { .compatible = "renesas,rzv2h-gbeth", .data = &renesas_gbeth_of_data },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, renesas_gbeth_match);
--
2.51.0On Thu, Sep 04, 2025 at 09:39:48PM +0100, Prabhakar wrote: > plat_dat->init = renesas_gbeth_init; > plat_dat->exit = renesas_gbeth_exit; > - plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY | > - STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | > - STMMAC_FLAG_SPH_DISABLE; > + plat_dat->flags |= gbeth->of_data->stmmac_flags; You include the first two flags in your new device. I would like to see at least STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP always being set. The only reason we have the STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is to avoid changing existing behaviour and causing regressions. New stuff should always set this. If there is a reason not to have this set (e.g., PCS doesn't support it) then we need to make that a PCS property and extend phylink's EEE support. If there's something wrong in the setup that stmmac does for EEE, then I'd like to hear about it as well. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell, On Thu, Sep 4, 2025 at 9:49 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 04, 2025 at 09:39:48PM +0100, Prabhakar wrote: > > plat_dat->init = renesas_gbeth_init; > > plat_dat->exit = renesas_gbeth_exit; > > - plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY | > > - STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | > > - STMMAC_FLAG_SPH_DISABLE; > > + plat_dat->flags |= gbeth->of_data->stmmac_flags; > > You include the first two flags in your new device. I would like to see > at least STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP always being set. The only > reason we have the STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is to avoid > changing existing behaviour and causing regressions. New stuff should > always set this. > Me confused, STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is set in the new device [0]. The reason STMMAC_FLAG_SPH_DISABLE flag being dropped in the new device is SPHEN=1 in MAC HW feature reg for the new device. [0] https://lore.kernel.org/all/20250904203949.292066-4-prabhakar.mahadev-lad.rj@bp.renesas.com/ Cheers, Prabhakar > If there is a reason not to have this set (e.g., PCS doesn't support > it) then we need to make that a PCS property and extend phylink's EEE > support. If there's something wrong in the setup that stmmac does for > EEE, then I'd like to hear about it as well. > > Thanks. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Thu, Sep 04, 2025 at 10:10:32PM +0100, Lad, Prabhakar wrote: > Hi Russell, > > On Thu, Sep 4, 2025 at 9:49 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 04, 2025 at 09:39:48PM +0100, Prabhakar wrote: > > > plat_dat->init = renesas_gbeth_init; > > > plat_dat->exit = renesas_gbeth_exit; > > > - plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY | > > > - STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | > > > - STMMAC_FLAG_SPH_DISABLE; > > > + plat_dat->flags |= gbeth->of_data->stmmac_flags; > > > > You include the first two flags in your new device. I would like to see > > at least STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP always being set. The only > > reason we have the STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is to avoid > > changing existing behaviour and causing regressions. New stuff should > > always set this. > > > Me confused, STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is set in the new > device [0]. The reason STMMAC_FLAG_SPH_DISABLE flag being dropped in > the new device is SPHEN=1 in MAC HW feature reg for the new device. What I'm saying is I'd like to see: plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | gbeth->of_data->stmmac_flags; iow, it is set unconditionally, even if forgotten in a future patch. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell, On Thu, Sep 4, 2025 at 10:31 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 04, 2025 at 10:10:32PM +0100, Lad, Prabhakar wrote: > > Hi Russell, > > > > On Thu, Sep 4, 2025 at 9:49 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 04, 2025 at 09:39:48PM +0100, Prabhakar wrote: > > > > plat_dat->init = renesas_gbeth_init; > > > > plat_dat->exit = renesas_gbeth_exit; > > > > - plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY | > > > > - STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | > > > > - STMMAC_FLAG_SPH_DISABLE; > > > > + plat_dat->flags |= gbeth->of_data->stmmac_flags; > > > > > > You include the first two flags in your new device. I would like to see > > > at least STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP always being set. The only > > > reason we have the STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is to avoid > > > changing existing behaviour and causing regressions. New stuff should > > > always set this. > > > > > Me confused, STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP flag is set in the new > > device [0]. The reason STMMAC_FLAG_SPH_DISABLE flag being dropped in > > the new device is SPHEN=1 in MAC HW feature reg for the new device. > > What I'm saying is I'd like to see: > > plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | > gbeth->of_data->stmmac_flags; > > iow, it is set unconditionally, even if forgotten in a future patch. > Ah got you. Thank you for the clarification. Cheers, Prabhakar
© 2016 - 2025 Red Hat, Inc.