Thread (35 messages) 35 messages, 6 authors, 2023-06-28

Re: [v3,17/19] arch/sparc: Implement fb_is_primary_device() in source file

From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2023-06-24 14:22:24
Also in: dri-devel, linux-arch, linux-arm-kernel, linux-m68k, linux-mips, linux-sh, linuxppc-dev, lkml, loongarch, sparclinux

On Sat, Jun 24, 2023, at 15:26, Guenter Roeck wrote:
On 6/24/23 02:27, Arnd Bergmann wrote:
quoted
On Sat, Jun 24, 2023, at 03:55, Guenter Roeck wrote:
quoted
On Mon, Apr 17, 2023 at 02:56:49PM +0200, Thomas Zimmermann wrote:
quoted
Other architectures implment fb_is_primary_device() in a source
file. Do the same on sparc. No functional changes, but allows to
remove several include statement from <asm/fb.h>.

v2:
	* don't include <asm/prom.h> in header file

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
This patch results (or appears to result) in the following build error
when trying to build sparc64:allmodconfig.

Error log:
<stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp]
WARNING: modpost: drivers/cpufreq/sparc-us2e-cpufreq: section mismatch
in reference: cpufreq_us2e_driver+0x20 (section: .data) ->
us2e_freq_cpu_init (section: .init.text)
WARNING: modpost: drivers/cpufreq/sparc-us3-cpufreq: section mismatch
in reference: cpufreq_us3_driver+0x20 (section: .data) ->
us3_freq_cpu_init (section: .init.text)
ERROR: modpost: "__xchg_called_with_bad_pointer" [lib/atomic64_test.ko]
undefined!
These all look like old bugs that would be trivially fixed if
anyone cared about sparc.
Odd argument, given that this _is_ a sparc patch. Those may be old
bugs, but at least in 6.4-rc7 sparc64:allmodconfig does at least compile.
The first three are non-fatal warnings even with CONFIG_WERROR=y, I'm
sure they have been there for years. I don't immediately see what
caused the __xchg_called_with_bad_pointer error, but it does not
look related to the fbdev patch. I would guess that this is a second
regression that happened to come in at the same time.
Sure, I can stop build testing it if that is where things are going.
I think we clearly want to fix the fbdev regression you found, and
maybe bisect the atomic64_test as well to see if that was caused by
a recent patch to get it into a working state again.

Regarding whether to continue build testing: if every kernel build
warns about a missing syscall for almost four years (clone3 was
added in 5.3 and requires a minimal review to hook it up to asm
code), it shows that the architecture is seriously neglected
already.

     Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help