This tag contains the new features we'd like to incorporate into the
RISC-V port for 4.17. We might have a bit more stuff land later in the
merge window, but I wanted to get this out earlier just so everyone can
see where we currently stand.
A short summary of the changes is:
* We've added support for dynamic ftrace on RISC-V targets.
* There have been a handful of cleanups to our atomic and locking
routines. They now more closely match the released RISC-V memory
model draft.
* Our module loading support has been cleaned up and is now enabled by
default, despite some limitations still existing.
* A patch to define COMMANDLINE_FORCE instead of COMMANDLINE_OVERRIDE so
the generic device tree code picks up handling all our command line
stuff.
There's more information in the merge commits for each patch set.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlrDsOATHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQVDuD/9uBjfgzdyJ/C7+rcN6SgsmCOrDSmZz
9yx0xqJwuVe8b21Lt4fueDjIMpVfjgxbE4SWTQ/MqaGBcxknOtUpJdGzA98BO6oB
VU/Mx0EJL2L0N+FNqWuE1KCa6h8PH8PB4pzl/dvwKRdtgViL2EGuzQebSDT2iwTg
JpCsAzfAZjTT0StVj7vn9/7O3uP/9G9j+GeZFvCT+OxtPHYc5TkDKZuOCI66GokJ
ppGrqa9MqrWADpqWVBUIYsYqRHrhBUWgBqN5CfgsiRFTQn0ISUpdl/qZbLBVsHfY
o8i/d0RM1jc5U4+qgZLpB8nD9RYpr9GTQobhNkcjyVmKHJFdJirYDD/y3fi38IoT
svTv1n3VIFBTv1+u5H/Rv+ABhJx5ofFjboD9IXB3j/82i/T06IMZ2IujAAwLQw4u
1hE/wKM67c6dR+gqMl8Zq1LuYoUGuc2MIX3eLYc4GmWloZkKg/N7rHjaPFfnZlwd
ZFfrPl+ZTP3FYpr3yanrVNYwHZfFWPlTnXvPWNFi+A5HPVI7+ScR8++Eaqo1mb5h
nFr4wS8GX2FbUmF20mf4W7RAkpnnUlo9HRNMqfExTmp+dPCbgVXIEfJTCYsamAPV
nDQ2xG5aLMyRcUBSbQEi7tninMRFGXiBYbcn6LWhYibBpr5SFGwlSkmWxbDi3ark
6lsKCBK3qrNHBQ==
=XrWX
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-4.17-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux
Pull RISC-V updates from Palmer Dabbelt:
"This contains the new features we'd like to incorporate into the
RISC-V port for 4.17. We might have a bit more stuff land later in the
merge window, but I wanted to get this out earlier just so everyone
can see where we currently stand.
A short summary of the changes is:
- We've added support for dynamic ftrace on RISC-V targets.
- There have been a handful of cleanups to our atomic and locking
routines. They now more closely match the released RISC-V memory
model draft.
- Our module loading support has been cleaned up and is now enabled
by default, despite some limitations still existing.
- A patch to define COMMANDLINE_FORCE instead of COMMANDLINE_OVERRIDE
so the generic device tree code picks up handling all our command
line stuff.
There's more information in the merge commits for each patch set"
* tag 'riscv-for-linus-4.17-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: (21 commits)
RISC-V: Rename CONFIG_CMDLINE_OVERRIDE to CONFIG_CMDLINE_FORCE
RISC-V: Add definition of relocation types
RISC-V: Enable module support in defconfig
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Add sections of PLT and GOT for kernel module
riscv/atomic: Strengthen implementations with fences
riscv/spinlock: Strengthen implementations with fences
riscv/barrier: Define __smp_{store_release,load_acquire}
riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support
riscv/ftrace: Add DYNAMIC_FTRACE_WITH_REGS support
riscv/ftrace: Add ARCH_SUPPORTS_FTRACE_OPS support
riscv/ftrace: Add dynamic function graph tracer support
riscv/ftrace: Add dynamic function tracer support
...
Nothing particularly stands out here, probably because people were tied
up with spectre/meltdown stuff last time around. Still, the main pieces
are:
- Rework of our CPU features framework so that we can whitelist CPUs that
don't require kpti even in a heterogeneous system
- Support for the IDC/DIC architecture extensions, which allow us to elide
instruction and data cache maintenance when writing out instructions
- Removal of the large memory model which resulted in suboptimal codegen
by the compiler and increased the use of literal pools, which could
potentially be used as ROP gadgets since they are mapped as executable
- Rework of forced signal delivery so that the siginfo_t is well-formed
and handling of show_unhandled_signals is consolidated and made
consistent between different fault types
- More siginfo cleanup based on the initial patches from Eric Biederman
- Workaround for Cortex-A55 erratum #1024718
- Some small ACPI IORT updates and cleanups from Lorenzo Pieralisi
- Misc cleanups and non-critical fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJaw1TCAAoJELescNyEwWM0gyQIAJVMK4QveBW+LwF96NYdZo16
p90Aa+nqKelh/s93govQArDMv1gxyuXdFlQZVOGPQHfqpz6RhJWmBA2tFsUbQrUc
OBcioPrRihqTmKBe+1r1XORwZxkVX6GGmCn0LYpPR7I3TjxXZpvxqaxGxiUvHkci
yVxWlDTyN/7eL3akhCpCDagN3Fxwk3QnJLqE3fxOFMlY7NvQcmUxcITiUl/s469q
xK6SWH9SRH1JK8jTHPitwUBiU//3FfCqSI9HLEdDIDoTuPcVM8UetWvi4QzrzJL1
UYg8lmU0CXNmflDzZJDaMf+qFApOrGxR0YVPpBzlQvxe0JIY69g48f+JzDPz8nc=
=+gNa
-----END PGP SIGNATURE-----
Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 updates from Will Deacon:
"Nothing particularly stands out here, probably because people were
tied up with spectre/meltdown stuff last time around. Still, the main
pieces are:
- Rework of our CPU features framework so that we can whitelist CPUs
that don't require kpti even in a heterogeneous system
- Support for the IDC/DIC architecture extensions, which allow us to
elide instruction and data cache maintenance when writing out
instructions
- Removal of the large memory model which resulted in suboptimal
codegen by the compiler and increased the use of literal pools,
which could potentially be used as ROP gadgets since they are
mapped as executable
- Rework of forced signal delivery so that the siginfo_t is
well-formed and handling of show_unhandled_signals is consolidated
and made consistent between different fault types
- More siginfo cleanup based on the initial patches from Eric
Biederman
- Workaround for Cortex-A55 erratum #1024718
- Some small ACPI IORT updates and cleanups from Lorenzo Pieralisi
- Misc cleanups and non-critical fixes"
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (70 commits)
arm64: uaccess: Fix omissions from usercopy whitelist
arm64: fpsimd: Split cpu field out from struct fpsimd_state
arm64: tlbflush: avoid writing RES0 bits
arm64: cmpxchg: Include linux/compiler.h in asm/cmpxchg.h
arm64: move percpu cmpxchg implementation from cmpxchg.h to percpu.h
arm64: cmpxchg: Include build_bug.h instead of bug.h for BUILD_BUG
arm64: lse: Include compiler_types.h and export.h for out-of-line LL/SC
arm64: fpsimd: include <linux/init.h> in fpsimd.h
drivers/perf: arm_pmu_platform: do not warn about affinity on uniprocessor
perf: arm_spe: include linux/vmalloc.h for vmap()
Revert "arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)"
arm64: cpufeature: Avoid warnings due to unused symbols
arm64: Add work around for Arm Cortex-A55 Erratum 1024718
arm64: Delay enabling hardware DBM feature
arm64: Add MIDR encoding for Arm Cortex-A55 and Cortex-A35
arm64: capabilities: Handle shared entries
arm64: capabilities: Add support for checks based on a list of MIDRs
arm64: Add helpers for checking CPU MIDR against a range
arm64: capabilities: Clean up midr range helpers
arm64: capabilities: Change scope of VHE to Boot CPU feature
...
- improve checkpatch for more precise Kconfig code checking
- clarify effective selects by grouping reverse dependencies in help
- do not write out '# CONFIG_FOO is not set' from invisible symbols
- make oldconfig as silent as it should be
- rename 'silentoldconfig' to 'syncconfig'
- add unit-test framework and several test cases
- warn unmet dependency of tristate symbols
- make unmet dependency warnings readable, removing false positives
- improve recursive include detection
- use yylineno to simplify the line number tracking
- misc cleanups
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJaw6i1AAoJED2LAQed4NsGU7oP/Rc5DJmtQXbqONvEfVskfNzL
NaQekDa4QuWRCbrAdRZM+8dlAgX76kXHd0I1LnL6XeCZ2KZ7f93zxpqBKHZAteGU
Y6b06tDXiW9qIdI0wzfKB3KdZo0Jc1LELv7SMRrZ7+wFXZKmhh5M0mVX17sKrQai
L3wPMqiu15ve2Ya9s8F8+PGFBZfqzhOBEzYij8YtTZWFWVEfoLDDD5YDUxQNcJrS
FXO+fZH5EUpoWj+JseiIPuOKASChsyeqtwqCND444IrjqDQ0TLAyJSZJhSm+6bX3
qP/yMH0K+kMMkvKp8CCnaTfwkOJ2BZo+91Ydw1mnqLdnZ8gZndnyexrBFubIv+fJ
0KxX9IyGA+RBnwArsnF1yIoryktG3xtaR5diO2p5ztd8xgptKG+PqQfJ40DHjpu4
iZNpoVPIPh669w/Dfx033t1RZVhov8Mau2dZ5RCtpvXAAS6oRe+UmaazqUGt7O2z
V8ekSNL3g7FN3YYx0awXJWzX8e3BDMOcUjRvw/SI16XBk0BdHiBMrYfnRN+e3mpy
FjhzZdXajJclNwMVbUOAPaQypvbBQJjBMy0ryz05ZyTPEsmJqM+WjkPSLDppnMYT
8L3C5KSqC7WKdf1bj55YdGWyfyU0P9bCO026IClnvZNZDI/bg+3gB9ocyRfZG0sL
0Q7GJF+BixbUUQeUcejm
=sKto
-----END PGP SIGNATURE-----
Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kconfig updates from Masahiro Yamada:
- improve checkpatch for more precise Kconfig code checking
- clarify effective selects by grouping reverse dependencies in help
- do not write out '# CONFIG_FOO is not set' from invisible symbols
- make oldconfig as silent as it should be
- rename 'silentoldconfig' to 'syncconfig'
- add unit-test framework and several test cases
- warn unmet dependency of tristate symbols
- make unmet dependency warnings readable, removing false positives
- improve recursive include detection
- use yylineno to simplify the line number tracking
- misc cleanups
* tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (30 commits)
kconfig: use yylineno option instead of manual lineno increments
kconfig: detect recursive inclusion earlier
kconfig: remove duplicated file name and lineno of recursive inclusion
kconfig: do not include both curses.h and ncurses.h for nconfig
kconfig: make unmet dependency warnings readable
kconfig: warn unmet direct dependency of tristate symbols selected by y
kconfig: tests: test if recursive inclusion is detected
kconfig: tests: test if recursive dependencies are detected
kconfig: tests: test randconfig for choice in choice
kconfig: tests: test defconfig when two choices interact
kconfig: tests: check visibility of tristate choice values in y choice
kconfig: tests: check unneeded "is not set" with unmet dependency
kconfig: tests: test if new symbols in choice are asked
kconfig: tests: test automatic submenu creation
kconfig: tests: add basic choice tests
kconfig: tests: add framework for Kconfig unit testing
kbuild: add PYTHON2 and PYTHON3 variables
kconfig: remove redundant streamline_config.pl prerequisite
kconfig: rename silentoldconfig to syncconfig
kconfig: invoke oldconfig instead of silentoldconfig from local*config
...
- add a shell script to get Clang version
- improve portability of build scripts
- drop always-enabled CONFIG_THIN_ARCHIVE and remove unused code
- rename built-in.o which is now thin archive to built-in.a
- process clean/build targets one by one to get along with -j option
- simplify ld-option
- improve building with CONFIG_TRIM_UNUSED_KSYMS
- define KBUILD_MODNAME even for objects shared among multiple modules
- avoid linking multiple instances of same objects from composite objects
- move <linux/compiler_types.h> to c_flags to include it only for C files
- clean-up various Makefiles
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJaw6eWAAoJED2LAQed4NsGrK8QAJmbYg83TTNoOgQRK/7Lg+sj
KL1+RGFxmdHRVOqG5n18L7Q4LmTD19tUFNQImrQTTrKrbH2vbMSTF2PfzdmDRwMz
R5vW5+wsagfhSttOce/GR4p9+bM9XEclzEa3liqNVQxijOFXmkV14pn0x5anYfeB
ABthxFFHcVn3exP/q3lmq048x1yNE71wUU5WQIWf6V/ZKf+++wQU8r7HpnATWYeO
vtf8gZq+xyLLjhxoJF6n6olSZXI7Yhz4jV2G68/VroS312AUFWPogK+cSshWGlSw
zGixM1q55oj9CXjZ37nR6pTzQhSZLf/uHX5beatlpeoJ4Hho6HlIABvx2oEnat7b
o5RW64RB0gVJqlYZdKxL29HNrovr9tlWPTaIPGFRvWDpl3c1w+rMKXE+5hwu8jMJ
2jgxd5FZCgBaDsAKojmeQR7PAo2ffAdUO0Dj/SuAaMOpuHWHcnJk9kIN2PUrC+Sf
d/H2soT9x+60KbQmtCEo5VfEN8bvNP3+ZSnadEG/gRN2IIa5FZAUQykU+i50gAvj
tuKAokdRGZHvXM+buYFBfN6RbhVCXzBF/fAG7r37QVR2u1zaUszmgFOUqERhTQfm
RNnyeAs9G9rljtna/AD7cIOdKTg8oETPISxt8Y6EzNMpI8PhF0aGoxso3yD19oH1
M+fq55RigsR48Kic40hY
=N5BL
-----END PGP SIGNATURE-----
Merge tag 'kbuild-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild updates from Masahiro Yamada:
- add a shell script to get Clang version
- improve portability of build scripts
- drop always-enabled CONFIG_THIN_ARCHIVE and remove unused code
- rename built-in.o which is now thin archive to built-in.a
- process clean/build targets one by one to get along with -j option
- simplify ld-option
- improve building with CONFIG_TRIM_UNUSED_KSYMS
- define KBUILD_MODNAME even for objects shared among multiple modules
- avoid linking multiple instances of same objects from composite
objects
- move <linux/compiler_types.h> to c_flags to include it only for C
files
- clean-up various Makefiles
* tag 'kbuild-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (29 commits)
kbuild: get <linux/compiler_types.h> out of <linux/kconfig.h>
kbuild: clean up link rule of composite modules
kbuild: clean up archive rule of built-in.a
kbuild: remove partial section mismatch detection for built-in.a
net: liquidio: clean up Makefile for simpler composite object handling
lib: zstd: clean up Makefile for simpler composite object handling
kbuild: link $(real-obj-y) instead of $(obj-y) into built-in.a
kbuild: rename real-objs-y/m to real-obj-y/m
kbuild: move modname and modname-multi close to modname_flags
kbuild: simplify modname calculation
kbuild: fix modname for composite modules
kbuild: define KBUILD_MODNAME even if multiple modules share objects
kbuild: remove unnecessary $(subst $(obj)/, , ...) in modname-multi
kbuild: Use ls(1) instead of stat(1) to obtain file size
kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS
kbuild: move include/config/ksym/* to include/ksym/*
kbuild: move CONFIG_TRIM_UNUSED_KSYMS code unneeded for external module
kbuild: restore autoksyms.h touch to the top Makefile
kbuild: move 'scripts' target below
kbuild: remove wrong 'touch' in adjust_autoksyms.sh
...
- Lots of work aligning Documentation/ABI with reality, done by Aishwarya
Pant.
- The trace documentation has been converted to RST by Changbin Du
- I thrashed up kernel-doc to deal with a parsing issue and to try to make
the code more readable. It's still a 20+-year-old Perl hack, though.
- Lots of other updates, typo fixes, and more.
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEEUOvtSCFqLxY/7px3jc41VjAi5XoFAlrCPGYPHGNvcmJldEBs
d24ubmV0AAoJEI3ONVYwIuV6izAP/1DpGfBdnrG4TZkCf+qQHT19ZluwGm+wOBF4
+7qa6It4BL4PbSmSSZx79yZIpeSL96codCWMFSrud71WzOzfCtidyzOduuqvEluJ
3Fhl+hxyDYDQGpPt4y7rPbjh23dliXHFzYycfsFn7H9Gj4MX74c6ktRlPUwIgR/D
YFyE2jEKUU/2wblpZgcGdS49AUZAWiC9kS2Z9lSrIswcy+G2eZ1qUfbX60tge0op
nLKWlWwv2hTO0KnYJebdHwQsRe5DkW9smPiG1fsCX5CUT1auZY9FVK3KS2AUVxia
vilpUZrjEzuSa1EKWcflpmR/RuZ37a3fhc+cDoHrnCDp5FxOkdGp035Tx0/mgIDv
I7TrUJzt+jawdVo7fMbsDcSmd12Dmsl16knVN4WXSfD1JUiTZNAIEnEH4fF5fsIF
nvASedA9rsRRvMYEqqFIAPFJxdmfm3mWBKpOVhQyyAT3/T+vR1+rr6pGmThjHL09
DZUCiPpdFqZZ8fhNZQxjQvbIkZFHLCrl1zNENlEPtvOXGZfNTdcag2mA87n4JVfp
gCf1TuEvQ/aCMSL5V7aS3exXeaq1Xe+1P4+JOhY/Rv1SbI1JopChvO8z3ElHsKzN
x+0UBYDjXSeD5LS0lCBytKo3IZLJAxabSLK4eMLdVr60kNi3c3cgtlUjNx+LTRVu
tr7nWWLY
=QQ/a
-----END PGP SIGNATURE-----
Merge tag 'docs-4.17' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"There's been a fair amount of activity in Documentation/ this time
around:
- Lots of work aligning Documentation/ABI with reality, done by
Aishwarya Pant.
- The trace documentation has been converted to RST by Changbin Du
- I thrashed up kernel-doc to deal with a parsing issue and to try to
make the code more readable. It's still a 20+-year-old Perl hack,
though.
- Lots of other updates, typo fixes, and more"
* tag 'docs-4.17' of git://git.lwn.net/linux: (82 commits)
Documentation/process: update FUSE project website
docs: kernel-doc: fix parsing of arrays
dmaengine: Fix spelling for parenthesis in dmatest documentation
dmaengine: Make dmatest.rst indeed reST compatible
dmaengine: Add note to dmatest documentation about supported channels
Documentation: magic-numbers: Fix typo
Documentation: admin-guide: add kvmconfig, xenconfig and tinyconfig commands
Input: alps - Update documentation for trackstick v3 format
Documentation: Mention why %p prints ptrval
COPYING: use the new text with points to the license files
COPYING: create a new file with points to the Kernel license files
Input: trackpoint: document sysfs interface
xfs: Change URL for the project in xfs.txt
char/bsr: add sysfs interface documentation
acpi: nfit: document sysfs interface
block: rbd: update sysfs interface
Documentation/sparse: fix typo
Documentation/CodingStyle: Add an example for braces
docs/vm: update 00-INDEX
kernel-doc: Remove __sched markings
...
This removes the entire architecture code for blackfin, cris, frv, m32r,
metag, mn10300, score, and tile, including the associated device drivers.
I have been working with the (former) maintainers for each one to ensure
that my interpretation was right and the code is definitely unused in
mainline kernels. Many had fond memories of working on the respective
ports to start with and getting them included in upstream, but also saw
no point in keeping the port alive without any users.
In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company
in charge of an SoC line, a CPU microarchitecture and a software
ecosystem, which was more costly than licensing newer off-the-shelf
CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems
that all the SoC product lines are still around, but have not used the
custom CPU architectures for several years at this point. In contrast,
CPU instruction sets that remain popular and have actively maintained
kernel ports tend to all be used across multiple licensees.
The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
marking any ports as deprecated but remove them all at once after I made
sure that they are all unused. Some architectures (notably tile, mn10300,
and blackfin) are still being shipped in products with old kernels,
but those products will never be updated to newer kernel releases.
After this series, we still have a few architectures without mainline
gcc support:
- unicore32 and hexagon both have very outdated gcc releases, but the
maintainers promised to work on providing something newer. At least
in case of hexagon, this will only be llvm, not gcc.
- openrisc, risc-v and nds32 are still in the process of finishing their
support or getting it added to mainline gcc in the first place.
They all have patched gcc-7.3 ports that work to some degree, but
complete upstream support won't happen before gcc-8.1. Csky posted
their first kernel patch set last week, their situation will be similar.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJawdL2AAoJEGCrR//JCVInuH0P/RJAZh1nTD+TR34ZhJq2TBoo
PgygwDU7Z2+tQVU+EZ453Gywz9/NMRFk1RWAZqrLix4ZtyIMvC6A1qfT2yH1Y7Fb
Qh6tccQeLe4ezq5u4S/46R/fQXu3Txr92yVwzJJUuPyU0arF9rv5MmI8e6p7L1en
yb74kSEaCe+/eMlsEj1Cc1dgthDNXGKIURHkRsILoweysCpesjiTg4qDcL+yTibV
FP2wjVbniKESMKS6qL71tiT5sexvLsLwMNcGiHPj94qCIQuI7DLhLdBVsL5Su6gI
sbtgv0dsq4auRYAbQdMaH1hFvu6WptsuttIbOMnz2Yegi2z28H8uVXkbk2WVLbqG
ZESUwutGh8MzOL2RJ4jyyQq5sfo++CRGlfKjr6ImZRv03dv0pe/W85062cK5cKNs
cgDDJjGRorOXW7dyU6jG2gRqODOQBObIv3w5efdq5OgzOWlbI4EC+Y5u1Z0JF/76
pSwtGXA6YhwC+9LLAlnVTHG+yOwuLmAICgoKcTbzTVDKA2YQZG/cYuQfI5S1wD8e
X6urPx3Md2GCwLXQ9mzKBzKZUpu/Tuhx0NvwF4qVxy6x1PELjn68zuP7abDHr46r
57/09ooVN+iXXnEGMtQVS/OPvYHSa2NgTSZz6Y86lCRbZmUOOlK31RDNlMvYNA+s
3iIVHovno/JuJnTOE8LY
=fQ8z
-----END PGP SIGNATURE-----
Merge tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pul removal of obsolete architecture ports from Arnd Bergmann:
"This removes the entire architecture code for blackfin, cris, frv,
m32r, metag, mn10300, score, and tile, including the associated device
drivers.
I have been working with the (former) maintainers for each one to
ensure that my interpretation was right and the code is definitely
unused in mainline kernels. Many had fond memories of working on the
respective ports to start with and getting them included in upstream,
but also saw no point in keeping the port alive without any users.
In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company in
charge of an SoC line, a CPU microarchitecture and a software
ecosystem, which was more costly than licensing newer off-the-shelf
CPU cores from a third party (typically ARM, MIPS, or RISC-V). It
seems that all the SoC product lines are still around, but have not
used the custom CPU architectures for several years at this point. In
contrast, CPU instruction sets that remain popular and have actively
maintained kernel ports tend to all be used across multiple licensees.
[ See the new nds32 port merged in the previous commit for the next
generation of "one company in charge of an SoC line, a CPU
microarchitecture and a software ecosystem" - Linus ]
The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
marking any ports as deprecated but remove them all at once after I
made sure that they are all unused. Some architectures (notably tile,
mn10300, and blackfin) are still being shipped in products with old
kernels, but those products will never be updated to newer kernel
releases.
After this series, we still have a few architectures without mainline
gcc support:
- unicore32 and hexagon both have very outdated gcc releases, but the
maintainers promised to work on providing something newer. At least
in case of hexagon, this will only be llvm, not gcc.
- openrisc, risc-v and nds32 are still in the process of finishing
their support or getting it added to mainline gcc in the first
place. They all have patched gcc-7.3 ports that work to some
degree, but complete upstream support won't happen before gcc-8.1.
Csky posted their first kernel patch set last week, their situation
will be similar
[ Palmer Dabbelt points out that RISC-V support is in mainline gcc
since gcc-7, although gcc-7.3.0 is the recommended minimum - Linus ]"
This really says it all:
2498 files changed, 95 insertions(+), 467668 deletions(-)
* tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (74 commits)
MAINTAINERS: UNICORE32: Change email account
staging: iio: remove iio-trig-bfin-timer driver
tty: hvc: remove tile driver
tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
serial: remove tile uart driver
serial: remove m32r_sio driver
serial: remove blackfin drivers
serial: remove cris/etrax uart drivers
usb: Remove Blackfin references in USB support
usb: isp1362: remove blackfin arch glue
usb: musb: remove blackfin port
usb: host: remove tilegx platform glue
pwm: remove pwm-bfin driver
i2c: remove bfin-twi driver
spi: remove blackfin related host drivers
watchdog: remove bfin_wdt driver
can: remove bfin_can driver
mmc: remove bfin_sdh driver
input: misc: remove blackfin rotary driver
input: keyboard: remove bf54x driver
...
Now recordmcount.pl recognizes RISC-V object files. For the mechanism to
work, we have to disable the linker relaxation.
Cc: Greentime Hu <greentime@andestech.com>
Signed-off-by: Alan Kao <alankao@andestech.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJavDxYAAoJEAx081l5xIa+pCoP/iwjuxkSTdJpZUx5g0daGkCK
O18moGqGPChb7qJovfHqCKZ1f9PGulQt7SxwFzzJXNbv0PbfMA/Og0EhMLBImb+Q
VfYgq2vJLpmkikgcI5fBrzs9DRMQKKobGIzw24VS7IkPYA7d8KgAyywBwG0+LUFR
G3sobClgapsfaUcleb3ZOeDwymGkGCuuYRpYE4giHtuMDIxCWLePKJKOaOIq8o6P
A1557EvSbKuLQGI9X50jzJOoBE3TKRQYkzuM1GthdOF8RHaMNcFy44lDNO030HwZ
hzwAIg5Izhu16PqZGyEdIQ6SJTv3isRJWEciPnOsijvjl1li3ehMdQfhGISa/jZO
ivEGd32kaactiT0jJ5OyexergEViCPVKCIORksSIk46L84luDva9L22A3yu0mf3F
ixB63bAiLH7Py77kH3DmeJdqhMxlVZXCbdBVFDvzZvY4O3Mx0Dv9mmN/nw1FVCFH
scSYnXea9/o4IY5yGASU6FAUJEEGu20HAN12oHJw7/taqV/gbbEos3F7AGmjJE0f
qe6Rt/8fwi7Lhm2va6EoOo6yltH/gL4/AgnsN76VzppNGbaIv7W8Qa4Y/ES1lAE1
SATAEUJfU8kiLrVOolIElPbgfdJwv8TzoxiKB5wK/eoH20wf4BTmOuBMviaL2qXK
Sz6wihq+IlMXW7Y7pIl/
=DrA+
-----END PGP SIGNATURE-----
Merge tag 'drm-for-v4.17' of git://people.freedesktop.org/~airlied/linux
Pull drm updates from Dave Airlie:
"Cannonlake and Vega12 support are probably the two major things. This
pull lacks nouveau, Ben had some unforseen leave and a few other
blockers so we'll see how things look or maybe leave it for this merge
window.
core:
- Device links to handle sound/gpu pm dependency
- Color encoding/range properties
- Plane clipping into plane check helper
- Backlight helpers
- DP TP4 + HBR3 helper support
amdgpu:
- Vega12 support
- Enable DC by default on all supported GPUs
- Powerplay restructuring and cleanup
- DC bandwidth calc updates
- DC backlight on pre-DCE11
- TTM backing store dropping support
- SR-IOV fixes
- Adding "wattman" like functionality
- DC crc support
- Improved DC dual-link handling
amdkfd:
- GPUVM support for dGPU
- KFD events for dGPU
- Enable PCIe atomics for dGPUs
- HSA process eviction support
- Live-lock fixes for process eviction
- VM page table allocation fix for large-bar systems
panel:
- Raydium RM68200
- AUO G104SN02 V2
- KEO TX31D200VM0BAA
- ARM Versatile panels
i915:
- Cannonlake support enabled
- AUX-F port support added
- Icelake base enabling until internal milestone of forcewake support
- Query uAPI interface (used for GPU topology information currently)
- Compressed framebuffer support for sprites
- kmem cache shrinking when GPU is idle
- Avoid boosting GPU when waited item is being processed already
- Avoid retraining LSPCON link unnecessarily
- Decrease request signaling latency
- Deprecation of I915_SET_COLORKEY_NONE
- Kerneldoc and compiler warning cleanup for upcoming CI enforcements
- Full range ycbcr toggling
- HDCP support
i915/gvt:
- Big refactor for shadow ppgtt
- KBL context save/restore via LRI cmd (Weinan)
- Properly unmap dma for guest page (Changbin)
vmwgfx:
- Lots of various improvements
etnaviv:
- Use the drm gpu scheduler
- prep work for GC7000L support
vc4:
- fix alpha blending
- Expose perf counters to userspace
pl111:
- Bandwidth checking/limiting
- Versatile panel support
sun4i:
- A83T HDMI support
- A80 support
- YUV plane support
- H3/H5 HDMI support
omapdrm:
- HPD support for DVI connector
- remove lots of static variables
msm:
- DSI updates from 10nm / SDM845
- fix for race condition with a3xx/a4xx fence completion irq
- some refactoring/prep work for eventual a6xx support (ie. when we
have a userspace)
- a5xx debugfs enhancements
- some mdp5 fixes/cleanups to prepare for eventually merging
writeback
- support (ie. when we have a userspace)
tegra:
- mmap() fixes for fbdev devices
- Overlay plane for hw cursor fix
- dma-buf cache maintenance support
mali-dp:
- YUV->RGB conversion support
rockchip:
- rk3399/chromebook fixes and improvements
rcar-du:
- LVDS support move to drm bridge
- DT bindings for R8A77995
- Driver/DT support for R8A77970
tilcdc:
- DRM panel support"
* tag 'drm-for-v4.17' of git://people.freedesktop.org/~airlied/linux: (1646 commits)
drm/i915: Fix hibernation with ACPI S0 target state
drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt
drm/i915: Specify which engines to reset following semaphore/event lockups
drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
drm/amdkfd: Use ordered workqueue to restore processes
drm/amdgpu: Fix acquiring VM on large-BAR systems
drm/amd/pp: clean header file hwmgr.h
drm/amd/pp: use mlck_table.count for array loop index limit
drm: Fix uabi regression by allowing garbage mode->type from userspace
drm/amdgpu: Add an ATPX quirk for hybrid laptop
drm/amdgpu: fix spelling mistake: "asssert" -> "assert"
drm/amd/pp: Add new asic support in pp_psm.c
drm/amd/pp: Clean up powerplay code on Vega12
drm/amd/pp: Add smu irq handlers for legacy asics
drm/amd/pp: Fix set wrong temperature range on smu7
drm/amdgpu: Don't change preferred domian when fallback GTT v5
drm/vmwgfx: Bump version patchlevel and date
drm/vmwgfx: use monotonic event timestamps
drm/vmwgfx: Unpin the screen object backup buffer when not used
drm/vmwgfx: Stricter count of legacy surface device resources
...
Since commit 28128c61e0 ("kconfig.h: Include compiler types to avoid
missed struct attributes"), <linux/kconfig.h> pulls in kernel-space
headers to unrelated places.
Commit 0f9da844d8 ("MIPS: boot: Define __ASSEMBLY__ for its.S build")
suppress the build error by defining __ASSEMBLY__, but ITS (i.e. DTS)
is not assembly, and should not include <linux/compiler_types.h> in the
first place.
Looking at arch/s390/tools/Makefile, host programs gen_facilities and
gen_opcode_table now pull in <linux/compiler_types.h> as well.
The motivation for that commit was to define necessary attributes
before any struct is defined. Obviously, this happens only in C.
It is enough to include <linux/compiler_types.h> only when compiling
C files, and only when compiling kernel space. Move the include to
c_flags.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The logic with parses array has a bug that prevents it to
parse arrays like:
struct {
...
struct {
u64 msdu[IEEE80211_NUM_TIDS + 1];
...
...
Fix the parser to accept it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJauCZfAAoJEHm+PkMAQRiGWGUH/2rhdQDkoJpYWnjaQkolECG8
MxpGE7nmIIHxQcbSDdHTGJ8IhVm6Z5wZ7ym/PwCDTT043Y1y341sJrIwL2/nTG6d
HVidk8hFvgN6QzlzVAHT3ZZMII/V9Zt+VV5SUYLGnPAVuJNHo/6uzWlTU5g+NTFo
IquFDdQUaGBlkKqby+NoAFnkV1UAIkW0g22cfvPnlO5GMer0gusGyVNvVp7TNj3C
sqj4Hvt3RMDLMNe9RZ2pFTiOD096n8FWpYftZneUTxFImhRV3Jg5MaaYZm9SI3HW
tXrv/LChT/F1mi5Pkx6tkT5Hr8WvcrwDMJ4It1kom10RqWAgjxIR3CMm448ileY=
=YKUG
-----END PGP SIGNATURE-----
Backmerge tag 'v4.16-rc7' into drm-next
Linux 4.16-rc7
This was requested by Daniel, and things were getting
a bit hard to reconcile, most of the conflicts were
trivial though.
There is a change in how command line parsing is done in this version.
Excludes and includes are now ordered with the file list. Since
the spec file puts the file list before the exclude list it means newer
tar ignores the excludes and packs all the build output into the
kernel-devel RPM resulting in a huge package.
Simple argument re-ordering fixes the problem.
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since d5d332d3f7, a couple of links in scripts/dtc/include-prefixes
are additionally required in order to build device trees with the header
package.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The Blackfin port has been removed from the kernel, also remove the
blackfin specific bits from the checkstack.pl script.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
These two architectures are getting removed, so we no longer
need the special cases.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tracking the line number by hand is error-prone since you need to
increment it in every \n matching pattern.
If '%option yylineno' is set, flex defines 'yylineno' to contain the
current line number and automatically updates it each time it reads a
\n character. This is much more convenient although the lexer does
not initializes yylineno, so you need to set it to 1 each time you
start reading a new file, and restore it you go back to the previous
file.
I tested this with DEBUG_PARSE, and confirmed the same dump message
was produced.
I removed the perf-report option. Otherwise, I see the following
message:
%option yylineno entails a performance penalty ONLY on rules that
can match newline characters
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the recursive inclusion is not detected when the offending
file is about to be included; it is detected the offending file is
about to include the *next* file. This is because the detection loop
does not involve the file being included.
Do this check against the file that is about to be included so that
the recursive inclusion is detected before unneeded parsing happens.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As in the unit test, the error message for the recursive inclusion
looks like this:
Kconfig.inc1:4: recursive inclusion detected. Inclusion path:
current file : 'Kconfig.inc1'
included from: 'Kconfig.inc3:1'
included from: 'Kconfig.inc2:3'
included from: 'Kconfig.inc1:4'
The 'Kconfig.inc1:4' is duplicated in the first and last lines.
Also, the single quotes do not help readability.
Change the message like follows:
Recursive inclusion detected.
Inclusion path:
current file : Kconfig.inc1
included from: Kconfig.inc3:1
included from: Kconfig.inc2:3
included from: Kconfig.inc1:4
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
nconf.h includes <curses.h> and "ncurses.h", but it does not need to
include both. Generally, it should fall back to curses.h only when
ncurses.h is not found. But, looks like it has never happened;
these includes have been here for many years since commit 692d97c380
("kconfig: new configuration interface (nconfig)"), and nobody has
complained about hard-coding of ncurses.h . Let's simply drop the
curses.h inclusion.
I replaced "ncurses.h" with <ncurses.h> since it is not a local file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.
Here is test code to demonstrate how it currently works.
[Test Case]
config DEP1
def_bool y
config DEP2
bool "DEP2"
config A
bool "A"
select E
config B
bool "B"
depends on DEP2
select E
config C
bool "C"
depends on DEP1 && DEP2
select E
config D
def_bool n
select E
config E
bool
depends on DEP1 && DEP2
[Result]
$ make config
scripts/kconfig/conf --oldaskconfig Kconfig
*
* Linux Kernel Configuration
*
DEP2 (DEP2) [N/y/?] (NEW) n
A (A) [N/y/?] (NEW) y
warning: (A && B && D) selects E which has unmet direct
dependencies (DEP1 && DEP2)
Here, I see some points to be improved.
First, '(A || B || D)' would make more sense than '(A && B && D)'.
I am not sure if this is intentional, but expr_simplify_unmet_dep()
turns OR expressions into AND, like follows:
case E_OR:
return expr_alloc_and(
Second, we see false positives. 'A' is a real unmet dependency.
'B' is false positive because 'DEP1' is fixed to 'y', and 'B' depends
on 'DEP2'. 'C' was correctly dropped by expr_simplify_unmet_dep().
'D' is also false positive because it has no chance to be enabled.
Current expr_simplify_unmet_dep() cannot avoid those false positives.
After all, I decided to use the same helpers as used for printing
reverse dependencies in the help.
With this commit, unreadable warnings (most of the reported symbols are
false positives) in the real world:
$ make ARCH=score allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM &&
DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_OXNAS && DWMAC_ROCKCHIP &&
DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_GEMINI &&
PINCTRL_OXNAS && PINCTRL_ROCKCHIP && PINCTRL_DOVE &&
PINCTRL_ARMADA_37XX && PINCTRL_STM32 && S3C2410_WATCHDOG &&
VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 &&
LPC18XX_DMAMUX && VIDEO_OMAP4 && COMMON_CLK_GEMINI &&
COMMON_CLK_ASPEED && COMMON_CLK_NXP && COMMON_CLK_OXNAS &&
COMMON_CLK_BOSTON && QCOM_ADSP_PIL && QCOM_Q6V5_PIL && QCOM_GSBI &&
ATMEL_EBI && ST_IRQCHIP && RESET_IMX7 && PHY_HI6220_USB &&
PHY_RALINK_USB && PHY_ROCKCHIP_PCIE && PHY_DA8XX_USB) selects
MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
warning: (PINCTRL_AT91 && PINCTRL_AT91PIO4 && PINCTRL_OXNAS &&
PINCTRL_PISTACHIO && PINCTRL_PIC32 && PINCTRL_MESON &&
PINCTRL_NOMADIK && PINCTRL_MTK && PINCTRL_MT7622 && GPIO_TB10X)
selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF &&
HAS_IOMEM)
warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && LOCKDEP)
selects FRAME_POINTER which has unmet direct dependencies
(DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN ||
MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS)
will be turned into:
$ make ARCH=score allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
WARNING: unmet direct dependencies detected for MFD_SYSCON
Depends on [n]: HAS_IOMEM [=n]
Selected by [y]:
- PINCTRL_STM32 [=y] && PINCTRL [=y] && (ARCH_STM32 ||
COMPILE_TEST [=y]) && OF [=y]
- RTC_DRV_AT91SAM9 [=y] && RTC_CLASS [=y] && (ARCH_AT91 ||
COMPILE_TEST [=y])
- RESET_IMX7 [=y] && RESET_CONTROLLER [=y]
- PHY_HI6220_USB [=y] && (ARCH_HISI && ARM64 ||
COMPILE_TEST [=y])
- PHY_RALINK_USB [=y] && (RALINK || COMPILE_TEST [=y])
- PHY_ROCKCHIP_PCIE [=y] && (ARCH_ROCKCHIP && OF [=y] ||
COMPILE_TEST [=y])
WARNING: unmet direct dependencies detected for OF_GPIO
Depends on [n]: GPIOLIB [=y] && OF [=y] && HAS_IOMEM [=n]
Selected by [y]:
- PINCTRL_MTK [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
COMPILE_TEST [=y]) && OF [=y]
- PINCTRL_MT7622 [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
COMPILE_TEST [=y]) && OF [=y] && (ARM64 || COMPILE_TEST [=y])
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=y] && (CRIS || M68K || FRV || UML ||
SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS [=n]
Selected by [y]:
- LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] &&
PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND &&
!ARC && !X86
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Commit 246cf9c26b ("kbuild: Warn on selecting symbols with unmet
direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
So, the unmet direct dependencies of tristate symbols are not reported.
[Test Case]
config MODULES
def_bool y
option modules
config A
def_bool y
select B
config B
tristate "B"
depends on m
This causes unmet dependency because 'B' is forced 'y' ignoring
'depends on m'. This should be warned.
On the other hand, the following case ('B' is bool) should not be
warned, so 'depends on m' for bool symbols should be naturally treated
as 'depends on y'.
[Test Case2 (not unmet dependency)]
config MODULES
def_bool y
option modules
config A
def_bool y
select B
config B
bool "B"
depends on m
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
If recursive inclusion is detected, it should fail with error
messages. Test this.
This also tests the line numbers in the error message, fixed by
commit 5ae6fcc4bb ("kconfig: fix line number in recursive inclusion
error message").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Recursive dependency should be detected and warned. Test this.
This indirectly tests the line number increments.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit 3b9a19e089 ("kconfig: loop as long as we changed some symbols
in randconfig") fixed randconfig where a choice contains a sub-choice.
Prior to that commit, the sub-choice values were not set.
I am not sure whether this is an intended feature or just something
people discovered works, but it is used in the real world;
drivers/usb/gadget/legacy/Kconfig is source'd in a choice context,
then creates a sub-choice in it.
For the test case in this commit, there are 3 possible results.
Case 1:
CONFIG_A=y
# CONFIG_B is not set
Case 2:
# CONFIG_A is not set
CONFIG_B=y
CONFIG_C=y
# CONFIG_D is not set
Case 3:
# CONFIG_A is not set
CONFIG_B=y
# CONFIG_C is not set
CONFIG_D=y
CONFIG_E=y
So, this test iterates several times, and checks if the result is
either of the three.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit fbe98bb9ed ("kconfig: Fix defconfig when one choice menu
selects options that another choice menu depends on") fixed defconfig
when two choices interact (i.e. calculating the visibility of a choice
requires to calculate another choice).
The test code in that commit log was based on the real world example,
and complicated. So, I shrunk it down to the following:
defconfig.choice:
---8<---
CONFIG_CHOICE_VAL0=y
---8<---
---8<---
config MODULES
def_bool y
option modules
choice
prompt "Choice"
config CHOICE_VAL0
tristate "Choice 0"
config CHOICE_VAL1
tristate "Choice 1"
endchoice
choice
prompt "Another choice"
depends on CHOICE_VAL0
config DUMMY
bool "dummy"
endchoice
---8<---
Prior to commit fbe98bb9ed,
$ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice
resulted in:
CONFIG_MODULES=y
CONFIG_CHOICE_VAL0=m
# CONFIG_CHOICE_VAL1 is not set
CONFIG_DUMMY=y
where the expected result would be:
CONFIG_MODULES=y
CONFIG_CHOICE_VAL0=y
# CONFIG_CHOICE_VAL1 is not set
CONFIG_DUMMY=y
Roughly, this weird behavior happened like this:
Symbols are calculated a couple of times. First, all symbols are
calculated in conf_read(). The first 'choice' is evaluated to 'y'
due to the SYMBOL_DEF_USER flag, but sym_calc_choice() clears it
unless all of its choice values are explicitly set by the user.
conf_set_all_new_symbols() clears all SYMBOL_VALID flags. Then, only
choices are calculated. Here, the SYMBOL_DEF_USER for the first choice
has been forgotten, so it is evaluated to 'm'. set_all_choice_values()
sets SYMBOL_DEF_USER again to choice symbols.
When calculating the second choice, due to 'depends on CHOICE_VAL0',
it triggers the calculation of CHOICE_VAL0. As a result, SYMBOL_VALID
is set for CHOICE_VAL0.
Symbols except choices get the final chance of re-calculation in
conf_write(). In a normal case, CHOICE_VAL0 would be re-calculated,
then the first choice would be indirectly re-calculated with the
SYMBOL_DEF_USER which has been recalled by set_all_choice_values(),
which would be evaluated to 'y'. But, in this case, CHOICE_VAL0 has
already been marked as SYMBOL_VALID, so this re-calculation does not
happen. Then, =m from the conf_set_all_new_symbols() phase is written
out to the .config file.
Add a unit test for this naive case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If tristate choice values depend on symbols set to 'm', they should be
hidden when the choice containing them is changed from 'm' to 'y'
(i.e. exclusive choice).
This issue was fixed by commit fa64e5f6a3 ("kconfig/symbol.c: handle
choice_values that depend on 'm' symbols").
Add a test case to avoid regression.
For the input in this unit test, there is a room for argument if
"# CONFIG_CHOICE1 is not set" should be written to the .config file.
After commit fa64e5f6a3, this line was written to the .config file.
With commit cb67ab2cd2 ("kconfig: do not write choice values when
their dependency becomes n"), it is not written now.
In this test, "# CONFIG_CHOICE1 is not set" is don't care.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit cb67ab2cd2 ("kconfig: do not write choice values when their
dependency becomes n") fixed a problem where "# CONFIG_... is not set"
for choice values are wrongly written into the .config file when they
are once visible, then become invisible later.
Add a test for this naive case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If new choice values are added with new dependency, and they become
visible during user configuration, oldconfig should recognize them
as (NEW), and ask the user for choice.
This issue was fixed by commit 5d09598d48 ("kconfig: fix new choices
being skipped upon config update").
This is a subtle corner case. Add a test case to avoid breakage.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If a symbols has dependency on the preceding symbol, the menu entry
should become the submenu of the preceding one, and displayed with
deeper indentation.
This is done by restructuring the menu tree in menu_finalize().
It is a bit complicated computation, so let's add a test case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The calculation of 'choice' is a bit complicated part in Kconfig.
The behavior of 'y' choice is intuitive. If choice values are tristate,
the choice can be 'm' where each value can be enabled independently.
Also, if a choice is marked as 'optional', the whole choice can be
invisible.
Test basic functionality of choice.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Many parts in Kconfig are so cryptic and need refactoring. However,
its complexity prevents us from moving forward. There are several
naive corner cases where it is difficult to notice breakage. If
those are covered by unit tests, we will be able to touch the code
with more confidence.
Here is a simple test framework based on pytest. The conftest.py
provides a fixture useful to run commands such as 'oldaskconfig' etc.
and to compare the resulted .config, stdout, stderr with expectations.
How to add test cases?
----------------------
For each test case, you should create a subdirectory under
scripts/kconfig/tests/ (so test cases are separated from each other).
Every test case directory should contain the following files:
- __init__.py: describes test functions
- Kconfig: the top level Kconfig file for the test
To do a useful job, test cases generally need additional data like
input .config and information about expected results.
How to run tests?
-----------------
You need python3 and pytest. Then, run "make testconfig". O= option
is supported. If V=1 is given, detailed logs captured during tests
are displayed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The local{yes,mod}config targets currently have streamline_config.pl as
a prerequisite. This is redundant, because streamline_config.pl is a
checked-in file with no prerequisites.
Remove the prerequisite and reference streamline_config.pl directly in
the recipe of the rule instead.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As commit cedd55d49d ("kconfig: Remove silentoldconfig from help
and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
historical misnomer. That commit removed it from help and docs since
it is an internal interface. If so, it should be allowed to rename
it to something more intuitive. 'syncconfig' is the one I came up
with because it updates the .config if necessary, then synchronize
include/generated/autoconf.h and include/config/* with it.
You should not manually invoke 'silentoldcofig'. Display warning if
used in case existing scripts are doing wrong.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The purpose of local{yes,mod}config is to arrange the .config file
based on actually loaded modules. It is unnecessary to update
include/generated/autoconf.h and include/config/* stuff here.
They will be updated as needed during the build.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Historically, "make oldconfig" has changed its behavior several times,
quieter or louder. (I attached the history below.) Currently, it is
not as quiet as it should be. This commit addresses it.
Test Case
---------
---------------------------(Kconfig)----------------------------
menu "menu"
config FOO
bool "foo"
menu "sub menu"
config BAR
bool "bar"
endmenu
endmenu
menu "sibling menu"
config BAZ
bool "baz"
endmenu
----------------------------------------------------------------
---------------------------(.config)----------------------------
CONFIG_BAR=y
CONFIG_BAZ=y
----------------------------------------------------------------
With the Kconfig and .config above, "make silentoldconfig" and
"make oldconfig" work differently, like follows:
$ make silentoldconfig
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
#
# configuration written to .config
#
$ make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
*
* sub menu
*
bar (BAR) [Y/n/?] y
#
# configuration written to .config
#
Both hide "sibling node" since it is irrelevant. The difference is
that silentoldconfig hides "sub menu" whereas oldconfig does not.
The behavior of silentoldconfig is preferred since the "sub menu"
does not contain any new symbol.
The root cause is in conf(). There are three input modes that can
call conf(); oldaskconfig, oldconfig, and silentoldconfig.
Everytime conf() encounters a menu entry, it calls check_conf() to
check if it contains new symbols. If no new symbol is found, the
menu is just skipped.
Currently, this happens only when input_mode == silentoldconfig.
The oldaskconfig enters into the check_conf() loop as silentoldconfig,
so oldaskconfig works likewise for the second loop or later, but it
never happens for oldconfig. So, irrelevant sub-menus are shown for
oldconfig.
Change the test condition to "input_mode != oldaskconfig". This is
false only for the first loop of oldaskconfig; it must ask the user
all symbols, so no need to call check_conf().
History of oldconfig
--------------------
[0] Originally, "make oldconfig" was as loud as "make config" (It
showed the entire .config file)
[1] Commit cd9140e1e7 ("kconfig: make oldconfig is now less chatty")
made oldconfig quieter, but it was still less quieter than
silentoldconfig. (oldconfig did not hide sub-menus)
[2] Commit 204c96f609 ("kconfig: fix silentoldconfig") changed
the input_mode of oldconfig to "ask_silent" from "ask_new".
So, oldconfig really became as quiet as silentoldconfig.
(oldconfig hided irrelevant sub-menus)
[3] Commit 4062f1a4c0 ("kconfig: use long options in conf") made
oldconfig as loud as [0] due to misconversion.
[4] Commit 1482834971 ("kconfig: fix make oldconfig") addressed
the misconversion of [3], but it made oldconfig quieter only to
the same level as [1], not [2].
This commit is restoring the behavior of [2].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
check_conf() never increments conf_cnt for listnewconfig, so conf_cnt
is always zero.
In other words, conf_cnt is not zero, "input_mode != listnewconfig"
is met.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
conf() is never called for listnewconfig / olddefconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
check_conf() traverses the menu tree, but it is completely no-op for
olddefconfig because the following if-else block does nothing.
if (input_mode == listnewconfig) {
...
} else if (input_mode != olddefconfig) {
...
}
As the help message says, olddefconfig automatically sets new symbols
to their default value. There is no room for manual intervention.
So, calling check_conf() for olddefconfig is odd in the first place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
=== Background ===
- Visible n-valued bool/tristate symbols generate a
'# CONFIG_FOO is not set' line in the .config file. The idea is to
remember the user selection without having to set a Makefile
variable. Having n correspond to the variable being undefined in the
Makefiles makes for easy CONFIG_* tests.
- Invisible n-valued bool/tristate symbols normally do not generate a
'# CONFIG_FOO is not set' line, because user values from .config
files have no effect on invisible symbols anyway.
Currently, there is one exception to this rule: Any bool/tristate symbol
that gets the value n through a 'default' property generates a
'# CONFIG_FOO is not set' line, even if the symbol is invisible.
Note that this only applies to explicitly given defaults, and not when
the symbol implicitly defaults to n (like bool/tristate symbols without
'default' properties do).
This is inconsistent, and seems redundant:
- As mentioned, the '# CONFIG_FOO is not set' won't affect the symbol
once the .config is read back in.
- Even if the symbol is invisible at first but becomes visible later,
there shouldn't be any harm in recalculating the default value
rather than viewing the '# CONFIG_FOO is not set' as a previous
user value of n.
=== Changes ===
Change sym_calc_value() to only set SYMBOL_WRITE (write to .config) for
non-n-valued 'default' properties.
Note that SYMBOL_WRITE is always set for visible symbols regardless of whether
they have 'default' properties or not, so this change only affects invisible
symbols.
This reduces the size of the x86 .config on my system by about 1% (due
to removed '# CONFIG_FOO is not set' entries).
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
This change only affects generated .config files and not autoconf.h:
autoconf.h only includes #defines for non-n bool/tristate symbols.
=== Testing ===
The following testing was done with the x86 Kconfigs:
- .config files generated before and after the change were compared to
verify that the only difference is some '# CONFIG_FOO is not set'
entries disappearing. A couple of these were inspected manually, and
most turned out to be from redundant 'default n/def_bool n'
properties.
- The generated include/generated/autoconf.h was compared before and
after the change and verified to be identical.
- As a sanity check, the same modification was done to Kconfiglib.
The Kconfiglib test suite was then run to check for any mismatches
against the output of the C implementation.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Surprisingly or not, disabling a CONFIG option (which is assumed to
be unneeded) may be not so trivial. Especially it is not trivial, when
this CONFIG option is selected by a dozen of other configs. Before the
moment commit 1ccb271433 ("kconfig: make "Selected by:" and
"Implied by:" readable") popped up in v4.16-rc1, it was an absolute pain
to break down the "Selected by" reverse dependency expression in order
to identify all those configs which select (IOW *do not allow
disabling*) a certain feature (assumed to be not needed).
This patch tries to make one step further by putting at users'
fingertips the revdep top level OR sub-expressions grouped/clustered by
the tristate value they evaluate to. This should allow the users to
directly concentrate on and tackle the _active_ reverse dependencies.
To give some numbers and quantify the complexity of certain reverse
dependencies, assuming commit 617aebe6a9 ("Merge tag
'usercopy-v4.16-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux"), ARCH=arm64
and vanilla arm64 defconfig, here is the top 10 CONFIG options with
the highest amount of top level "||" sub-expressions/tokens that make
up the final "Selected by" reverse dependency expression.
| Config | All revdep | Active revdep |
|-------------------|------------|---------------|
| REGMAP_I2C | 212 | 9 |
| CRC32 | 167 | 25 |
| FW_LOADER | 128 | 5 |
| MFD_CORE | 124 | 9 |
| FB_CFB_IMAGEBLIT | 114 | 2 |
| FB_CFB_COPYAREA | 111 | 2 |
| FB_CFB_FILLRECT | 110 | 2 |
| SND_PCM | 103 | 2 |
| CRYPTO_HASH | 87 | 19 |
| WATCHDOG_CORE | 86 | 6 |
The story behind the above is that users need to visually
review/evaluate 212 expressions which *potentially* select REGMAP_I2C
in order to identify the expressions which *actually* select REGMAP_I2C,
for a particular ARCH and for a particular defconfig used.
To make this experience smoother, change the way reverse dependencies
are displayed to the user from [1] to [2].
[1] Old representation of DMA_ENGINE_RAID:
Selected by:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || 440SP)
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
[2] New representation of DMA_ENGINE_RAID:
Selected by [y]:
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
Selected by [m]:
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
Selected by [n]:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit splits out the special E_OR handling ('-' instead of '||')
into a dedicated helper expr_print_revdev().
Restore the original expr_print() prior to commit 1ccb271433
("kconfig: make "Selected by:" and "Implied by:" readable").
This makes sense because:
- We need to chop those expressions only when printing the reverse
dependency, and only when E_OR is encountered
- Otherwise, it should be printed as before, so fall back to
expr_print()
This also improves the behavior; for a single line, it was previously
displayed in the same line as "Selected by", like this:
Selected by: A [=n] && B [=n]
This will be displayed in a new line, consistently:
Selected by:
- A [=n] && B [=n]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
IMO, we should discourage '---help---' for new help texts, even in cases
where it would be consistent with other help texts in the file. This
will help if we ever want to get rid of '---help---' in the future.
Also simplify the code to only check for exactly '---help---'. Since
commit c2264564df ("kconfig: warn of unhandled characters in Kconfig
commands"), '---help---' is a proper keyword and can only appear in that
form. Prior to that commit, '---help---' working was more of a syntactic
quirk.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, only Kconfig symbols are checked for a missing or short help
text, and are only checked if they are defined with the 'config'
keyword.
To make the check more general, extend it to also check help texts for
choices and for symbols defined with the 'menuconfig' keyword.
This increases the accuracy of the check for symbols that would already
have been checked as well, since e.g. a 'menuconfig' symbol after a help
text will be recognized as ending the preceding symbol/choice
definition.
To increase the accuracy of the check further, also recognize 'if',
'endif', 'menu', 'endmenu', 'endchoice', and 'source' as ending a
symbol/choice definition.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The check for a missing or short help text only considers symbols with a
prompt, but doesn't recognize any of the following as a prompt:
bool 'foo'
tristate 'foo'
prompt "foo"
prompt 'foo'
Make the check recognize those too.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
With the incremental linking entirely dropped, we can simplify
the Makefile.
While I am here, I renamed cmd_link_o_target to cmd_ar_builtin.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When built-in.o was incrementally linked with 'ld -r', the section
mismatch analysis for the individual built-in.o was possible when
CONFIG_DEBUG_SECTION_MISMATCH was enabled.
With the migration to the thin archive, built-in.a (former, built-in.o)
is no longer an ELF file. So, the modpost does nothing useful.
scripts/mod/modpost.c just checks the header to bail out, as follows:
/* Is this a valid ELF file? */
if ((hdr->e_ident[EI_MAG0] != ELFMAG0) ||
(hdr->e_ident[EI_MAG1] != ELFMAG1) ||
(hdr->e_ident[EI_MAG2] != ELFMAG2) ||
(hdr->e_ident[EI_MAG3] != ELFMAG3)) {
/* Not an ELF file - silently ignore it */
return 0;
}
We have the full analysis in the final link stage anyway, so we would
not miss the section mismatching.
I do not see a good reason to require extra linking only for the
purpose of the per-directory analysis. Just get rid of this part.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
In Kbuild, Makefiles can add the same object to obj-y multiple
times. So,
obj-y += foo.o
obj-y += foo.o
is fine.
However, this is not true when the same object is added multiple
times via composite objects. For example,
obj-y += foo.o bar.o
foo-objs := foo-bar-common.o foo-only.o
bar-objs := foo-bar-common.o bar-only.o
causes build error because two instances of foo-bar-common.o are
linked into the vmlinux.
Makefiles tend to invent ugly work-around, for example
- lib/zstd/Makefile
- drivers/net/ethernet/cavium/liquidio/Makefile
The technique used in Kbuild to avoid the multiple definition error
is to use $(filter $(obj-y), $^). Here, $^ lists the names of all
the prerequisites with duplicated names removed.
By replacing it with $(filter $(real-obj-y), $^) we can do likewise
for composite objects. For built-in objects, we do not need to keep
the composite object structure. We can simply expand them, and link
$(real-obj-y) to built-in.a.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When I was refactoring Makefiles, I stupidly mistook 'real-obj-y' for
'real-objs-y' over and over again. Finally, I decide to rename it to
'real-obj-y'. This is consistent with 'obj-y', 'subdir-obj-y'.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Just a cosmetic change to put related code close together.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Linus Torvalds