> diff --git a/include/linux/fsl/netc_global.h b/include/linux/fsl/netc_global.h
> index fdecca8c90f0..5b8ff528d369 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 u32 netc_read(void __iomem *reg)
> {
> @@ -16,4 +17,9 @@ static inline void netc_write(void __iomem *reg, u32 val)
> iowrite32(val, reg);
> }
>
> +static inline u64 netc_read64(void __iomem *reg)
> +{
> + return ioread64(reg);
> +}
> +
Sashiko says:
Will this cause a build failure on 32-bit architectures? I noticed
ioread64() is used here, but it is strictly gated behind #ifdef CONFIG_64BIT
in include/asm-generic/io.h. Even though linux/io-64-nonatomic-lo-hi.h is
included above, ioread64() isn't provided by that header.
If this is updated to use readq() to fix the 32-bit build, could it lead to
torn reads? On 32-bit systems, readq() falls back to lo_hi_readq(), which
reads the lower 32 bits and then the upper 32 bits sequentially.
Since these are live, continuously incrementing hardware counters, a wrap of
the lower 32 bits between reads could result in a spurious counter spike of
~4.29 billion. Would it be safer to use a read-high, read-low, read-high
retry loop to ensure atomicity on 32-bit architectures?
First, if CONFIG_64BIT is not selected, then ioread64() is provided by
linux/io-64-nonatomic-lo-hi.h. Sashiko mistakenly believed that
linux/io-64-nonatomic-lo-hi.h did not provide ioread64().
i.MX9x and S32N7 and subsequent SoCs are all arm64 architectures,
netc_read64() is used to read 64-bit registers of NETC.
So this is a false positive.
