linux-kernel - Re: [PATCH net-next v3 1/3] net: phy: qcom: Add PHY counter 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: <87cace03-dd5e-4624-9615-15f3babd1848@redhat.com>
Date: Thu, 17 Jul 2025 15:23:16 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Luo Jie <quic_luoj@...cinc.com>, Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
 Russell King <linux@...linux.org.uk>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 1/3] net: phy: qcom: Add PHY counter support

On 7/16/25 12:15 PM, Luo Jie wrote:
> On 7/16/2025 12:11 AM, Andrew Lunn wrote:
>>> +int qcom_phy_update_stats(struct phy_device *phydev,
>>> +			  struct qcom_phy_hw_stats *hw_stats)
>>> +{
>>> +	int ret;
>>> +	u32 cnt;
>>> +
>>> +	/* PHY 32-bit counter for RX packets. */
>>> +	ret = phy_read_mmd(phydev, MDIO_MMD_AN, QCA808X_MMD7_CNT_RX_PKT_15_0);
>>> +	if (ret < 0)
>>> +		return ret;
>>> +
>>> +	cnt = ret;
>>> +
>>> +	ret = phy_read_mmd(phydev, MDIO_MMD_AN, QCA808X_MMD7_CNT_RX_PKT_31_16);
>>> +	if (ret < 0)
>>> +		return ret;
>>
>> Does reading QCA808X_MMD7_CNT_RX_PKT_15_0 cause
>> QCA808X_MMD7_CNT_RX_PKT_31_16 to latch?
> 
> Checked with the hardware design team: The high 16-bit counter register
> does not latch when reading the low 16 bits.
> 
>>
>> Sometimes you need to read the high part, the low part, and then
>> reread the high part to ensure it has not incremented. But this is
>> only needed if the hardware does not latch.
>>
>> 	Andrew
> 
> Since the counter is configured to clear after reading, the clear action
> takes priority over latching the count. This means that when reading the
> low 16 bits, the high 16-bit counter value cannot increment, any new
> packet events occurring during the read will be recorded after the
> 16-bit counter is cleared.

Out of sheer ignorance and language bias on my side, based on the above
I would have assumed that the registers do latch ;)

> Therefore, the current sequence for reading the counter is correct and
> will not result in missed increments.

Andrew, looks good?

/P