[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXsiSfp3DGnLXfuENVLOdG91a+GXj3+g9p8Yp6aGTuqDQ@mail.gmail.com>
Date: Thu, 21 Sep 2023 09:08:30 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Guenter Roeck <linux@...ck-us.net>, Rob Herring <robh@...nel.org>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Michael Schmitz <schmitzmic@...il.com>
Subject: Re: arch/m68k/include/asm/raw_io.h:91:13: warning: array subscript 0
is outside array bounds of 'volatile u16[0]' {aka 'volatile short unsigned int[]'}
Hi Günter, Rob,
CC Michael
On Wed, Sep 20, 2023 at 11:09 PM Guenter Roeck <linux@...ck-us.net> wrote:
> On 9/20/23 09:20, Rob Herring wrote:
> [....]
>
> >>
> >> Sure, but I still argue that this isn't worth it for drivers like this one.
> >> Are you going to submit a fix ? Because otherwise I'll submit a patch
> >> to drop COMPILE_TEST from MACHZ_WDT.
I think dropping COMPILE_TEST from MACHZ_WDT is the right thing to do
anyway. Unlike most other drivers, this is not a driver that can be
compiled in, and doesn't do anything if the hardware is not present.
In fact it is a very dangerous driver: its probe function "reads" the
ZF version register, but that involves doing an unconditional write,
which might crash any non-X86 system.
IMHO a driver must not be enabled for compile-testing if its presence
can harm the system.
> > I honestly don't know what the fix is. There's a compiler flag to
> > allow 0 address, but that seems like a big hammer. From what I read on
> > the fix for gcc-12, we shouldn't be getting this, but I haven't
> > confirmed. I was hoping for comment from Geert as the issue doesn't
> > appear to be the driver, but the arch code.
Well, Atari ROM port ISA accesses are really weird, due to the really
weird way the bus is wired to the address/data lines...
The issue is that gcc considers accessing these addresses as "not
done"...
> > Furthermore, I just built the same HEAD and config as reported and
> > don't see this error. I'm using kernel.org nolibc gcc 13.2.0 which
> > should be the same version.
>
> Exactly my point. So now we are stuck with a report like this on a
> driver which probably has 0 users and we don't know how to fix it,
> all to get the benefit of being able to compile it for an architecture
> and platform which will never use it.
>
> I seem to recall similar errors with m68k and COMPILE_TEST last time
> I tried to enable it on watchdog drivers, so I am not sure if this is
> entirely new.
Probably not.
Michael: original build failure report in
https://lore.kernel.org/r/202309192013.vI4DKHmw-lkp@intel.com/
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
Powered by blists - more mailing lists