Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHk-=wgTmGaToVFdSdoFqT2sNkk7jg2rSWasUYv-tASUZ2j_0Q@mail.gmail.com>
 <20220713050724.GA2471738@roeck-us.net> <CAHk-=widUqghhXus_GCM9+FESa5vHqMb_pO3=0dGYH8C+yix2w@mail.gmail.com>
 <a804b76e-159f-dbc2-f8dc-62a58552e88d@roeck-us.net> <CADnq5_O6Tp2QPXyDCvpWuRXhDr6H1PM50Ow5YG2WeukqUd-GnQ@mail.gmail.com>
 <CAHk-=wj4+BSj2SPMRUr-TZ4Qg2o9HGOBWiJQE336YcF_U1sVNQ@mail.gmail.com> <CAMuHMdV9Pj9V-ZPpu=BMSkPt1uA_eCvU4+bxF8ZfHjteRk2CAg@mail.gmail.com>
In-Reply-To: <CAMuHMdV9Pj9V-ZPpu=BMSkPt1uA_eCvU4+bxF8ZfHjteRk2CAg@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 14 Jul 2022 09:48:36 -0700
Message-ID: <CAHk-=wgnmaTVigBc02tjqgcZaNJiYz8Xw77P+ERAXhcYjkwd=Q@mail.gmail.com>
Subject: Re: Linux 5.19-rc6
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     Alex Deucher <alexdeucher@gmail.com>,
        Guenter Roeck <linux@roeck-us.net>,
        Harry Wentland <harry.wentland@amd.com>,
        Leo Li <sunpeng.li@amd.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Balbir Singh <bsingharora@gmail.com>,
        Daniel Axtens <dja@axtens.net>,
        Paul Mackerras <paulus@ozlabs.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Kefeng Wang <wangkefeng.wang@huawei.com>,
        "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        amd-gfx list <amd-gfx@lists.freedesktop.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Oh, it's not just this one. The lists of build regressions between v5.18
> and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(
>
> [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
> [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.org

Hmm.

Some of them are because UM ends up defining and exposing helper
functions like "to_phys()", which it just shouldn't do. Very generic
name - so when some driver ends up using the same name, you get those
errors.

And some look positively strange. Like that

  drivers/mfd/asic3.c: error: unused variable 'asic'
[-Werror=unused-variable]:  => 941:23

which is clearly used three lines later by

        iounmap(asic->tmio_cnf);

and I can't find any case of 'iounmap()' having been defined to an
empty macro or anything like that to explain it. The error in
drivers/tty/serial/sh-sci.c looks to be exactly the same issue, just
with ioremap() instead of iounmap().

It would be good to have some way to find which build/architecture it
is, because right now it just looks bogus.

Do you perhaps use some broken compiler that complains when the empty
inline functions don't use their arguments? Because that's what those
ioremap/iounmap() ones look like to me, but there might be some
magical architecture / config that has issues that aren't obvious.

IOW, I'd love to get those fixed, but I would also want a little bit more info.

            Linus