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: <5132d023-2308-490b-a867-07445ae4ddbe@lunn.ch>
Date: Fri, 19 Sep 2025 03:47:59 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 09:33:27PM +0100, Russell King (Oracle) wrote:
> 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.

I doubt the static analysers can do such a detailed analysis. So at
some point we are going to get patches adding a cast. You could maybe
change hi to a signed 64. That would avoid adding a cast, while still
being O.K. to hold a negative error code from __phy_read().

	Andrew