arch: Select fbdev helpers with CONFIG_VIDEO

Various Kconfig options selected the per-architecture helpers for
fbdev. But none of the contained code depends on fbdev. Standardize
on CONFIG_VIDEO, wh

arch: Select fbdev helpers with CONFIG_VIDEO

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 <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Andreas Larsson <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: [email protected]
Cc: "H. Peter Anvin" <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

kbuild: use 4-space indentation when followed by conditionals

GNU Make manual [1] clearly forbids a tab at the beginning of the
conditional directive line:
"Extra spaces are allowed and ignored at

kbuild: use 4-space indentation when followed by conditionals

GNU Make manual [1] clearly forbids a tab at the beginning of the
conditional directive line:
"Extra spaces are allowed and ignored at the beginning of the
conditional directive line, but a tab is not allowed."

This will not work for the next release of GNU Make, hence commit
82175d1f9430 ("kbuild: Replace tabs with spaces when followed by
conditionals") replaced the inappropriate tabs with 8 spaces.

However, the 8-space indentation cannot be visually distinguished.
Linus suggested 2-4 spaces for those nested if-statements. [2]

This commit redoes the replacement with 4 spaces.

[1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax
[2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/

Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: Replace tabs with spaces when followed by conditionals

This is needed for the future (post make-4.4.1) versions of gnu make.

Starting from https://git.savannah.gnu.org/cgit/make.git/commit/

kbuild: Replace tabs with spaces when followed by conditionals

This is needed for the future (post make-4.4.1) versions of gnu make.

Starting from https://git.savannah.gnu.org/cgit/make.git/commit/?id=07fcee35f058a876447c8a021f9eb1943f902534
gnu make won't allow conditionals to follow recipe prefix.

For example there is a tab followed by ifeq on line 324 in the root Makefile.
With the new make this conditional causes the following

$ make cpu.o
/home/dgoncharov/src/linux-kbuild/Makefile:2063: *** missing 'endif'. Stop.
make: *** [Makefile:240: __sub-make] Error 2

This patch replaces tabs followed by conditionals with 8 spaces.

See https://savannah.gnu.org/bugs/?64185 and
https://savannah.gnu.org/bugs/?64259 for details.

Signed-off-by: Dmitry Goncharov <[email protected]>
Reported-by: Martin Dorey <[email protected]>
Reviewed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: unify vdso_install rules

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

1. Code duplication

Many architectures duplicate similar code just

kbuild: unify vdso_install rules

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 <[email protected]>
Acked-by: Sven Schnelle <[email protected]> # s390
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Guo Ren <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Russell King (Oracle) <[email protected]>

show more ...

arch/parisc: Implement fb_is_primary_device() under arch/parisc

Move PARISC's implementation of fb_is_primary_device() into the
architecture directory. This the place of the declaration and
where ot

arch/parisc: Implement fb_is_primary_device() under arch/parisc

Move PARISC's implementation of fb_is_primary_device() into the
architecture directory. This the place of the declaration and
where other architectures implement this function. No functional
changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: Helge Deller <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

arch/parisc: Remove trailing whitespaces

Fix trailing whitespaces. No functional changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPa

arch/parisc: Remove trailing whitespaces

Fix trailing whitespaces. No functional changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: Helge Deller <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

kbuild: remove head-y syntax

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

kbuild: remove head-y syntax

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 <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

parisc: remove arch/parisc/nm

Parisc overrides 'nm' with a shell script. I was hit by a false-positive
error of $(NM) because this script returns the exit status of grep
instead of ${CROSS_COMPILE}n

parisc: remove arch/parisc/nm

Parisc overrides 'nm' with a shell script. I was hit by a false-positive
error of $(NM) because this script returns the exit status of grep
instead of ${CROSS_COMPILE}nm. (grep returns 1 if no lines were selected)

I tried to fix it, but in the code review, Helge suggested to remove it
entirely. [1]

This script was added in 2003. [2]

Presumably, it was a workaround for old toolchains (but even the parisc
maintainer does not know the detail any more).

Hopefully, recent tools should work fine.

[1]: https://lore.kernel.org/all/[email protected]/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=36eaa6e4c0e0b6950136b956b72fd08155b92ca3

Suggested-by: Helge Deller <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Helge Deller <[email protected]>

show more ...

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

Many architectures have similar install.sh scripts.

The first half is really generic; it verifies that the kernel image
and S

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

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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

parisc: Detect hppa-suse-linux-gcc compiler for cross-building

Allow the system to find the SUSE hppa compiler and linker to set
CROSS32_COMPILE and CROSS_COMPILE.

Suggested-by: Jiri Slaby <jirisla

parisc: Detect hppa-suse-linux-gcc compiler for cross-building

Allow the system to find the SUSE hppa compiler and linker to set
CROSS32_COMPILE and CROSS_COMPILE.

Suggested-by: Jiri Slaby <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

parisc: Always use the self-extracting kernel feature

This patch drops the CONFIG_PARISC_SELF_EXTRACT option.

The palo boot loader is able to decompress a kernel which was compressed
with gzip. Tha

parisc: Always use the self-extracting kernel feature

This patch drops the CONFIG_PARISC_SELF_EXTRACT option.

The palo boot loader is able to decompress a kernel which was compressed
with gzip. That possibility was useful when the Linux kernel
self-extracting feature wasn't implemented yet.

Beside the fact that the self-extracting feature offers much better
compression rates, we do support self-extracting kernels already since
kernel v4.14, so now it's really time to get rid of that old option and
always use the self-extractor.

Signed-off-by: Helge Deller <[email protected]>

show more ...

parisc: Add vDSO support

Add minimal vDSO support, which provides the signal trampoline helpers,
but none of the userspace syscall helpers like time wrappers.

The big benefit of this vDSO implement

parisc: Add vDSO support

Add minimal vDSO support, which provides the signal trampoline helpers,
but none of the userspace syscall helpers like time wrappers.

The big benefit of this vDSO implementation is, that we now don't need
an executeable stack any longer. PA-RISC is one of the last
architectures where an executeable stack was needed in oder to implement
the signal trampolines by putting assembly instructions on the stack
which then gets executed. Instead the kernel will provide the relevant
code in the vDSO page and only put the pointers to the signal
information on the stack.

By dropping the need for executable stacks we avoid running into issues
with applications which want non executable stacks for security reasons.
Additionally, alternative stacks on memory areas without exec
permissions are supported too.

This code is based on an initial implementation by Randolph Chung from 2006:
https://lore.kernel.org/linux-parisc/[email protected]/

I did the porting and lifted the code to current code base. Dave fixed
the unwind code so that gdb and glibc are able to backtrace through the
code. An additional patch to gdb will be pushed upstream by Dave.

Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Dave Anglin <[email protected]>
Cc: Randolph Chung <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

parisc: Fix KBUILD_IMAGE for self-extracting kernel

Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting
(CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built.
This fixes the bindeb-pkg make

parisc: Fix KBUILD_IMAGE for self-extracting kernel

Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting
(CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built.
This fixes the bindeb-pkg make target.

Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # v4.14+

show more ...

kbuild: use more subdir- for visiting subdirectories while cleaning

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

kbuild: use more subdir- for visiting subdirectories while cleaning

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 <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)

show more ...

parisc: Fix compile failure when building 64-bit kernel natively

Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is
a cross build or not") broke 64-bit parisc builds on 32-bit pa

parisc: Fix compile failure when building 64-bit kernel natively

Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is
a cross build or not") broke 64-bit parisc builds on 32-bit parisc
systems.

Helge mentioned:
- 64-bit parisc userspace is not supported yet [1]
- hppa gcc does not support "-m64" flag [2]

That means, parisc developers working on a 32-bit parisc machine need
to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit
parisc kernel.

After the offending commit, gcc is used in such a case because
both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is
unset.

A correct way is to introduce ARCH=parisc64 because building the 64-bit
parisc kernel on a 32-bit parisc system is not exactly a native build,
but rather a semi-cross build.

[1]: https://lore.kernel.org/linux-parisc/[email protected]/#t
[2]: https://lore.kernel.org/linux-parisc/[email protected]/

Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not")
Signed-off-by: Masahiro Yamada <[email protected]>
Reported-by: Meelis Roos <[email protected]>
Tested-by: Meelis Roos <[email protected]>
Cc: <[email protected]> # v5.13+
Signed-off-by: Helge Deller <[email protected]>

show more ...

parisc: move core-y in arch/parisc/Makefile to arch/parisc/Kbuild

Use obj-y to clean up Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

arch: use cross_compiling to check whether it is a cross build or not

'cross_compiling' is defined by the top Makefile and available for
arch Makefiles to check whether it is a cross build or not. A

arch: use cross_compiling to check whether it is a cross build or not

'cross_compiling' is defined by the top Makefile and available for
arch Makefiles to check whether it is a cross build or not. A good
thing is the variable name 'cross_compiling' is self-documenting.

This is a simple replacement for m68k, mips, sh, for which $(ARCH)
and $(SRCARCH) always match.

No functional change is intended for xtensa, either.

This is rather a fix for parisc because arch/parisc/Makefile defines
UTS_MATCHINE depending on CONFIG_64BIT, therefore cc-cross-prefix
is not working in Kconfig time.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc
Acked-by: Max Filippov <[email protected]> # xtensa

show more ...

arch: parisc: Remove CONFIG_OPROFILE support

The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf int

arch: parisc: Remove CONFIG_OPROFILE support

The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf interfaces.

Remove the old oprofile's architecture specific support.

Suggested-by: Christoph Hellwig <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Robert Richter <[email protected]>
Acked-by: William Cohen <[email protected]>
Acked-by: Al Viro <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc

show more ...

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The origi

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: add variables for compression tools

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$

kbuild: add variables for compression tools

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2

Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.

The credit goes to @grsecurity.

As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"

Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

parisc: suppress error messages for 'make clean'

Avoid error messages when running 'make ARCH=parisc clean'.

Noticed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Helge Deller <deller@g

parisc: suppress error messages for 'make clean'

Avoid error messages when running 'make ARCH=parisc clean'.

Noticed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

parisc: Fix defconfig selection

Fix the recursive loop when running "make ARCH=parisc defconfig".

Fixes: 84669923e1ed ("parisc: Regenerate parisc defconfigs")
Noticed-by: Guenter Roeck <linux@roeck

parisc: Fix defconfig selection

Fix the recursive loop when running "make ARCH=parisc defconfig".

Fixes: 84669923e1ed ("parisc: Regenerate parisc defconfigs")
Noticed-by: Guenter Roeck <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

module/ftrace: handle patchable-function-entry

When using patchable-function-entry, the compiler will record the
callsites into a section named "__patchable_function_entries" rather
than "__mcount_l

module/ftrace: handle patchable-function-entry

When using patchable-function-entry, the compiler will record the
callsites into a section named "__patchable_function_entries" rather
than "__mcount_loc". Let's abstract this difference behind a new
FTRACE_CALLSITE_SECTION, so that architectures don't have to handle this
explicitly (e.g. with custom module linker scripts).

As parisc currently handles this explicitly, it is fixed up accordingly,
with its custom linker script removed. Since FTRACE_CALLSITE_SECTION is
only defined when DYNAMIC_FTRACE is selected, the parisc module loading
code is updated to only use the definition in that case. When
DYNAMIC_FTRACE is not selected, modules shouldn't have this section, so
this removes some redundant work in that case.

To make sure that this is keep up-to-date for modules and the main
kernel, a comment is added to vmlinux.lds.h, with the existing ifdeffery
simplified for legibility.

I built parisc generic-{32,64}bit_defconfig with DYNAMIC_FTRACE enabled,
and verified that the section made it into the .ko files for modules.

Signed-off-by: Mark Rutland <[email protected]>
Acked-by: Helge Deller <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Torsten Duwe <[email protected]>
Tested-by: Amit Daniel Kachhap <[email protected]>
Tested-by: Sven Schnelle <[email protected]>
Tested-by: Torsten Duwe <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: [email protected]

show more ...

kbuild: rebuild modules when module linker scripts are updated

Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.

kbuild: rebuild modules when module linker scripts are updated

Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

parisc: Add archclean Makefile target

Apparently we don't have an archclean target in our
arch/parisc/Makefile, so files in there never get cleaned out by make
mrproper. This, in turn means that th

parisc: Add archclean Makefile target

Apparently we don't have an archclean target in our
arch/parisc/Makefile, so files in there never get cleaned out by make
mrproper. This, in turn means that the sizes.h file in
arch/parisc/boot/compressed never gets removed and worse, when you
transition to an O=build/parisc[64] build model it overrides the
generated file. The upshot being my bzImage was building with a SZ_end
that was too small.

I fixed it by making mrproper clean everything.

Signed-off-by: James Bottomley <[email protected]>
Cc: [email protected] # v4.20+
Signed-off-by: Helge Deller <[email protected]>

show more ...