From: "Arnd Bergmann" <arnd@kernel.org>
To: "Jani Nikula" <jani.nikula@intel.com>,
"Richard Weinberger" <richard@nod.at>,
"Anton Ivanov" <anton.ivanov@cambridgegreys.com>,
"Johannes Berg" <johannes@sipsolutions.net>,
linux-um@lists.infradead.org
Cc: "Lucas De Marchi" <lucas.demarchi@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: um linux: no previous prototype for ‘ioread64_lo_hi’ and friends
Date: Fri, 06 Dec 2024 17:54:57 +0100 [thread overview]
Message-ID: <cafec036-d476-4bb8-8a23-25fb65943d54@app.fastmail.com> (raw)
In-Reply-To: <87ser21ks4.fsf@intel.com>
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
prev parent reply other threads:[~2024-12-06 16:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 10:33 um linux: no previous prototype for ‘ioread64_lo_hi’ and friends Jani Nikula
2024-12-06 16:54 ` Arnd Bergmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cafec036-d476-4bb8-8a23-25fb65943d54@app.fastmail.com \
--to=arnd@kernel.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=lucas.demarchi@intel.com \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox