On Thu, Sep 1, 2022, at 3:06 PM, Linus Walleij wrote:
> In arch/parisc/lib/iomap.c the .read64 and .read64be operations
> were defined unconditionally using readq() and
> drivers/parisc/sba_iommu.c also expect writeq to be available so add
> parameterization to <asm-generic/io.h> to make sure we get these also
> on 32bit parisc: platforms can now opt in for generic 64bit
> IO operations even if they are not nativelt 64bit by definining
> GENERIC_64BIT_IO before including <asm-generi/io.h>, while
> these will still be default-enabled on CONFIG_64BIT systems.
I don't think that is a good idea in general, as 64-bit I/O
operations on 32-bit machines are not well-defined. Depending
on the device, one must first write the low or the high word
to get the correct behavior, so each driver that needs to
do this must either include include/linux/io-64-nonatomic-lo-hi.h
or include/linux/io-64-nonatomic-hi-lo.h.
The parisc definition of writeq() just uses a volatile pointer
dereference, which is not guaranteed to have one or the
other meaning by the C standard, and this is why architectures
actually should define the __raw_* accessors using inline
asm for correctness.
For the arch/parisc/lib/iomap.c version, I think we just need
an #ifdef CONFIG_64BIT around those. For the iommu, we may
be able to get away with either the hi/lo or the lo/hi version,
since the 64-bit register accesses appear to be either
reads without side-effects, or the write to IOC_PDIR_BASE,
which probably always sets the upper half as zero on a 32-bit
kernel.
At that point, I would split out the fixes for 64-bit I/O
accessors into a separate patch that can be backported
without the cleanup.
Arnd
