Re: [PATCH 1/5] ARC: uapi: Stop leaking CONFIG_ARC_HAS_SWAPE reference to userspace

Vineet Gupta <[email protected]>
Newsgroups org.infradead.lists.linux-snps-arc,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Hi Arnd,

Long time no see. Happy New Year !

On 12/30/25 13:23, Arnd Bergmann wrote:
> On Tue, Dec 30, 2025, at 08:10, Thomas Weißschuh wrote:
>> UAPI headers are not supposed to leak references to kconfig symbols.
>> These won't be set when building userspace. Hide the kconfig reference
>> behind 'if defined(__KERNEL__)', so it will be stripped by
>> headers_install.sh. The result for userspace will be the same, but the
>> exception in headers_install.sh can also be removed.
>>
>> Signed-off-by: Thomas Weißschuh <[email protected]>
> Acked-by: Arnd Bergmann <[email protected]>
>
> Same as for the nios2 version, I think the nicer solution would
> be to use the asm-generic header for uapi and move this one
> to arch/arc/include/asm/swab.h for kernel-internal use.
>
> In theory, using 'select ARCH_USE_BUILTIN_BSWAP' in Kconfig should
> let the compiler pick the best swap instruction, which would
> be even less code, but I'm not sure if there was a reason that
> nios2 and arc don't already do this.

The builtins didn't exist when the insns were first rolled out in hw.
It seems ARCH_USE_BUILTIN_BSWAP assumes 16,32,64 variants to be available which
surprisingly seems to be true.

foo32:
    j_s.d    [blink]
    swape    r0,r0

foo16:
    exth_s    r0,r0
    asl    r2,r0,8
    lsr_s    r0,r0,8
    or_s    r0,r0,r2
    j_s.d    [blink]
    exth_s    r0,r0

foo64:
    mov_s    r2,r1    ;4
    swape    r1,r0
    j_s.d    [blink]
    swape    r0,r2

And as you said, since all upstream cores support SWAPE, we can really get rid
of all the legacy stuff and just rely on builtins.

Thx,
-Vineet

_______________________________________________
linux-snps-arc mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.