[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdYjEgsyCznNwkSaStk+DMtjH3_oGeX4f4BJzpo5eXHm2g@mail.gmail.com>
Date: Thu, 23 Nov 2023 09:17:49 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Dan Williams <dan.j.williams@...el.com>,
Arnd Bergmann <arnd@...db.de>
Cc: Dave Jiang <dave.jiang@...el.com>, rafael@...nel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, lenb@...nel.org,
robert.moore@...el.com, Jonathan.Cameron@...wei.com,
guohanjun@...wei.com, linux-acpi@...r.kernel.org,
acpica-devel@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, cfsworks@...il.com
Subject: Re: [PATCH v3] acpi: Fix ARM32 platforms compile issue introduced by
fw_table changes
On Wed, Nov 22, 2023 at 10:32 PM Dan Williams <dan.j.williams@...el.com> wrote:
> It concerns me that neither linux-next nor 0day robot exposure reported
> this problem.
>
> Does ARM32 require manual compilation coverage these days or was this
> just a series of unfortunate events that the build bots missed this?
It's not just ARM32, I saw it on ARM64 as well and I'm pretty
sure it appears on any bare metal "none" compiler.
kernel.org host "nolibc" cross compilers (Arnd makes these):
https://mirrors.edge.kernel.org/pub/tools/crosstool/
and those WORK, because they use the kernel minimal
libc which defines __linux__.
So a "nolibc" compiler works but not "none" compilers.
I think the test robots all use Arnds nolibc compilers or the
compilers from distributions so they don't see this.
A typical example of breaking compilers: ARMs supported
"none" compilers:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Yours,
Linus Walleij
Powered by blists - more mailing lists