From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33AF31C5D57; Mon, 30 Jun 2025 18:20:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751307610; cv=none; b=YCyjJKhOSJxS/JU6oKPzhMJ+zed2uNHSHezQIw26GFljSlYWExCNdvdFRZvtYC97otYE4cynHxjmMbUvVpFEomroRToFGecsmmsPikzqVwzckeX3aOr1oewFnC3nm9Jzi3d6lMG8XmJRPW7rgtZhYgqBTjYTAw0LZFhL+eXZtGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751307610; c=relaxed/simple; bh=6Y5Q9o6niBc1wW/qQciLoEiC649aCdmS1pSCDEfqP0Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Et3Z71BZ+xiPTuh5sxy9s9ucBVgipxCt0oZq79U4MwFDnuRvZw/NPDFL8afS11/olhwv1ZcwPzUH8PF7W3Kh5U38g9LRi0EI344jNTXWwbJ4WjyRkx/Qg0MqR2KKB1982V5jCNviXwXe82m4KEy5EoTvpJY8iXE/LoIgt3YlO+E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.98.2) (envelope-from ) id 1uWJ6Y-000000006fR-2UuI; Mon, 30 Jun 2025 18:19:46 +0000 Date: Mon, 30 Jun 2025 19:19:42 +0100 From: Daniel Golle To: Simon Horman Cc: Felix Fietkau , Frank Wunderlich , Eric Woudstra , Elad Yifee , Bo-Cun Chen , Sky Huang , Sean Wang , Lorenzo Bianconi , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH net-next v2 3/3] net: ethernet: mtk_eth_soc: use genpool allocator for SRAM Message-ID: References: <61897c7a3dcc0b2976ec2118226c06c220b00a80.1751229149.git.daniel@makrotopia.org> <20250630162959.GA57523@horms.kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250630162959.GA57523@horms.kernel.org> 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 > > Signed-off-by: Frank Wunderlich > > Signed-off-by: Daniel Golle > > --- > > 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.