On Mon, 26 Feb 2024 at 03:18, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > 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? > I don't know the answer. I'd also like to stabilize the for-next branch as we're pretty late in the cycle so I'm really considering backing this patch out unless you think you'll be able to fix it soon? I'm quite busy ATM and will be travelling this week so can't really spend time on it. Bart > -- > With Best Regards, > Andy Shevchenko