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

[sashiko-bot@kernel.org]

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 <wei.fang@nxp.com>

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509102954.4116624-1-wei.fang@nxp.com?part=14