lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250630162959.GA57523@horms.kernel.org>
Date: Mon, 30 Jun 2025 17:29:59 +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 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?

Flagged by Smatch.

>  				}
> -				eth->phy_scratch_ring = res_sram->start;
> -			} else {
> -				eth->phy_scratch_ring = res->start + MTK_ETH_SRAM_OFFSET;
>  			}
>  		}
>  	}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ