Align iounmap() signature with other architectures.

This fixes the following build error on CONFIG_RUST enabled:

In file included from /home/fujita/git/linux-rust/rust/helpers/helpers.c:19:
/home/fujita/git/linux-rust/rust/helpers/io.c:12:10: error: passing 'volatile void *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
   12 |         iounmap(addr);
      |                 ^~~~
/home/fujita/git/linux-rust/arch/um/include/asm/io.h:19:42: note: passing argument to parameter 'addr' here
   19 | static inline void iounmap(void __iomem *addr)
      |                                          ^
1 error generated.

Fixes: ce30d94e6855 ("rust: add `io::{Io, IoRaw}` base types")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
 arch/um/include/asm/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/include/asm/io.h b/arch/um/include/asm/io.h
index 9ea42cc746d9..ce0e8cf4834d 100644
--- a/arch/um/include/asm/io.h
+++ b/arch/um/include/asm/io.h
@@ -16,7 +16,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, size_t size)
 
 #ifndef iounmap
 #define iounmap iounmap
-static inline void iounmap(void __iomem *addr)
+static inline void iounmap(volatile void __iomem *addr)
 {
 }
 #endif /* iounmap */

base-commit: c59026c0570a2a97ce2e7d5ae5e9c48fc841542b
-- 
2.43.0

On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> Align iounmap() signature with other architectures.

Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
just in case.

Cc'ing also the original authors of both sides too.

Thanks!

Cheers,
Miguel

Hi Miguel,

CC arnd

On Wed, 9 Apr 2025 at 16:48, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
> On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
> <fujita.tomonori@gmail.com> wrote:
> >
> > Align iounmap() signature with other architectures.
>
> Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
> just in case.

Indeed. Apparently the volatile keyword has not always been there...
Why does iounmap() need the volatile keyword?
Why does pci_iounmap() not have the volatile keyword?

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Wed, Apr 09, 2025 at 07:07:56PM +0200, Geert Uytterhoeven wrote:
> Hi Miguel,
> 
> CC arnd
> 
> On Wed, 9 Apr 2025 at 16:48, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> > On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
> > <fujita.tomonori@gmail.com> wrote:
> > >
> > > Align iounmap() signature with other architectures.
> >
> > Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
> > just in case.
> 
> Indeed. Apparently the volatile keyword has not always been there...
> Why does iounmap() need the volatile keyword?
> Why does pci_iounmap() not have the volatile keyword?

I think none of the functions within rust/helpers/io.c need volatile, since they
just defer to the corresponding C function / macro.

This probably has been a copy/paste mistake of the function signatures and
should be removed instead.

- Danilo

On Wed, 9 Apr 2025 19:30:19 +0200
Danilo Krummrich <dakr@kernel.org> wrote:

>> On Wed, 9 Apr 2025 at 16:48, Miguel Ojeda
>> <miguel.ojeda.sandonis@gmail.com> wrote:
>> > On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
>> > <fujita.tomonori@gmail.com> wrote:
>> > >
>> > > Align iounmap() signature with other architectures.
>> >
>> > Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
>> > just in case.
>> 
>> Indeed. Apparently the volatile keyword has not always been there...
>> Why does iounmap() need the volatile keyword?
>> Why does pci_iounmap() not have the volatile keyword?
> 
> I think none of the functions within rust/helpers/io.c need volatile, since they
> just defer to the corresponding C function / macro.

Yeah, all volatile in the file should be safe to remove. I'll go with
that approach for the next version.

I think it would be nice to have the same function signature across
all architectures, but that's a separate topic.

Thanks,