Re: um linux: no previous prototype for ‘ioread64_lo_hi’ and friends
Arnd Bergmann
arnd at kernel.org
Fri Dec 6 08:54:57 PST 2024
On Thu, Dec 5, 2024, at 11:33, Jani Nikula wrote:
> There's this persistent build warning about missing prototypes with
> ARCH=um:
>
> [12:21:20] Configuring KUnit Kernel ...
> [12:21:20] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=um O=build.kunit olddefconfig
> Building with:
> $ make all compile_commands.json ARCH=um O=build.kunit --jobs=8
> ../lib/iomap.c:156:5: warning: no previous prototype for
> ‘ioread64_lo_hi’ [-Wmissing-prototypes]
> 156 | u64 ioread64_lo_hi(const void __iomem *addr)
> | ^~~~~~~~~~~~~~
> ../lib/iomap.c:163:5: warning: no previous prototype for
> ‘ioread64_hi_lo’ [-Wmissing-prototypes]
> 163 | u64 ioread64_hi_lo(const void __iomem *addr)
> | ^~~~~~~~~~~~~~
...
> [12:21:24] Elapsed time: 3.945s
>
> I fail at figuring out where to stick an #include or #define readq or
> something to get the prototypes.
>
> Cc: Arnd who seems to have fixed similar issues before on other archs,
> do you have any ideas?
I need to read up on the details again, but I think this is
actually a fundamentally hard problem to solve as we have
conflicting definitions for these functions depending
on the architecture:
- On 32-bit architectures, they are a pair of 32-bit
MMIO accesses, which may point to PCI PIO space,
but never a single access. These override the
normal io{write,read}64{,be} definitions. The normal
way to call these is through io{write,read}64{,be},
after including the headers.
- On x86-64 (non-um) it turns into either a pair of 32-bit
I/O port accesses or a single 64-bit MMIO access,
depending on the address, but never a pair of 32-bit
MMIO accesses.
- On other 64-bit architectures, they always turn into
a pair of 32-bit MMIO access that may point to
PIO space, but these do not override the native 64-bit
helpers.
It would be best if we can agree on what semantics we
actually want to support here on all architectures,
and at that point we can implement this for arch/um as
well.
Arnd
More information about the linux-um
mailing list