Re: [PATCH v2 net-next 0/3] change some statistics to 64-bit

[Simon Horman <horms@kernel.org>]

On Wed, Jun 25, 2025 at 02:22:54AM +0000, Wei Fang wrote:
> > On Tue, 24 Jun 2025 18:15:45 +0800 Wei Fang wrote:
> > > The port MAC counters of ENETC are 64-bit registers and the statistics
> > > of ethtool are also u64 type, so add enetc_port_rd64() helper function
> > > to read 64-bit statistics from these registers, and also change the
> > > statistics of ring to unsigned long type to be consistent with the
> > > statistics type in struct net_device_stats.
> > 
> > this series adds almost 100 sparse warnings please trying building it with C=1
> > --
> > pw-bot: cr
> 
> Hi Jakub,
> 
> Simon has posted a patch [1] to fix the sparse warnings. Do I need to wait until
> Simon's patch is applied to the net-next tree and then resend this patch set?
> 
> [1] https://lore.kernel.org/imx/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org/

Yes, I have confirmed that with patch[1] applied this patch-set
does not introduce any Sparse warnings (in my environment).

I noticed the Sparse warnings that are otherwise introduced when reviewing
v1 of this patchset which is why I crated patch[1].

The issue is that there is are long standing Sparse warnings - which
highlight a driver bug, albeit one that doesn't manifest with in tree
users. They is due to an unnecessary call to le64_to_cpu(). The warnings
are:

  .../enetc_hw.h:513:16: warning: cast to restricted __le64
  .../enetc_hw.h:513:16: warning: restricted __le64 degrades to integer
  .../enetc_hw.h:513:16: warning: cast to restricted __le64

Patches 2/3 and 3/3 multiply the incidence of the above 3 warnings because
they increase the callers of the inline function where the problem lies.

But I'd argue that, other than noise, they don't make things worse.
The bug doesn't manifest for in-tree users (and if it did, it would
have been manifesting anyway).

So I'd advocate accepting this series (or not) independent of resolving
the Sparse warnings. Which should disappear when patch[1], or some variant
thereof, is accepted (via net or directly into net-next).