Re: [brgl:gpio/for-next 42/47] gpio-mmio.c:undefined reference to `iowrite64'

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Sun, Feb 25, 2024 at 11:09 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Sun, Feb 25, 2024, at 00:23, Andy Shevchenko wrote:
> > On Sat, Feb 24, 2024 at 8:57 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:

...

> > So, the problem is that those architectures do define GENERIC_IOMAP
> > which does NOT have implementations of ioread64*()/iowrite64*().
> >
> > Arnd, maybe you can shed a light on why it is so?
>
> The problem here is that x86 cannot do 64-bit accesses
> to IORESOURCE_IO() mappings, so neither inq()/outq() nor
> ioread64()/iowrite64() can be implemented for it without
> splitting the access into two 32-bit ones.
>
> If you have the specification for the device that tries
> to use this, you should be able to work out whether
> the top or the bottom half of the 64-bit register comes
> first and replace it with a pair of 32-bit accesses that
> work on both I/O and memory space, see
> include/linux/io-64-nonatomic-{hi-lo,lo-hi}.h
>
> > And we have dead code like drivers/vfio/pci/vfio_pci_rdwr.c (the
> > part related to 64-bit IO accessors), which nobody tried.
>
> I could not figure out what that code is even trying to do,
> with its extra byteswap.
>
> > P.S. The workaround is to open code using readq()/writeq() [with
> > swab64() for BE].
>
> readq()/writeq() are not generally a replace for
> ioread64()/iowrite64() because they can't deal with ioport_map()
> type mappings, though the reverse is true and you can always
> replace readl()/writel() with ioread32()/iowrite32() if you
> can live with the performance overhead on x86.

The driver in question by name assumes that it won't perform IO port
access. Perhaps use of ioread*()/iowrite*() is not what we should even
consider there, Linus, Bart, do you know if gpio-mmio was ever used
for devices that want IO port rather than MMIO accesses?

-- 
With Best Regards,
Andy Shevchenko