[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250701125133.GQ41770@horms.kernel.org>
Date: Tue, 1 Jul 2025 13:51:33 +0100
From: Simon Horman <horms@...nel.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Felix Fietkau <nbd@....name>,
Frank Wunderlich <frank-w@...lic-files.de>,
Eric Woudstra <ericwouds@...il.com>, Elad Yifee <eladwf@...il.com>,
Bo-Cun Chen <bc-bocun.chen@...iatek.com>,
Sky Huang <skylake.huang@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH net-next v2 3/3] net: ethernet: mtk_eth_soc: use genpool
allocator for SRAM
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:
> > On Sun, Jun 29, 2025 at 11:22:44PM +0100, Daniel Golle wrote:
> > > 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 <frank-w@...lic-files.de>
> > > Signed-off-by: Frank Wunderlich <frank-w@...lic-files.de>
> > > Signed-off-by: Daniel Golle <daniel@...rotopia.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
> >
> > ...
> >
> > > @@ -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.
Powered by blists - more mailing lists