linux-kernel - Re: [RFC PATCH net-next v4 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

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: <aUrStfaYuOzjDky2@pie>
Date: Tue, 23 Dec 2025 17:34:45 +0000
From: Yao Zi <me@...ao.cc>
To: Andrew Lunn <andrew@...n.ch>
Cc: 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>,
	Frank <Frank.Sae@...or-comm.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Choong Yong Liang <yong.liang.choong@...ux.intel.com>,
	Chen-Yu Tsai <wens@...e.org>, Jisheng Zhang <jszhang@...nel.org>,
	Furong Xu <0x1207@...il.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Mingcong Bai <jeffbai@...c.io>,
	Kexy Biscuit <kexybiscuit@...c.io>, Runhua He <hua@...c.io>,
	Xi Ruoyao <xry111@...111.site>
Subject: Re: [RFC PATCH net-next v4 2/3] net: stmmac: Add glue driver for
 Motorcomm YT6801 ethernet controller

On Sun, Dec 21, 2025 at 09:42:20PM +0100, Andrew Lunn wrote:
> > +static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv *priv,
> > +				      u8 index,
> > +				      struct motorcomm_efuse_patch *patch)
> > +{
> > +	u8 buf[sizeof(*patch)], offset;
> > +	int i, ret;
> > +
> > +	for (i = 0; i < sizeof(*patch); i++) {
> > +		offset = EFUSE_PATCH_REGION_OFFSET + sizeof(*patch) * index + i;
> > +
> > +		ret = motorcomm_efuse_read_byte(priv, offset, &buf[i]);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	memcpy(patch, buf, sizeof(*patch));
> 
> Why do you write it into a temporary buffer and then copy it to patch?
> Why not put it straight into patch?

Originally I wanted to avoid possible violation of pointer aliasing
rules, so write the RAW data to an extra buffer and do a memcpy() later.

But we have -fno-strict-aliasing in kernel, even without it accessing
any objects with character type should be okay. I'll remove buf and
write to patch directly in v5.

> > +	ret = motorcomm_efuse_read_mac(priv, res.mac);
> > +	if (ret == -ENOENT) {
> > +		dev_warn(&pdev->dev, "eFuse contains no valid MAC address\n");
> > +		dev_warn(&pdev->dev, "fallback to random MAC address\n");
> > +
> > +		memset(res.mac, 0, sizeof(res.mac));
> 
> It is not clear how setting this to zero results in a random MAC
> address. Maybe actually call eth_random_addr()?

stmmac_check_ether_addr() would generate a random MAC address through
eth_random_addr() if res.mac is all zeroes. But I agree calling
eth_random_addr() directly here would be clearer, will do it in v5.

> 	 Andrew 

Thanks for your review, happy holiday!

Regards,
Yao Zi