netdev - Re: [PATCH RFC net-next 03/20] net: phy: marvell: add PHY PTP support

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: <aMxsl4v-Aio6R20R@shell.armlinux.org.uk>
Date: Thu, 18 Sep 2025 21:33:27 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH RFC net-next 03/20] net: phy: marvell: add PHY PTP support

On Thu, Sep 18, 2025 at 10:12:02PM +0200, Andrew Lunn wrote:
> > +static u64 marvell_phy_tai_clock_read(struct device *dev,
> > +				      struct ptp_system_timestamp *sts)
> > +{
> > +	struct phy_device *phydev = to_phy_device(dev);
> > +	int err, oldpage, lo, hi;
> > +
> > +	oldpage = phy_select_page(phydev, MARVELL_PAGE_PTP_GLOBAL);
> > +	if (oldpage >= 0) {
> > +		/* 88e151x says to write 0x8e0e */
> > +		ptp_read_system_prets(sts);
> > +		err = __phy_write(phydev, PTPG_READPLUS_COMMAND, 0x8e0e);
> > +		ptp_read_system_postts(sts);
> > +		lo = __phy_read(phydev, PTPG_READPLUS_DATA);
> > +		hi = __phy_read(phydev, PTPG_READPLUS_DATA);
> > +	}
> > +	err = phy_restore_page(phydev, oldpage, err);
> > +
> > +	if (err || lo < 0 || hi < 0)
> > +		return 0;
> > +
> > +	return lo | hi << 16;
> 
> What happens when hi is >= 0x8000? Doesn't that result in undefined
> behaviour for 32 bit machines? The u64 result we are trying to return
> is big enough to hold the value. Does the hi need promoting to u64
> before doing the shift?

Good point - looking at the generated code, it gets sign-extended
to a 64 bit value. So, hi=0x8000 results in 0xffffffff8000XXXX
being returned.

Does it matter? There are two functions that call the cyclecounter
->read() method. timecounter_init() sets ->cycle_last from the
value, and timecounter_read_delta() does this:

	cycle_delta = (cycle_now - tc->cycle_last) & tc->cc->mask;

before updating ->cycle_last with the returned value. As the
mask is initialised thusly:

	tai->cyclecounter.mask = CYCLECOUNTER_MASK(32);

this masks off the sign-extended high 32-bits, giving us back
a value of 0x8000XXXX.

So, while the sign extension is undesirable, it has no effect on
the operation. Is it worth throwing casts in the code? I suspect
that's a matter of personal opinion.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!