summaryrefslogtreecommitdiffstats
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2018-04-03Merge tag 'kconfig-v4.17' of ↵Linus Torvalds55-135/+1037
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 ...
2018-04-03Merge tag 'kbuild-v4.17' of ↵Linus Torvalds12-181/+142
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 ...
2018-04-03Merge tag 'docs-4.17' of git://git.lwn.net/linuxLinus Torvalds2-303/+396
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 ...
2018-04-02Merge tag 'arch-removal' of ↵Linus Torvalds5-65/+3
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 ...
2018-04-02Merge tag 'drm-for-v4.17' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-10/+0
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 ...
2018-03-31kbuild: get <linux/compiler_types.h> out of <linux/kconfig.h>Masahiro Yamada1-0/+1
Since commit 28128c61e08e ("kconfig.h: Include compiler types to avoid missed struct attributes"), <linux/kconfig.h> pulls in kernel-space headers to unrelated places. Commit 0f9da844d877 ("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>
2018-03-29docs: kernel-doc: fix parsing of arraysMauro Carvalho Chehab1-1/+1
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>
2018-03-28Backmerge tag 'v4.16-rc7' into drm-nextDave Airlie16-33/+47
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.
2018-03-28kbuild: rpm-pkg: Support GNU tar >= 1.29Jason Gunthorpe1-1/+1
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>
2018-03-28builddeb: Fix header package regarding dtc source linksJan Kiszka1-1/+1
Since d5d332d3f7e8, 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>
2018-03-26scripts/checkstack.pl: remove blackfin supportTobias Klauser1-3/+0
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>
2018-03-26recordmcount.pl: drop blackin and tile supportArnd Bergmann1-8/+0
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>
2018-03-26kconfig: use yylineno option instead of manual lineno incrementsMasahiro Yamada2-11/+10
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>
2018-03-26kconfig: detect recursive inclusion earlierMasahiro Yamada1-6/+8
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>
2018-03-26kconfig: remove duplicated file name and lineno of recursive inclusionMasahiro Yamada2-10/+10
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>
2018-03-26kconfig: do not include both curses.h and ncurses.h for nconfigMasahiro Yamada1-3/+1
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 692d97c380c6 ("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>
2018-03-26kconfig: make unmet dependency warnings readableMasahiro Yamada3-55/+23
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>
2018-03-26kconfig: warn unmet direct dependency of tristate symbols selected by yMasahiro Yamada1-2/+2
Commit 246cf9c26bf1 ("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>
2018-03-26kconfig: tests: test if recursive inclusion is detectedMasahiro Yamada6-0/+24
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 5ae6fcc4bb82 ("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>
2018-03-26kconfig: tests: test if recursive dependencies are detectedMasahiro Yamada3-0/+101
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>
2018-03-26kconfig: tests: test randconfig for choice in choiceMasahiro Yamada5-0/+60
Commit 3b9a19e08960 ("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>
2018-03-26kconfig: tests: test defconfig when two choices interactMasahiro Yamada4-0/+42
Commit fbe98bb9ed3d ("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 fbe98bb9ed3d, $ 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>
2018-03-26kconfig: tests: check visibility of tristate choice values in y choiceMasahiro Yamada5-0/+43
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 fa64e5f6a35e ("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 fa64e5f6a35e, this line was written to the .config file. With commit cb67ab2cd2b8 ("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>
2018-03-26kconfig: tests: check unneeded "is not set" with unmet dependencyMasahiro Yamada4-0/+39
Commit cb67ab2cd2b8 ("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>
2018-03-26kconfig: tests: test if new symbols in choice are askedMasahiro Yamada4-0/+64
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 5d09598d488f ("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>
2018-03-26kconfig: tests: test automatic submenu creationMasahiro Yamada3-0/+72
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>
2018-03-26kconfig: tests: add basic choice testsMasahiro Yamada9-0/+149
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>
2018-03-26kconfig: tests: add framework for Kconfig unit testingMasahiro Yamada3-0/+306
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>
2018-03-26kconfig: remove redundant streamline_config.pl prerequisiteUlf Magnusson1-4/+4
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>
2018-03-26kconfig: rename silentoldconfig to syncconfigMasahiro Yamada2-13/+20
As commit cedd55d49dee ("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>
2018-03-26kconfig: invoke oldconfig instead of silentoldconfig from local*configMasahiro Yamada1-2/+2
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>
2018-03-26kconfig: hide irrelevant sub-menus for oldconfigMasahiro Yamada1-3/+6
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 cd9140e1e73a ("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 204c96f60904 ("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 4062f1a4c030 ("kconfig: use long options in conf") made oldconfig as loud as [0] due to misconversion. [4] Commit 14828349719a ("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>
2018-03-26kconfig: remove redundant input_mode test for check_conf() loopMasahiro Yamada1-1/+1
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>
2018-03-26kconfig: remove unneeded input_mode test in conf()Masahiro Yamada1-3/+1
conf() is never called for listnewconfig / olddefconfig. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: do not call check_conf() for olddefconfigMasahiro Yamada1-5/+5
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>
2018-03-26kconfig: only write '# CONFIG_FOO is not set' for visible symbolsUlf Magnusson1-1/+2
=== 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>
2018-03-26kconfig: Print reverse dependencies in groupsEugeniu Rosca3-13/+20
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 1ccb27143360 ("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 617aebe6a97e ("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>
2018-03-26kconfig: clean-up reverse dependency help implementationMasahiro Yamada2-17/+23
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 1ccb27143360 ("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>
2018-03-26checkpatch: kconfig: prefer 'help' over '---help---'Ulf Magnusson1-1/+5
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 c2264564df3d ("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>
2018-03-26checkpatch: kconfig: check help texts for menuconfig and choiceUlf Magnusson1-2/+11
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>
2018-03-26checkpatch: kconfig: recognize more prompts when checking help textsUlf Magnusson1-1/+1
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>
2018-03-26kbuild: clean up link rule of composite modulesMasahiro Yamada1-3/+1
cmd_link_multi-link is used only for cmd_link_multi-m. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: clean up archive rule of built-in.aMasahiro Yamada1-9/+4
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>
2018-03-26kbuild: remove partial section mismatch detection for built-in.aMasahiro Yamada1-2/+1
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>
2018-03-26kbuild: link $(real-obj-y) instead of $(obj-y) into built-in.aMasahiro Yamada2-18/+10
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>
2018-03-26kbuild: rename real-objs-y/m to real-obj-y/mMasahiro Yamada2-16/+16
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>
2018-03-26kbuild: move modname and modname-multi close to modname_flagsMasahiro Yamada2-8/+8
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>
2018-03-26kbuild: simplify modname calculationMasahiro Yamada2-18/+1
modname can be calculated much more simply. If modname-multi is empty, it is a single-used object. So, modname = $(basetarget). Otherwise, modname = $(modname-multi). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
2018-03-26kbuild: fix modname for composite modulesCao jin1-2/+2
Commit cf4f21938e13 ("kbuild: Allow to specify composite modules with modname-m") added modname-m support, but missed to update the corresponding multi-objs-m & modname-multi definition. Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: define KBUILD_MODNAME even if multiple modules share objectsMasahiro Yamada1-7/+5
Currently, KBUILD_MODNAME is defined only when $(modname) contains just one word. If an object is shared among multiple modules, undefined KBUILD_MODNAME could cause a build error. For example, if CONFIG_DYNAMIC_DEBUG is enabled, any call of printk() populates .modname, then fails to build due to undefined KBUILD_MODNAME. Take the following code as an example: obj-m += foo.o obj-m += bar.o foo-objs := foo-bar-common.o foo-only.o bar-objs := foo-bar-common.o bar-only.o In this case, there is room for argument what to define for KBUILD_MODNAME when foo-bar-common.o is being compiled. "foo", "bar", or what else? One idea is to define colon-separated modules that share the object, in this case, "bar:foo" (modules are sorted alphabetically by $(sort ...)). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 00:42:39 +0000