On Mon, Jun 30, 2025 at 07:19:42PM +0100, Daniel Golle wrote:

On Mon, Jun 30, 2025 at 05:29:59PM +0100, Simon Horman wrote:

quoted

On Sun, Jun 29, 2025 at 11:22:44PM +0100, Daniel Golle wrote:

quoted

Use a dedicated "mmio-sram" and the genpool allocator instead of
open-coding SRAM allocation for DMA rings.
Keep support for legacy device trees but notify the user via a
warning to update.

Co-developed-by: Frank Wunderlich <redacted>
Signed-off-by: Frank Wunderlich <redacted>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: fix return type of mtk_dma_ring_alloc() in case of error

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 120 +++++++++++++-------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |   4 +-
 2 files changed, 84 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c

...

quoted

@@ -5117,16 +5148,27 @@ static int mtk_probe(struct platform_device *pdev)
 			err = -EINVAL;
 			goto err_destroy_sgmii;
 		}
+
 		if (MTK_HAS_CAPS(eth->soc->caps, MTK_SRAM)) {
-			if (mtk_is_netsys_v3_or_greater(eth)) {
-				res_sram = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-				if (!res_sram) {
-					err = -EINVAL;
-					goto err_destroy_sgmii;
+			eth->sram_pool = of_gen_pool_get(pdev->dev.of_node, "sram", 0);
+			if (!eth->sram_pool) {
+				if (!mtk_is_netsys_v3_or_greater(eth)) {
+					/*
+					 * Legacy support for missing 'sram' node in DT.
+					 * SRAM is actual memory and supports transparent access
+					 * just like DRAM. Hence we don't require __iomem being
+					 * set and don't need to use accessor functions to read from
+					 * or write to SRAM.
+					 */
+					eth->sram_base = (void __force *)eth->base +
+							 MTK_ETH_SRAM_OFFSET;
+					eth->phy_scratch_ring = res->start + MTK_ETH_SRAM_OFFSET;
+					dev_warn(&pdev->dev,
+						 "legacy DT: using hard-coded SRAM offset.\n");
+				} else {
+					dev_err(&pdev->dev, "Could not get SRAM pool\n");
+					return -ENODEV;

Hi Daniel,

Rather than returning, should this
jump to err_destroy_sgmii to avoid leaking resources?

Yes, you are right. I'll fix that in v3.

Thanks.