linux-stable.git/arch/sparc/Makefile, branch linux-rolling-stable

sparc/build: Put usage of -fcall-used* flags behind cc-option

2024-11-16T08:52:56+00:00

Place -fcall-used* flags behind cc-option so that clang (which doesn't
support them) can still compile the kernel.

This is a safe change, the reasoning is as follows:

In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
the 64-bit ABI, %g7 is the reserved one.
Linux turns them into volatile registers by the way of -fcall-used-*,
but on the other hand, omitting the flags shouldn't be harmful;
compilers will now simply refuse to touch them, and any assembly
code that happens to touch them would still work like usual (because
Linux' conventions already treats them as volatile anyway).

Signed-off-by: Koakuma 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Reviewed-by: Andreas Larsson 
Link: https://lore.kernel.org/r/20241029-sparc-cflags-v3-1-b28745a6bd71@protonmail.com
Signed-off-by: Andreas Larsson

arch: Select fbdev helpers with CONFIG_VIDEO

2024-05-03T15:07:50+00:00

Various Kconfig options selected the per-architecture helpers for
fbdev. But none of the contained code depends on fbdev. Standardize
on CONFIG_VIDEO, which will allow to add more general helpers for
video functionality.

CONFIG_VIDEO protects each architecture's video/ directory. This
allows for the use of more fine-grained control for each directory's
files, such as the use of CONFIG_STI_CORE on parisc.

v2:
- sparc: rebased onto Makefile changes

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sam Ravnborg 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: "David S. Miller" 
Cc: Andreas Larsson 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x86@kernel.org
Cc: "H. Peter Anvin" 
Signed-off-by: Arnd Bergmann

sparc: Fix undefined reference to fb_is_primary_device

2024-02-21T13:08:41+00:00

Commit 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE
symbols") added a new FB_CORE Kconfig symbol, that can be enabled to only
have fbcon/VT and DRM fbdev emulation, but without support for any legacy
fbdev driver.

Unfortunately, it missed to change the CONFIG_FB in arch/sparc makefiles,
which leads to the following linking error in some sparc64 configurations:

   sparc64-linux-ld: drivers/video/fbdev/core/fbcon.o: in function `fbcon_fb_registered':
>> fbcon.c:(.text+0x4f60): undefined reference to `fb_is_primary_device'

Fixes: 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE symbols")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/r/202401290306.IV8rhJ02-lkp@intel.com/
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Thomas Zimmermann 
Acked-by: Arnd Bergmann 
Cc:  # v6.6+
Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20240220095428.3341195-1-javierm@redhat.com

kbuild: unify vdso_install rules

2023-10-28T12:09:02+00:00

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada
Acked-by: Sven Schnelle # s390
Reviewed-by: Nicolas Schier
Reviewed-by: Guo Ren
Acked-by: Helge Deller # parisc
Acked-by: Catalin Marinas
Acked-by: Russell King (Oracle)

Merge drm/drm-next into drm-misc-next

2023-05-09T13:03:40+00:00

Start the 6.5 release cycle.

Signed-off-by: Maxime Ripard

sparc: unify sparc32/sparc64 archhelp

2023-04-26T12:10:39+00:00

Currently, entering
$ make ARCH=sparc32 help
prints the archhelp text for sparc64.
["sparc32" is documented (Documentation/kbuild/kbuild.rst)
to be a recognized alias for 32-bit sparc.]

Instead of handling ARCH=sparc or ARCH=sparc32 or ARCH=sparc64,
just unify all SPARC archhelp text in one place.

Fixes: 5e53879008b9 ("sparc,sparc64: unify Makefile")
Signed-off-by: Randy Dunlap 
Suggested-by: Masahiro Yamada 
Signed-off-by: Masahiro Yamada

arch/sparc: Implement fb_is_primary_device() in source file

2023-04-20T08:05:12+00:00

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 .

v2:
	* don't include  in header file

Signed-off-by: Thomas Zimmermann 
Cc: "David S. Miller" 
Acked-by: Arnd Bergmann 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-18-tzimmermann@suse.de

kbuild: remove head-y syntax

2022-10-02T09:06:03+00:00

Kbuild puts the objects listed in head-y at the head of vmlinux.
Conventionally, we do this for head*.S, which contains the kernel entry
point.

A counter approach is to control the section order by the linker script.
Actually, the code marked as __HEAD goes into the ".head.text" section,
which is placed before the normal ".text" section.

I do not know if both of them are needed. From the build system
perspective, head-y is not mandatory. If you can achieve the proper code
placement by the linker script only, it would be cleaner.

I collected the current head-y objects into head-object-list.txt. It is
a whitelist. My hope is it will be reduced in the long run.

Signed-off-by: Masahiro Yamada 
Tested-by: Nick Desaulniers 
Reviewed-by: Nicolas Schier

kbuild: factor out the common installation code into scripts/install.sh

2022-05-11T12:45:53+00:00

Many architectures have similar install.sh scripts.

The first half is really generic; it verifies that the kernel image
and System.map exist, then executes ~/bin/${INSTALLKERNEL} or
/sbin/${INSTALLKERNEL} if available.

The second half is kind of arch-specific; it copies the kernel image
and System.map to the destination, but the code is slightly different.

Factor out the generic part into scripts/install.sh.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nicolas Schier

kbuild: use more subdir- for visiting subdirectories while cleaning

2021-10-24T04:49:46+00:00

Documentation/kbuild/makefiles.rst suggests to use "archclean" for
cleaning arch/$(SRCARCH)/boot/, but it is not a hard requirement.

Since commit d92cc4d51643 ("kbuild: require all architectures to have
arch/$(SRCARCH)/Kbuild"), we can use the "subdir- += boot" trick for
all architectures. This can take advantage of the parallel option (-j)
for "make clean".

I also cleaned up the comments in arch/$(SRCARCH)/Makefile. The "archdep"
target no longer exists.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Acked-by: Geert Uytterhoeven 
Acked-by: Michael Ellerman  (powerpc)