Now Kbuild provides reasonable defaults for objtool, sanitizers, and
profilers.

Remove redundant variables.

Note:

This commit changes the coverage for some objects:

  - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV
  - include arch/sparc/vdso/vdso-image-*.o into UBSAN
  - include arch/sparc/vdso/vma.o into UBSAN
  - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
  - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
  - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
  - include arch/x86/entry/vdso/vma.o into GCOV, KCOV
  - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV

I believe these are positive effects because all of them are kernel
space objects.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>

The objtool, sanitizers (KASAN, UBSAN, etc.), and profilers (GCOV, etc.)
are intended only for kernel space objects.

For instance, the following are not kernel objects, and therefore should
opt out of coverage:

  - vDSO
  - purgatory
  - bootloader (arch/*/boot/)

However, to exclude these from coverage, you need to explicitly set
OBJECT_FILES_NON_STNDARD=y, KASAN_SANITIZE=n, etc.

Kbuild can achieve this without relying on such variables because
objects not directly linked to vmlinux or modules are considered
"non-standard objects".

Detecting standard objects is straightforward:

  - objects added to obj-y or lib-y are linked to vmlinux
  - objects added to obj-m are linked to modules

There are some exceptional Makefiles (e.g., arch/s390/boot/Makefile,
arch/xtensa/boot/lib/Makefile) that use obj-y or lib-y for non-kernel
space objects, but they can be fixed later if necessary.

Going forward, objects that are not listed in obj-y, lib-y, or obj-m
will opt out of objtool, sanitizers, and profilers by default.

You can still override the Kbuild decision by explicitly specifying
OBJECT_FILES_NON_STANDARD, KASAN_SANITIZE, etc. but most of such Make
variables can be removed.

The next commit will clean up redundant variables.

Note:

This commit changes the coverage for some objects:

  - exclude .vmlinux.export.o from UBSAN, KCOV
  - exclude arch/csky/kernel/vdso/vgettimeofday.o from UBSAN
  - exclude arch/parisc/kernel/vdso32/vdso32.so from UBSAN
  - exclude arch/parisc/kernel/vdso64/vdso64.so from UBSAN
  - exclude arch/x86/um/vdso/um_vdso.o from UBSAN
  - exclude drivers/misc/lkdtm/rodata.o from UBSAN, KCOV
  - exclude init/version-timestamp.o from UBSAN, KCOV
  - exclude lib/test_fortify/*.o from all santizers and profilers

I believe these are positive effects.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>

Commit ddb5cdba ("kbuild: generate KSYMTAB entries by modpost")
forget drop the .export_symbol section from the final modules.

Fixes: ddb5cdba ("kbuild: generate KSYMTAB entries by modpost")
Signed-off-by: Wang Yao <wangyao@lemote.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Choices and their members are associated via the P_CHOICE property.

Currently, sym_get_choice_prop() and expr_list_for_each_sym() are
used to iterate on choice members.

Replace them with menu_for_each_sub_entry(), which achieves the same
without relying on P_CHOICE.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the choice of the given choice member.

Replace it with sym_get_choice_menu(), which retrieves the choice
without relying on P_CHOICE.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the choice of the given choice member.

We can do this without relying on P_CHOICE by checking the parent in
the menu structure.

Introduce a new helper to retrieve the choice if the given symbol is a
choice member.

This is intended to replace prop_get_symbol(sym_get_choice_prop()) and
deprecate P_CHOICE eventually.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard errors.

While I was here, I moved the checks to slim down menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Choice members must have a prompt; hence make it an error.

While I was here, I moved the check to the parser to slim down
_menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The return value of conf_choice() is not used.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Following the approach employed in commit bedf9236 ("kconfig: use
linked list in get_symbol_str() to iterate over menus"), simplify the
iteration on the menus of the specified symbol.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

SYMBOL_CHANGED and MENU_CHANGED are used to update GUI frontends
when the symbol value is changed. These are used inconsistently:
SYMBOL_CHANGED in gconf.c and MENU_CHANGE in qconf.cc.

MENU_CHANGED works more properly when a symbol has multiple prompts
(although such code is not ideal).

[test code]

    config FOO
            bool "foo prompt 1"

    config FOO
            bool "foo prompt 2"

In gconfig, if one of the two checkboxes is clicked, only the first
one is toggled. In xconfig, the two checkboxes work in sync.

Replace SYMBOL_CHANGED in gconf.c with MENU_CHANGED to align with
the xconfig behavior.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This is not so useful. If necessary, you can insert printf() or
whatever during debugging.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Every time a config file is loaded (either by clicking the "Load" button
or selecting "File" -> "Load" from the menu), a new list is appended to
the pane.

The current tree needs to be cleared by calling gtk_tree_store_clear().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Use the KBUILD_IMAGE variable to determine the right kernel image to
install and install compressed images to /boot/vmlinuz-$version like the
'make install' target already does.
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

With commit 4b0bf9a0 ("riscv: compat_vdso: install compat_vdso.so.dbg
to /lib/modules/*/vdso/") applied, all debug VDSO files are installed in
$(MODLIB)/vdso/.

Simplify the installation rule.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, Kbuild produces inconsistent results in some cases.

You can do an interesting experiment using the --shuffle option, which
is supported by GNU Make 4.4 or later.

Set CONFIG_KVM_INTEL=y and CONFIG_KVM_AMD=m (or vice versa), and repeat
incremental builds w/wo --shuffle=reverse.

  $ make
    [ snip ]
    CC      arch/x86/kvm/kvm-asm-offsets.s

  $ make --shuffle=reverse
    [ snip ]
    CC [M]  arch/x86/kvm/kvm-asm-offsets.s

  $ make
    [ snip ]
    CC      arch/x86/kvm/kvm-asm-offsets.s

arch/x86/kvm/kvm-asm-offsets.s is rebuilt every time w/wo the [M] marker.

arch/x86/kvm/kvm-asm-offsets.s is built as built-in when it is built as
a prerequisite of arch/x86/kvm/kvm-intel.o, which is built-in.

arch/x86/kvm/kvm-asm-offsets.s is built as modular when it is built as
a prerequisite of arch/x86/kvm/kvm-amd.o, which is a module.

Another odd example is single target builds.

When CONFIG_LKDTM=m, drivers/misc/lkdtm/rodata.o can be built as
built-in or modular, depending on how it is built.

  $ make drivers/misc/lkdtm/lkdtm.o
    [ snip ]
    CC [M]  drivers/misc/lkdtm/rodata.o

  $ make drivers/misc/lkdtm/rodata.o
    [ snip ]
    CC      drivers/misc/lkdtm/rodata.o

drivers/misc/lkdtm/rodata.o is built as modular when it is built as a
prerequisite of another, but built as built-in when it is a final
target.

The same thing happens to drivers/memory/emif-asm-offsets.s when
CONFIG_TI_EMIF_SRAM=m.

  $ make drivers/memory/ti-emif-sram.o
    [ snip ]
    CC [M]  drivers/memory/emif-asm-offsets.s

  $ make drivers/memory/emif-asm-offsets.s
    [ snip ]
    CC      drivers/memory/emif-asm-offsets.s

This is because the part-of-module=y flag defined for the modules is
inherited by its prerequisites.

Target-specific variables are likely intended only for local use.
This commit adds 'private' to them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

The $(wildcard ) is called in quiet_cmd_rmfiles.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:

    src := $(obj)

When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.

This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.

To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.

Going forward, the variables used in Makefiles will have the following
meanings:

  $(obj)     - directory in the object tree
  $(src)     - directory in the source tree  (changed by this commit)
  $(objtree) - the top of the kernel object tree
  $(srctree) - the top of the kernel source tree

Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:

  src := $(obj)

Before changing the semantics of $(src) in the next commit, this commit
replaces $(obj)/ with $(src)/ in pattern rules where the prerequisite
might be a generated file.

C, assembly, Rust, and DTS files are sometimes generated by tools, so
they could be either generated files or real sources. The $(obj)/ prefix
works for both cases with the help of VPATH.

As mentioned above, $(obj) and $(src) are the same at this point, hence
this commit has no functional change.

I did not modify scripts/Makefile.userprogs because there is no use
case where userspace C files are generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

scripts/Makefile.lib is included not only from scripts/Makefile.build
but also from scripts/Makefile.{vmlinux,modfinal} for building generated
C files.

In scripts/Makefile.{vmlinux,modfinal}, $(obj) and $(src) are empty.

Therefore, the header include paths:

    -I $(srctree)/$(src) -I $(objtree)/$(obj)

... become meaningless code:

    -I $(srctree)/ -I $(objtree)/

Add these paths only when 'obj' and 'src' are defined.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202404170634.BlqTaYA0-lkp@intel.com/Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

These are generated files. Prefix them with $(obj)/ instead of $(src)/.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

This flag is set to symbols that are not intended to be written
to the .config file.

Since commit b75b0a81 ("kconfig: change defconfig_list option to
environment variable"), SYMBOL_NO_WRITE is only set to choices.

Therefore, (sym->flags & SYMBOL_NO_WRITE) is equivalent to
sym_is_choice(sym). This flag is no longer necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

There is an issue in clang's ThinLTO caching (enabled for the kernel via
'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
to include data within the kernel, such as the .config file for
/proc/config.gz. For example, when changing the .config and rebuilding
vmlinux, the copy of .config in vmlinux does not match the copy of
.config in the build folder:

  $ echo 'CONFIG_LTO_NONE=n
  CONFIG_LTO_CLANG_THIN=y
  CONFIG_IKCONFIG=y
  CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config

  $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
  ...

  $ grep CONFIG_HEADERS_INSTALL .config
  CONFIG_HEADERS_INSTALL=y

  $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
  CONFIG_HEADERS_INSTALL=y

  $ scripts/config -d HEADERS_INSTALL

  $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
  ...
    UPD     kernel/config_data
    GZIP    kernel/config_data.gz
    CC      kernel/configs.o
  ...
    LD      vmlinux
  ...

  $ grep CONFIG_HEADERS_INSTALL .config
  # CONFIG_HEADERS_INSTALL is not set

  $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
  CONFIG_HEADERS_INSTALL=y

Without '--thinlto-cache-dir' or when using full LTO, this issue does
not occur.

Benchmarking incremental builds on a few different machines with and
without the cache shows a 20% increase in incremental build time without
the cache when measured by touching init/main.c and running 'make all'.

ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:

  Benchmark 1: With ThinLTO cache
    Time (mean ± σ):     56.347 s ±  0.163 s    [User: 83.768 s, System: 24.661 s]
    Range (min … max):   56.109 s … 56.594 s    10 runs

  Benchmark 2: Without ThinLTO cache
    Time (mean ± σ):     67.740 s ±  0.479 s    [User: 718.458 s, System: 31.797 s]
    Range (min … max):   67.059 s … 68.556 s    10 runs

  Summary
    With ThinLTO cache ran
      1.20 ± 0.01 times faster than Without ThinLTO cache

ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:

  Benchmark 1: With ThinLTO cache
    Time (mean ± σ):     85.772 s ±  0.252 s    [User: 91.505 s, System: 8.408 s]
    Range (min … max):   85.447 s … 86.244 s    10 runs

  Benchmark 2: Without ThinLTO cache
    Time (mean ± σ):     103.833 s ±  0.288 s    [User: 232.058 s, System: 8.569 s]
    Range (min … max):   103.286 s … 104.124 s    10 runs

  Summary
    With ThinLTO cache ran
      1.21 ± 0.00 times faster than Without ThinLTO cache

While it is unfortunate to take this performance improvement off the
table, correctness is more important. If/when this is fixed in LLVM, it
can potentially be brought back in a conditional manner. Alternatively,
a developer can just disable LTO if doing incremental compiles quickly
is important, as a full compile cycle can still take over a minute even
with the cache and it is unlikely that LTO will result in functional
differences for a kernel change.

Cc: stable@vger.kernel.org
Fixes: dc5723b0 ("kbuild: add support for Clang LTO")
Reported-by: Yifan Hong <elsk@google.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2021Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.

In the following example, both A and B can be disabled simultaneously:

    choice
            prompt "choose A, B, or nothing"
            optional

    config A
            bool "A"

    config B
            bool "B"

    endchoice

You can achieve the equivalent outcome by other means.

A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:

    choice
            prompt "choose A or B"
            depends on ENABLE_A_B_CHOICE

    config A
            bool "A"

    config B
            bool "B"

    endchoice

Another approach is to insert one more entry:

    choice
            prompt "choose A, B, or disable both"

    config A
            bool "A"

    config B
            bool "B"

    config DISABLE_A_AND_B
            bool "choose this to disable both A and B"

    endchoice

Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.

The 'optional' property is even more unnecessary for a tristate choice.

Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:

    choice
            prompt "choose one built-in or make them modular"

    config A
            tristate "A"

    config B
            tristate "B"

    endchoice

In conclusion, the 'optional' property was unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.

This feature is rarely used. In fact, it is only used in arch/sh/Kconfig
because the equivalent outcome can be achieved by inserting one more
entry.

The 'optional' property support will be removed from Kconfig.

This commit replaces the 'optional' property with a dummy option,
CMDLINE_FROM_BOOTLOADER, as seen in some other architectures.

Note:
 The 'default CMDLINE_OVERWRITE' statement does not work as intended
 in combination with 'optional'. If neither CONFIG_CMDLINE_OVERWRITE
 nor CONFIG_CMDLINE_EXTEND is specified in a defconfig file, both of
 them are disabled. This is a bug. To maintain the current behavior,
 I added CONFIG_CMDLINE_FROM_BOOTLOADER=y to those defconfig files.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

All symbols except choices have a name.

Previously, choices were allowed to have a name, but commit c83f0209
("kconfig: remove named choice support") eliminated that possibility.

Now, it is easy to distinguish choices from normal symbols; if the name
is NULL, it is a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Given KBUILD_IMAGE properly set in arch/*/Makefile, the default case
should work in most scenarios. The only oddity is the naming of the
copy destination, vmlinux-kbuild-${KERNELRELEASE}. Let's rename it
to vmlinuz-${KERNELRELEASE} because the kernel is often compressed.
Remove the warning to avoid unnecessary patch submissions when the
default case suffices.

Remove the x86 case, which is now equivalent to the default.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

All symbols except choices have a name.

child->sym->name never becomes NULL inside choice blocks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations.

The menu_next() function facilitates depth-first traversal:

 1. Descend to the child level if the current menu has one
 2. Move to the next sibling at the same level if available
 3. Ascend to the parent level if there is no more child or sibling

The menu_for_each_sub_entry() macro iterates over all submenu entries
using depth-first traverse.

The menu_for_each_entry() macro is the same, but over all menu entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Weak references are references that are permitted to remain unsatisfied
in the final link. This means they cannot be implemented using place
relative relocations, resulting in GOT entries when using position
independent code generation.

The notes section should always exist, so the weak annotations can be
omitted.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

kallsyms is a directory of all the symbols in the vmlinux binary, and so
creating it is somewhat of a chicken-and-egg problem, as its non-zero
size affects the layout of the binary, and therefore the values of the
symbols.

For this reason, the kernel is linked more than once, and the first pass
does not include any kallsyms data at all. For the linker to accept
this, the symbol declarations describing the kallsyms metadata are
emitted as having weak linkage, so they can remain unsatisfied. During
the subsequent passes, the weak references are satisfied by the kallsyms
metadata that was constructed based on information gathered from the
preceding passes.

Weak references lead to somewhat worse codegen, because taking their
address may need to produce NULL (if the reference was unsatisfied), and
this is not usually supported by RIP or PC relative symbol references.

Given that these references are ultimately always satisfied in the final
link, let's drop the weak annotation, and instead, provide fallback
definitions in the linker script that are only emitted if an unsatisfied
reference exists.

While at it, drop the FRV specific annotation that these symbols reside
in .rodata - FRV is long gone.

Tested-by: Nick Desaulniers <ndesaulniers@google.com> # Boot
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20230504174320.3930345-1-ardb%40kernel.orgSigned-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

scripts/package/buildtar checks some kernel packages, and copies the
first image found. This may potentially produce an inconsistent (and
possibly wrong) package.

For instance, the for-loop for arm64 checks Image.{bz2,gz,lz4,lzma,lzo},
and vmlinuz.efi, then copies the first image found, which might be a
stale image created in a previous build.

When CONFIG_EFI_ZBOOT is enabled in the pristine source tree,
'make ARCH=arm64 tar-pkg' will build and copy vmlinuz.efi. This is the
expected behavior.

If you build the kernel with CONFIG_EFI_ZBOOT disabled, Image.gz will
be created, which will remain in the tree until you run 'make clean'.
Even if CONFIG_EFI_ZBOOT is turned on later, 'make ARCH=arm64 tar-pkg'
will copy stale Image.gz instead of the latest vmlinuz.efi, as Image.gz
takes precedence over vmlinuz.efi.

In summary, the code "[ -f ... ] && cp" does not consistently produce
the desired outcome.

Other packaging targets are deterministic; deb-pkg and rpm-pkg copies
${KBUILD_IMAGE}, which is determined by CONFIG options.

I removed [ -f ... ] checks from x86, alpha, parisc, and the default
because they have a single kernel image to copy. If it is missing, it
should be an error.

I did not modify the code for mips, arm64, riscv. Instead, I left some
comments. Eventually, someone may fix the code, or at the very least,
it may discourage the copy-pasting of incorrect code to another
architecture.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Running dtbs_check and dt_compatible_check targets really only depend
on processed-schema.json, but the dependency is 'dt_binding_check'. That
was sort worked around with the CHECK_DT_BINDING variable in order to
skip some of the work that 'dt_binding_check' does. It still runs the
full checks of the schemas which is not necessary and adds 10s of
seconds to the build time. That's significant when checking only a few
DTBs and with recent changes that have improved the validation time by
6-7x.

Add a new target, dt_binding_schema, which just builds
processed-schema.json and can be used as the dependency for other
targets. The scripts_dtc dependency isn't needed either as the examples
aren't built for it.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Masahiro pointed out the use of if_changed_rule is incorrect and command
line changes are not correctly accounted for.

To fix this, split up the DT binding validation target,
dt_binding_check, into multiple rules for each step: yamllint, schema
validtion with meta-schema, and building the processed schema.

One change in behavior is the yamllint or schema validation will be
re-run again when there are warnings present.
Reported-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/all/20220817152027.16928-1-masahiroy@kernel.org/Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Instead of stripping off the $(srctree) multiple times do it once up
front, but keep the src/obj path as it is going to be needed in
subsequent commit.

Rename the variable to CHK_DT_EXAMPLES to better reflect what it
contains.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Starting with c23, 'constexpr' is a keyword in C like in C++ and cannot
be used as an identifier:

scripts/unifdef.c:206:25: error: 'constexpr' can only be used in variable declarations
  206 | static bool             constexpr;              /* constant #if expression */
      |                         ^
scripts/unifdef.c:880:13: error: expected identifier or '('
  880 |                 constexpr = false;
      |                           ^

Rename this instance to allow changing to C23 at some point in the future.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-By: Tony Finch <dot@dotat.at>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The build rule for C is unused because 'obj-cvdso32' is not defined
in this Makefile.

If you add a C file into arch/parisc/kernel/vdso32/ in the future,
you can revert this commit. The kernel does not keep unused code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>

Pull char / misc driver fixes from Greg KH:
 "Here are some small char/misc and other driver fixes for 6.9-rc5.
  Included in here are the following:

   - binder driver fix for reported problem

   - speakup crash fix

   - mei driver fixes for reported problems

   - comdei driver fix

   - interconnect driver fixes

   - rtsx driver fix

   - peci.h kernel doc fix

  All of these have been in linux-next for over a week with no reported
  problems"

* tag 'char-misc-6.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  peci: linux/peci.h: fix Excess kernel-doc description warning
  binder: check offset alignment in binder_get_object()
  comedi: vmk80xx: fix incomplete endpoint checking
  mei: vsc: Unregister interrupt handler for system suspend
  Revert "mei: vsc: Call wake_up() in the threaded IRQ handler"
  misc: rtsx: Fix rts5264 driver status incorrect when card removed
  mei: me: disable RPL-S on SPS and IGN firmwares
  speakup: Avoid crash on very long word
  interconnect: Don't access req_list while it's being manipulated
  interconnect: qcom: x1e80100: Remove inexistent ACV_PERF BCM