Re: [PATCH v1] um: fix incompatible argument type in iounmap()

[Geert Uytterhoeven]

Hi Arnd,

On Wed, 9 Apr 2025 at 21:07, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Wed, Apr 9, 2025, at 19:07, Geert Uytterhoeven wrote:
> > On Wed, 9 Apr 2025 at 16:48, Miguel Ojeda
> > <miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> >> On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
> >> <fujita.tomonori@xxxxxxxxx> 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?
>
> In the old days, a lot of drivers marked MMIO pointers
> as 'volatile void *' rather than 'void __iomem *', so iounmap()
> and the readl() family of accessors need to be compatible
> with that type to avoid a warning.
>
> By the time we introduced pci_iomap()/pci_iounmap(), this was
> no longer common, so they never needed it.

IC.

> In theory we could go through all the old drivers and
> also remove the 'volatile' markers from struct members that
> store __iomem pointers, but there is no practical benefit to
> that.

Most drivers must have been fixed already, as m68k allmodconfig
does not complain.  Still, I guess I should update m68k to match the
others, right? (FTR, that also builds fine)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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