netdev - Re: [net-next,v10,3/3] net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family

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] [day] [month] [year] [list]

Message-ID: <20260131015008.970729-1-kuba@kernel.org>
Date: Fri, 30 Jan 2026 17:50:08 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: a0987203069@...il.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	openbmc@...ts.ozlabs.org,
	ychuang3@...oton.com,
	andrew+netdev@...n.ch,
	linux-stm32@...md-mailman.stormreply.com,
	yclu4@...oton.com,
	pabeni@...hat.com,
	davem@...emloft.net,
	andrew@...n.ch,
	peppe.cavallaro@...com,
	joabreu@...opsys.com,
	linux-kernel@...r.kernel.org,
	conor+dt@...nel.org,
	richardcochran@...il.com,
	krzk+dt@...nel.org,
	edumazet@...gle.com,
	robh@...nel.org,
	schung@...oton.com,
	netdev@...r.kernel.org,
	mcoquelin.stm32@...il.com,
	alexandre.torgue@...s.st.com
Subject: Re: [net-next,v10,3/3] net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family

Adds Gigabit Ethernet support for Nuvoton MA35 series SoCs using
the stmmac driver framework.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-nuvoton.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-nuvoton.c
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-nuvoton.c

[ ... ]

> +static struct nvt_priv_data *
> +nvt_gmac_setup(struct platform_device *pdev, struct plat_stmmacenet_data *plat)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct nvt_priv_data *bsp_priv;

[ ... ]

> +	bsp_priv->regmap =
> +		syscon_regmap_lookup_by_phandle_args(dev->of_node, "nuvoton,sys", 1, &macid);
> +	if (IS_ERR(bsp_priv->regmap)) {
> +		dev_err_probe(dev, PTR_ERR(bsp_priv->regmap), "Failed to get sys register\n");
> +		return ERR_PTR(-ENODEV);
                           ^^^^^^

Should this propagate the actual error code from
syscon_regmap_lookup_by_phandle_args() instead of always returning
-ENODEV? If the syscon lookup returns -EPROBE_DEFER, this will lose
that error code and prevent the driver from properly deferring its
probe when dependencies aren't ready yet.

Other dwmac drivers (dwmac-loongson1, dwmac-starfive, dwmac-sun8i) use
something like:

    return dev_err_probe(dev, PTR_ERR(regmap), "...\n");

or

    return PTR_ERR(regmap);

to propagate the error.

> +	}

[ ... ]
-- 
pw-bot: cr