RE: [PATCH v6 net-next 14/15] net: dsa: netc: add support for the standardized counters

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to
> consider:
> - [Medium] Reading 64-bit hardware statistics registers via `ioread64()` can
> result in torn reads on 32-bit platforms.
> --
> 
> commit cc14b24b819aeb13f3bfcafbea26c9b2150e232c
> Author: Wei Fang <[email protected]>
> 
> net: dsa: netc: add support for the standardized counters
> 
> This commit adds support for 802.3 basic and mandatory managed objects
> statistic counters, along with MIB and RMON counters for the NETC switch.
> These are 64-bit registers read via a newly added ethtool implementation.
> 
> > diff --git a/include/linux/fsl/netc_global.h b/include/linux/fsl/netc_global.h
> > index fdecca8c90f0c..5b8ff528d3699 100644
> > --- a/include/linux/fsl/netc_global.h
> > +++ b/include/linux/fsl/netc_global.h
> > @@ -5,6 +5,7 @@
> >  #define __NETC_GLOBAL_H
> >
> >  #include <linux/io.h>
> > +#include <linux/io-64-nonatomic-lo-hi.h>
> 
> [ ... ]
> 
> > +static inline u64 netc_read64(void __iomem *reg)
> > +{
> > +	return ioread64(reg);
> > +}
> 
> Since ioread64() is backed by ioread64_lo_hi() on 32-bit platforms via
> <linux/io-64-nonatomic-lo-hi.h>, can this sequence result in torn reads
> when accessing the live 64-bit hardware counters?
> 
> If a hardware counter increments from 0x00000000_FFFFFFFF to
> 0x00000001_00000000 between the lower and upper 32-bit reads, would the
> result be incorrectly returned as 0x00000001_FFFFFFFF?
> 
> Unless the NETC hardware provides an atomic shadow latch mechanism for
> these
> counters upon the first read, might this require a read-retry loop to ensure
> consistency on 32-bit architectures?
> 

NETC runs on ARM64 SoCs, so please ignore this warning, it is a false positive.