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

[Arnd Bergmann]

On Sat, Jun 24, 2023, at 15:26, Guenter Roeck wrote:
> On 6/24/23 02:27, Arnd Bergmann wrote:
>> On Sat, Jun 24, 2023, at 03:55, Guenter Roeck wrote:
>>>
>>> On Mon, Apr 17, 2023 at 02:56:49PM +0200, Thomas Zimmermann wrote:
>>>> 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@xxxxxxx>
>>>> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
>>>
>>> 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