linux-um archives
 help / color / mirror / Atom feed
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


      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