Messages in this thread | | | From | Jann Horn <> | Date | Fri, 29 Mar 2019 22:40:50 +0100 | Subject | Re: [PATCH] x86/calgary: fix bitcast type warnings |
| |
On Fri, Mar 29, 2019 at 10:32 PM Logan Gunthorpe <logang@deltatee.com> wrote: > On 2019-03-29 3:19 p.m., Jann Horn wrote: > >>> Can the existing api's not be used here like iowrite64be/ioread64be/ or > >>> similar variant in "include/asm-generic/io.h" > >> > >> Oooh! I didn't realize that those exist. I'll change that and send a v2. > Yes, they are very new! It took me a while to get those patches in as it > is a bit more complicated than it seems. > > > Actually, that doesn't work at the moment on x86-64: > > > > include/asm-generic/io.h only defines these things if > > CONFIG_GENERIC_IOMAP isn't defined; and X86 unconditionally defines > > it. With CONFIG_GENERIC_IOMAP set, these functions are provided by > > include/asm-generic/iomap.h. > > For CONFIG_GENERIC_IOMAP, lib/iomap.c provides _lo_hi and _hi_lo > implementations seeing the pio regions must be emulated with 32bit > operations and we have to define the order. > > > The definitions for these are in lib/iomap.c, except that there are no > > definitions for ioread64be() and iowrite64be(); if you try to use > > them, you get linker errors. > > Some platforms implement these but most do not. If I recall correctly > only powerpc does. > > If you want to use 64 bit operations in a portable fashion, you should > include "linux/io-64-nonatomic-hi-lo.h" or > "linux/io-64-nonatomic-lo-hi.h", depending on weather you want the lower > bits or the higher bits to be written or read first in cases where an > atomic operation is not available.
So what is the right thing to do in the context of arch/x86/kernel/pci-calgary_64.c? That code wants to perform MMIO with endianness conversion, and these accesses are always performed as MMIO. Using the non-atomic 64-bit I/O helpers for this would be kind of awkward, since the accesses would never actually be split...
| |