linux-kernel - Re: [PATCH] m68k: asm/io.h: mark mmio read addresses as const

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWFCSQgsf_0qwdkkAif3zDXM2N-WEymJBa1eeT4N6Ezcw@mail.gmail.com>
Date:   Mon, 2 Oct 2023 15:12:17 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     kernel test robot <lkp@...el.com>, linux-m68k@...ts.linux-m68k.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] m68k: asm/io.h: mark mmio read addresses as const

Hi Arnd,

On Mon, Sep 25, 2023 at 5:53 PM Arnd Bergmann <arnd@...nel.org> wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> Passing constant __iomem tokens into the readl() family of helpers
> or any of the others causes a warning on m68k:
>
> include/asm-generic/io.h: In function 'ioread8_rep':
> arch/m68k/include/asm/io_mm.h:375:44: warning: passing argument 1 of 'raw_insb' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>      375 | #define readsb(port, buf, nr)     raw_insb((port), (u8
>
> Add a 'const' modifier to the pointers to shut up the warnings here.
>
> Closes: https://lore.kernel.org/oe-kbuild-all/202309251926.bPl23AhG-lkp@intel.com/
> Reported-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Thanks for your patch!

> --- a/arch/m68k/include/asm/raw_io.h
> +++ b/arch/m68k/include/asm/raw_io.h
> @@ -17,15 +17,15 @@
>   * two accesses to memory, which may be undesirable for some devices.
>   */
>  #define in_8(addr) \
> -    ({ u8 __v = (*(__force volatile u8 *) (unsigned long)(addr)); __v; })
> +    ({ u8 __v = (*(__force const volatile u8 *) (unsigned long)(addr)); __v; })
>  #define in_be16(addr) \
> -    ({ u16 __v = (*(__force volatile u16 *) (unsigned long)(addr)); __v; })
> +    ({ u16 __v = (*(__force const volatile u16 *) (unsigned long)(addr)); __v; })
>  #define in_be32(addr) \
> -    ({ u32 __v = (*(__force volatile u32 *) (unsigned long)(addr)); __v; })
> +    ({ u32 __v = (*(__force const volatile u32 *) (unsigned long)(addr)); __v; })
>  #define in_le16(addr) \
> -    ({ u16 __v = le16_to_cpu(*(__force volatile __le16 *) (unsigned long)(addr)); __v; })
> +    ({ u16 __v = le16_to_cpu(*(__force const volatile __le16 *) (unsigned long)(addr)); __v; })
>  #define in_le32(addr) \
> -    ({ u32 __v = le32_to_cpu(*(__force volatile __le32 *) (unsigned long)(addr)); __v; })
> +    ({ u32 __v = le32_to_cpu(*(__force const volatile __le32 *) (unsigned long)(addr)); __v; })
>
>  #define out_8(addr,b) (void)((*(__force volatile u8 *) (unsigned long)(addr)) = (b))
>  #define out_be16(addr,w) (void)((*(__force volatile u16 *) (unsigned long)(addr)) = (w))

Shouldn't a similar change be made to rom_in_{8,be16,le16}()?

I can do that while applying...

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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