Hi,
I would like to get rid of the following sparse error in the enetc
driver (for arm64), which uses ioread64().
../drivers/net/ethernet/freescale/enetc/enetc_ethtool.c: note: in included file
(through ../arch/arm64/include/asm/io.h, ../include/linux/io.h,
../include/linux/irq.h, ../include/asm-generic/hardirq.h,
../arch/arm64/include/asm/hardirq.h, ...):
../include/asm-generic/io.h:239:15: warning: cast to restricted __le64
The trouble is I don't understand why the casts to __le64 and use of
__le64_to_cpu() are even needed, when everything seems to be native
endianness. I've seen commit c1d55d50139b ("asm-generic/io.h: Fix sparse
warnings on big-endian architectures"), but that doesn't claim to fix
anything for little endian (and doesn't touch the 64 accessors, for some
reason).
Could you please help?
Thanks,
Vladimir
On Mon, Jan 9, 2023, at 11:40, Vladimir Oltean wrote:
> Hi,
>
> I would like to get rid of the following sparse error in the enetc
> driver (for arm64), which uses ioread64().
>
> ../drivers/net/ethernet/freescale/enetc/enetc_ethtool.c: note: in included file
> (through ../arch/arm64/include/asm/io.h, ../include/linux/io.h,
> ../include/linux/irq.h, ../include/asm-generic/hardirq.h,
> ../arch/arm64/include/asm/hardirq.h, ...):
> ../include/asm-generic/io.h:239:15: warning: cast to restricted __le64
>
> The trouble is I don't understand why the casts to __le64 and use of
> __le64_to_cpu() are even needed, when everything seems to be native
> endianness. I've seen commit c1d55d50139b ("asm-generic/io.h: Fix sparse
> warnings on big-endian architectures"), but that doesn't claim to fix
> anything for little endian (and doesn't touch the 64 accessors, for some
> reason).
>
> Could you please help?
From what I can tell, the fix for openrisc was described as
a big-endian warning fix, but the warning is actually the same
on both. The difference is that on little-endian kernels,
the __le64_to_cpu() conversion only changes the type but not
the value, while on big-endian machines, the value would
be wrong without the conversion: __raw_readl() is defined
to never byteswap the data, while readl() must byteswap
little-endian MMIO registers into big-endian CPU registers
when CONFIG_CPU_BIG_ENDIAN is set.
Since Stafford only tested on 32-bit OpenRISC, he missed the
readq()/writeq() accessors that need the same warning fix.
Arnd
On Mon, Jan 09, 2023 at 12:33:31PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 9, 2023, at 11:40, Vladimir Oltean wrote:
> > Hi,
> >
> > I would like to get rid of the following sparse error in the enetc
> > driver (for arm64), which uses ioread64().
> >
> > ../drivers/net/ethernet/freescale/enetc/enetc_ethtool.c: note: in included file
> > (through ../arch/arm64/include/asm/io.h, ../include/linux/io.h,
> > ../include/linux/irq.h, ../include/asm-generic/hardirq.h,
> > ../arch/arm64/include/asm/hardirq.h, ...):
> > ../include/asm-generic/io.h:239:15: warning: cast to restricted __le64
> >
> > The trouble is I don't understand why the casts to __le64 and use of
> > __le64_to_cpu() are even needed, when everything seems to be native
> > endianness. I've seen commit c1d55d50139b ("asm-generic/io.h: Fix sparse
> > warnings on big-endian architectures"), but that doesn't claim to fix
> > anything for little endian (and doesn't touch the 64 accessors, for some
> > reason).
> >
> > Could you please help?
>
> From what I can tell, the fix for openrisc was described as
> a big-endian warning fix, but the warning is actually the same
> on both. The difference is that on little-endian kernels,
> the __le64_to_cpu() conversion only changes the type but not
> the value, while on big-endian machines, the value would
> be wrong without the conversion: __raw_readl() is defined
> to never byteswap the data, while readl() must byteswap
> little-endian MMIO registers into big-endian CPU registers
> when CONFIG_CPU_BIG_ENDIAN is set.
>
> Since Stafford only tested on 32-bit OpenRISC, he missed the
> readq()/writeq() accessors that need the same warning fix.
>
> Arnd
Hmm, ok, didn't know that difference between __raw_readq() and readq().
With this information, I guess I can submit a patch. Thanks!