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

["Arnd Bergmann" <arnd@xxxxxxxx>]

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:
>> On Sat, Feb 24, 2024 at 4:58 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> > On Fri, Feb 23, 2024 at 1:44 PM kernel test robot <lkp@xxxxxxxxx> wrote:
>> >
>> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git gpio/for-next
>> > > head:   7bb5f3a7ca8856c5c1fa26a6e3f58a1254019dc0
>> > > commit: 36e44186e0badfda499b65d4462c49783bf92314 [42/47] gpio: mmio: Support 64-bit BE access
>> > > config: um-allyesconfig (https://download.01.org/0day-ci/archive/20240223/202402232058.4eDf4GRs-lkp@xxxxxxxxx/config)
>> >
>> > UM Linux now again.
>> >
>> > gpio-mmio depends on HAS_IOMEM
>> > and UM Linux has set HAS_IOMEM, but
>> > also claims to support 64bit without providing the necessary 64bit
>> > io-accessors.
>> >
>> > Maybe UM Linux need to be fixed?
>>
>> Nah, there were other reports for the same issues, at least for x86
>> and alpha. I hope Andy will have some time to look into it early this
>> week, otherwise we'll have to revert the offending patch.
>
> 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.

     Arnd