Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. May 20, 2019
  3. May 07, 2019
    • Alexey Gladkov's avatar
      moduleparam: Save information about built-in modules in separate file · 898490c0
      Alexey Gladkov authored 
      
Problem:

When a kernel module is compiled as a separate module, some important
information about the kernel module is available via .modinfo section of
the module.  In contrast, when the kernel module is compiled into the
kernel, that information is not available.

Information about built-in modules is necessary in the following cases:

1. When it is necessary to find out what additional parameters can be
passed to the kernel at boot time.

2. When you need to know which module names and their aliases are in
the kernel. This is very useful for creating an initrd image.

Proposal:

The proposed patch does not remove .modinfo section with module
information from the vmlinux at the build time and saves it into a
separate file after kernel linking. So, the kernel does not increase in
size and no additional information remains in it. Information is stored
in the same format as in the separate modules (null-terminated string
array). Because the .modinfo section is already exported with a separate
modules, we are not creating a new API.

It can be easily read in the userspace:

$ tr '\0' '\n' < modules.builtin.modinfo
ext4.softdep=pre: crc32c
ext4.license=GPL
ext4.description=Fourth Extended Filesystem
ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
ext4.alias=fs-ext4
ext4.alias=ext3
ext4.alias=fs-ext3
ext4.alias=ext2
ext4.alias=fs-ext2
md_mod.alias=block-major-9-*
md_mod.alias=md
md_mod.description=MD RAID framework
md_mod.license=GPL
md_mod.parmtype=create_on_open:bool
md_mod.parmtype=start_dirty_degraded:int
...

Co-Developed-by: default avatarGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: default avatarGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: default avatarAlexey Gladkov <gladkov.alexey@gmail.com>
Acked-by: default avatarJessica Yu <jeyu@kernel.org>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      898490c0
  5. Mar 17, 2019
  7. Mar 04, 2019
    • Masahiro Yamada's avatar
      kbuild: remove cc-version macro · d3a918c6
      Masahiro Yamada authored 
      
There is no more direct user of this macro; it is only used by
cc-ifversion.

Calling this macro is not efficient since it invokes the compiler to
get the compiler version. CONFIG_GCC_VERSION is already calculated in
the Kconfig stage, so Makefile can reuse it.

Here is a note about the slight difference between cc-version and
CONFIG_GCC_VERSION:

When using Clang, cc-version is evaluated to '0402' because Clang
defines __GNUC__ and __GNUC__MINOR__, and looks like GCC 4.2 in the
version point of view. On the other hand, CONFIG_GCC_VERSION=0
when $(CC) is clang.

There are currently two users of cc-ifversion:
  arch/mips/loongson64/Platform
  arch/powerpc/Makefile

They are not affected by this change.

The format of cc-version is <major><minor>, while CONFIG_GCC_VERSION
<major><minor><patch>. I adjusted cc-ifversion for the difference of
the number of digits.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d3a918c6
  9. Feb 20, 2019
    • Masahiro Yamada's avatar
      kbuild: turn '/' into an alias of './' · 6d3c94e4
      Masahiro Yamada authored 
      
Commit 06300b21 ("kbuild: support building individual files for
external modules") introduced the '/' target. It works only for
external modules to build all .o files, but skip the modpost stage.

However, 'make /' looks a bit weird to me. 'make ./' is more sensible
if you want to build all objects under the current directory, and it
works as expected.

Let's change '/' into a phony target that is an alias of './', but
I may feel like deprecating it in the future.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6d3c94e4
  11. Jan 28, 2019
  13. Jan 06, 2019
  15. Dec 01, 2018
    • Masahiro Yamada's avatar
      kbuild: announce removal of SUBDIRS if used · 0126be38
      Masahiro Yamada authored 
      
SUBDIRS has been kept as a backward compatibility since
commit ("[PATCH] kbuild: external module support") in 2002.

We do not need multiple ways to do the same thing, so I will remove
SUBDIRS after the Linux 5.3 release. I cleaned up in-tree code, and
updated the document so that nobody would try to use it.

Meanwhile, display the following warning if SUBDIRS is used.

Makefile:189: ================= WARNING ================
Makefile:190: 'SUBDIRS' will be removed after Linux 5.3
Makefile:191: Please use 'M=' or 'KBUILD_EXTMOD' instead
Makefile:192: ==========================================

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> # for scx200_docflash.c
Acked-by: Guenter Roeck <linux@roeck-us.net> # for scx200_wdt.c
      0126be38
  17. Nov 01, 2018
  19. Sep 09, 2018
    • Henrik Austad's avatar
      Drop all 00-INDEX files from Documentation/ · a7ddcea5
      Henrik Austad authored 
      
This is a respin with a wider audience (all that get_maintainer returned)
and I know this spams a *lot* of people. Not sure what would be the correct
way, so my apologies for ruining your inbox.

The 00-INDEX files are supposed to give a summary of all files present
in a directory, but these files are horribly out of date and their
usefulness is brought into question. Often a simple "ls" would reveal
the same information as the filenames are generally quite descriptive as
a short introduction to what the file covers (it should not surprise
anyone what Documentation/sched/sched-design-CFS.txt covers)

A few years back it was mentioned that these files were no longer really
needed, and they have since then grown further out of date, so perhaps
it is time to just throw them out.

A short status yields the following _outdated_ 00-INDEX files, first
counter is files listed in 00-INDEX but missing in the directory, last
is files present but not listed in 00-INDEX.

List of outdated 00-INDEX:
Documentation: (4/10)
Documentation/sysctl: (0/1)
Documentation/timers: (1/0)
Documentation/blockdev: (3/1)
Documentation/w1/slaves: (0/1)
Documentation/locking: (0/1)
Documentation/devicetree: (0/5)
Documentation/power: (1/1)
Documentation/powerpc: (0/5)
Documentation/arm: (1/0)
Documentation/x86: (0/9)
Documentation/x86/x86_64: (1/1)
Documentation/scsi: (4/4)
Documentation/filesystems: (2/9)
Documentation/filesystems/nfs: (0/2)
Documentation/cgroup-v1: (0/2)
Documentation/kbuild: (0/4)
Documentation/spi: (1/0)
Documentation/virtual/kvm: (1/0)
Documentation/scheduler: (0/2)
Documentation/fb: (0/1)
Documentation/block: (0/1)
Documentation/networking: (6/37)
Documentation/vm: (1/3)

Then there are 364 subdirectories in Documentation/ with several files that
are missing 00-INDEX alltogether (and another 120 with a single file and no
00-INDEX).

I don't really have an opinion to whether or not we /should/ have 00-INDEX,
but the above 00-INDEX should either be removed or be kept up to date. If
we should keep the files, I can try to keep them updated, but I rather not
if we just want to delete them anyway.

As a starting point, remove all index-files and references to 00-INDEX and
see where the discussion is going.

Signed-off-by: default avatarHenrik Austad <henrik@austad.us>
Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Just-do-it-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
Acked-by: default avatarPaul Moore <paul@paul-moore.com>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: default avatarMark Brown <broonie@kernel.org>
Acked-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
Cc: [Almost everybody else]
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      a7ddcea5
  21. Aug 22, 2018
    • Michal Suchanek's avatar
      kbuild: Fix LOADLIBES rename in Documentation/kbuild/makefiles.txt · c86b1f93
      Michal Suchanek authored 
      
Fixes: 8377bd2b ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS")
Signed-off-by: default avatarMichal Suchanek <msuchanek@suse.de>
Acked-by: default avatarLaura Abbott <labbott@redhat.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c86b1f93
    • Masahiro Yamada's avatar
      kconfig: report recursive dependency involving 'imply' · 5e8c5299
      Masahiro Yamada authored 
      
Currently, Kconfig does not complain about the recursive dependency
where 'imply' keywords are involved.

[Test Code]

  config A
          bool "a"

  config B
          bool "b"
          imply A
          depends on A

In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency.  For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  #
  # configuration written to .config
  #
  $ cat .config
  #
  # Automatically generated file; DO NOT EDIT.
  # Main menu
  #
  CONFIG_A=y
  $ make syncconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  *
  * Restart config...
  *
  *
  * Main menu
  *
  a (A) [Y/n/?] y
    b (B) [N/y/?] (NEW)

To detect this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .

At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency has been hit.  This will be solved
by the next commit.

In fact, even the document and the unit-test are confused.  Using
'imply' does not solve recursive dependency since 'imply' addresses
the unmet direct dependency, which 'select' could cause.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: default avatarDirk Gouders <dirk@gouders.net>
      5e8c5299
  23. Jul 25, 2018
  25. Jul 20, 2018
    • Dirk Gouders's avatar
      kbuild: if_changed: document single use per target limitation · bb81955f
      Dirk Gouders authored 
      
Users of if_changed could easily feel invited to use it to divide a
recipe into parts like:

a: prereq FORCE
	$(call if_changed,do_a)
	$(call if_changed,do_b)

But this is problematic, because if_changed should not be used more
than once per target: in the above example, if_changed stores the
command-line of the given command in .a.cmd and when a is up-to-date
with respect to prereq, the file .a.cmd contains the command-line for
the last command executed, i.e. do_b.

When the recipe is then executed again, without any change of
prerequisites, the command-line check for do_a will fail, do_a will be
executed and stored in .a.cmd.  The next check, however, will still see
the old content (the file isn't re-read) and if_changed will skip
do_b, because the command-line test will not recognize a change.  On
the next execution of the recipe the roles will flip: do_a is OK but
do_b not and it will be executed.  And so on...

Signed-off-by: default avatarDirk Gouders <dirk@gouders.net>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bb81955f
  27. Jul 17, 2018
  29. Jul 06, 2018
  31. Jun 25, 2018
  33. Jun 14, 2018
    • Linus Torvalds's avatar
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds authored 
      
The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_NONE is not set
  # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one.  This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_STACKPROTECTOR=y
  CONFIG_STACKPROTECTOR_STRONG=y
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  35. Jun 11, 2018
  37. May 28, 2018
    • Masahiro Yamada's avatar
      Documentation: kconfig: document a new Kconfig macro language · 316d55d5
      Masahiro Yamada authored 
      Add a document for the macro language introduced to Kconfig.

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.  By moving the
compiler capability tests to Kconfig, features unsupported by the
compiler will be hidden automatically.

This change was strongly prompted by Linus Torvalds.  You can find
his suggestions [1] [2] in ML.  The original idea was to add a new
attribute with 'option shell=...', but I found more generalized text
expansion would make Kconfig more powerful and lovely.  The basic
ideas are from Make, but there are some differences.

[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527



Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
Reviewed-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      316d55d5
    • Masahiro Yamada's avatar
      kconfig: reference environment variables directly and remove 'option env=' · 104daea1
      Masahiro Yamada authored 
      
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
          string
          default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      104daea1
  39. Mar 25, 2018
    • Masahiro Yamada's avatar
      kconfig: rename silentoldconfig to syncconfig · 911a91c3
      Masahiro Yamada authored 
      
As commit cedd55d4 ("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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      911a91c3
    • Masahiro Yamada's avatar
      kbuild: remove internally used LDFLAGS_vmlinux from kbuild.txt · bd0f98eb
      Masahiro Yamada authored 
      
Documentation/kbuild/makefiles.txt lists variables used in Makefile
whereas Documentation/kbuild/kbuild.txt describes user assignable
parameters given via environments or the command line.

The top Makefile and arch/*/Makefile accumulate proper linker flags to
LDFLAGS_vmlinux.  So, users can not override it from the command line.
Generally, per-file options are not supposed to be user-assignable.
Remove the misleading entry from kbuild.txt.

If we need a way to append user-specific flags for linking the kernel,
LDFLAGS_KERNEL would be a consistent choice because we already expose
LDFLAGS_MODULE counter-part to users.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bd0f98eb
    • Masahiro Yamada's avatar
      kbuild: remove command line interface LDFLAGS_MODULE from makefiles.txt · 35cd02be
      Masahiro Yamada authored 
      
Documentation/kbuild/makefiles.txt lists variables used in Makefile
whereas Documentation/kbuild/kbuild.txt describes user assignable
parameters given via environments or the command line.

LDFLAGS_MODULE is a command line interface, so it should be dropped
from makefiles.txt.

Some lines below in this file, it is clearly explained that
KBUILD_LDFLAGS_MODULE is the right one for the internal use:

    KBUILD_LDFLAGS_MODULE   Options for $(LD) when linking modules

        $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
        used when linking modules. This is often a linker script.
        From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).

Then, kbuild.txt explains LDFLAGS_MODULE, like follows:

    LDFLAGS_MODULE
    --------------------------------------------------
    Additional options used for $(LD) when linking modules.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      35cd02be
    • Nicholas Piggin's avatar
      kbuild: rename built-in.o to built-in.a · f49821ee
      Nicholas Piggin authored 
      
Incremental linking is gone, so rename built-in.o to built-in.a, which
is the usual extension for archive files.

This patch does two things, first is a simple search/replace:

git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g'

The second is to invert nesting of nested text manipulations to avoid
filtering built-in.a out from libs-y2:

-libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y)))
+libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))

Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f49821ee
    • Nicholas Piggin's avatar
      kbuild: remove incremental linking option · 6358d6e8
      Nicholas Piggin authored 
      
This removes the old `ld -r` incremental link option, which has not
been selected by any architecture since June 2017.

Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6358d6e8
  41. Jan 05, 2018
    • Nicolas Pitre's avatar
      kconfig: fix relational operators for bool and tristate symbols · 9059a349
      Nicolas Pitre authored 
      
Since commit 31847b67 ("kconfig: allow use of relations other than
(in)equality") it is possible to use relational operators in Kconfig
statements. However, those operators give unexpected results when
applied to bool/tristate values:

	(n < y) = y (correct)
	(m < y) = y (correct)
	(n < m) = n (wrong)

This happens because relational operators process bool and tristate
symbols as strings and m sorts before n. It makes little sense to do a
lexicographical compare on bool and tristate values though.

Documentation/kbuild/kconfig-language.txt states that expression can have
a value of 'n', 'm' or 'y' (or 0, 1, 2 respectively for calculations).
Let's make it so for relational comparisons with bool/tristate
expressions as well and document them. If at least one symbol is an
actual string then the lexicographical compare works just as before.

Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9059a349
  43. Dec 11, 2017
  45. Nov 08, 2017
  47. Oct 24, 2017
  49. Aug 07, 2017
  51. Jun 30, 2017
    • Nicholas Piggin's avatar
      kbuild: handle libs-y archives separately from built-in.o archives · 3a166fc2
      Nicholas Piggin authored 
      
The thin archives build currently puts all lib.a and built-in.o
files together and links them with --whole-archive.

This works because thin archives can recursively refer to thin
archives. However some architectures include libgcc.a, which may
not be a thin archive, or it may not be constructed with the "P"
option, in which case its contents do not get linked correctly.

So don't pull .a libs into the root built-in.o archive. These
libs should already have symbol tables and indexes built, so they
can be direct linker inputs. Move them out of the --whole-archive
option, which restore the conditional linking behaviour of lib.a
to thin archives builds.

Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3a166fc2
  53. Jun 25, 2017
  55. Jun 21, 2017
    • Masahiro Yamada's avatar
      kbuild: replace genhdr-y with generated-y · ae3f4151
      Masahiro Yamada authored 
      
Originally, generated-y and genhdr-y had different meaning, like
follows:

- generated-y: generated headers (other than asm-generic wrappers)
- header-y   : headers to be exported
- genhdr-y   : generated headers to be exported (generated-y + header-y)

Since commit fcc8487d ("uapi: export all headers under uapi
directories"), headers under UAPI directories are all exported.
So, there is no more difference between generated-y and genhdr-y.

We see two users of genhdr-y, arch/{arm,x86}/include/uapi/asm/Kbuild.
They generate some headers in arch/{arm,x86}/include/generated/uapi/asm
directories, which are obviously exported.

Replace them with generated-y, and abolish genhdr-y.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      ae3f4151