kconfig: make conf_get_autoconfig_name() static

This is only used in confdata.c

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: use snprintf for formatting pathnames

Valid pathnames will never exceed PATH_MAX, but these file names
are unsanitized and can cause buffer overflow if set incorrectly.
Use snprintf to avoid this. This was flagged during a Coverity scan
of the coreboot project, which also uses kconfig for its build system.

Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove useless NULL pointer check in conf_write_dep()

conf_write_dep() has just one caller:

    conf_write_dep("include/config/auto.conf.cmd");

"name" always points to a valid string.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: make parent directories for the saved .config as needed

With menuconfig / nconfig, users can input any file path from the
"Save" menu, but it fails if the parent directory does not exist.

Why not create the parent directory automatically. I think this is
a user-friendly behavior.

I changed the error messages in menuconfig / nconfig.

"Nonexistent directory" is no longer the most likely reason of the
failure. Perhaps, the user specified the existing directory, or
attempted to write to the location without write permission.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: do not write .config if the content is the same

Kconfig updates the .config when it exits even if its content is
exactly the same as before. Since its timestamp becomes newer than
that of other build artifacts, additional processing is invoked,
which is annoying.

- syncconfig is invoked to update include/config/auto.conf, etc.

- kernel/configs.o is recompiled if CONFIG_IKCONFIG is enabled,
  then vmlinux is relinked as well.

If the .config is not changed at all, we do not have to even
touch it. Just bail out showing "No change to .config".

  $ make allmodconfig
  config/conf  --allmodconfig Kconfig
  #
  # configuration written to .config
  #
  $ make allmodconfig
  config/conf  --allmodconfig Kconfig
  #
  # No change to .config
  #

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: do not accept a directory for configuration output

Currently, conf_write() can be called with a directory name instead
of a file name. As far as I see, this can happen for menuconfig,
nconfig, gconfig.

If it is given with a directory path, conf_write() kindly appends
getenv("KCONFIG_CONFIG"), but this ends up with hacky dir/basename
handling, and screwed up in corner-cases like "what if KCONFIG_CONFIG
is an absolute path?" as discussed before:

  https://patchwork.kernel.org/patch/9910037/

Since conf_write() is already messed up, I'd say "do not do it".
Please pass a file path all the time. If a directory path is specified
for the configuration output, conf_write() will simply error out.

Now that the tmp file is created in the same directory as the .config,
the previously reported "what if KCONFIG_CONFIG points to a different
file system?" has been solved.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Nicolas Porcel <nicolasporcel06@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kbuild: move ".config not found!" message from Kconfig to Makefile

If you run "make" in a pristine source tree, currently Kbuild will
start to build Kconfig to let it show the error message.

It would be more straightforward to check it in Makefile and let
it fail immediately.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename zconf.y to parser.y

Use a more logical name.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename zconf.l to lexer.l

Use a more logical name.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170 toolchain: update to gcc 9.2.0

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170 toolchain: update to gcc 9.1.0

gcc will now be warning about conflicting alignments
when a pointer from a packed structure is in play.

the include headers will likely need further fixes, but
we can wait until the linux kernel folks know how they
want to deal with ieee80211.h.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170: fix printf.c file permission

This was set to executable.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170 firmware: config: fix missing lkc_proto.h update

Commit: 2396dc74a1e0 ("kconfig: allow all config targets to write auto.conf if missing")
included a hunk for lkc_proto.h that was dropped.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170: config: re-add config.cmake

This patch re-adds the custom config.cmake support that was
removed by the cleanup patch.

Reported-by: Jason Self <j@jxself.org>
Fixes: 786134321b6e ("carl9170: config: fix patching errors and update CMakeFiles")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170 toolchain: update to gcc 8.3.0

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove unused "file" field of yylval union

This has never been used.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: split the lexer out of zconf.y

Compile zconf.lex.c independently of the other files.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

carl9170: config: fix patching errors and update CMakeFiles

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: split some C files out of zconf.y

I want to compile each C file independently instead of including all
of them from zconf.y.

Split out confdata.c, expr.c, symbol.c, and preprocess.c .
These are low-hanging fruits.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: convert to SPDX License Identifier

All files in lxdialog/ are licensed under GPL-2.0+, and the rest are
under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/.

Documentation/process/license-rules.rst does not suggest anything
about the flex/bison files. Because flex does not accept the C++
comment style at the very top of a file, I used the C style for
zconf.l, and so for zconf.y for consistency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove keyword lookup table entirely

Commit 7a88488bbc23 ("[PATCH] kconfig: use gperf for kconfig keywords")
introduced gperf for the keyword lookup.

Then, commit bb3290d91695 ("Remove gperf usage from toolchain") killed
the gperf use. As a result, the linear keyword search was left behind.

If we do not use gperf, there is no reason to have the separate table
of the keywords. Move all keywords back to the lexer.

I also refactored the lexer to remove the COMMAND and PARAM states.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: update current_pos in the second lexer

To simplify the generated lexer, let the hand-made lexer update the
file name and line number for the parser.

I tested this with DEBUG_PARSE, and confirmed the same file names
and line numbers were dumped.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: switch to ASSIGN_VAL state in the second lexer

To simplify the generated lexer, switch to the ASSIGN_VAL state in
the hand-made lexer.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: stop associating kconf_id with yylval

The lexer has conventionally associated kconf_id data with yylval
to carry additional information to the parser.

No token is relying on this any more.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: refactor end token rules

T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id
associated with yylval. Refactor them to not use it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: stop supporting '.' and '/' in unquoted words

In my understanding, special characters such as '.' and '/' are
supported in unquoted words to use bare file paths in the "source"
statement.

With the previous commit surrounding all file paths with double
quotes, we can drop this.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: use T_WORD instead of T_VARIABLE for variables

There is no grammatical ambiguity by using T_WORD for variables.
The parser can distinguish variables from symbols from the context.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: use specific tokens instead of T_ASSIGN for assignments

Currently, the lexer returns T_ASSIGN for all of =, :=, and +=
associating yylval with the flavor.

I want to make the generated lexer as simple as possible. So, the
lexer should convert keywords to tokens without thinking about the
meaning.

   =  ->  T_EQUAL
  :=  ->  T_COLON_EQUAL
  +=  ->  T_PLUS_EQUAL

Unfortunately, Kconfig uses = instead of == for the equal operator.
So, the same token T_EQUAL is used for assignment and comparison.
The parser can still distinguish them from the context.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: refactor scanning and parsing "option" properties

For the keywords "modules", "defconfig_list", and "allnoconfig_y",
the lexer should pass specific tokens instead of generic T_WORD.

This simplifies both the lexer and the parser.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: use distinct tokens for type and default properties

This commit removes kconf_id::stype to prepare for the entire
removal of kconf_id.c

To simplify the lexer, I want keywords straight-mapped to tokens.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove redundant token defines

These are already defined as %left.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename depends_list to comment_option_list

Now the comment_stmt is the only user of depends_list. Rename it to
comment_option_list

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: loosen the order of "visible" and "depends on" in menu entry

Currently, "visible" and "depends on", if defined in a menu entry,
must appear in that order.

The real example is in drivers/media/tuners/Kconfig:

  menu "Customize TV tuners"
          visible if <expr1>
          depends on <expr2>

... is fine, but you cannot change the property order like this:

  menu "Customize TV tuners"
          depends on <expr2>
          visible if <expr1>

Kconfig does not require a specific order of properties. In this case,
menu_add_visibility(() and menu_add_dep() are orthogonal.

Loosen this unreasonable restriction.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove redundant menu_block rule

The code block surrounded by "menu" ... "endmenu" is stmt_list.

Remove the redundant menu_block symbol entirely.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove redundant if_block rule

The code block surrounded by "if" ... "endif" is stmt_list.

Remove the redundant if_block symbol entirely.

Remove "stmt_list: stmt_list end" rule as well since it would
obviously cause conflicts.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove grammatically ambiguous option_error

This commit decreases 6 shift/reduce conflicts, and finally achieves
conflict-free parser.

Since Kconfig has no terminator for a config block, detecting the end
of config_stmt is not easy.

For example, there are two ways for handling the error in the following
code:

  1 config FOO
  2         =

 [A] Print "unknown option" error, assuming the line 2 is a part of
     config_option_list

 [B] Print "invalid statement", assuming the line 1 is reduced into
     a config_stmt by itself

Bison actually chooses [A] because it performs the shift rather than
the reduction where both are possible.

However, there is no reason to choose one over the other.

Let's remove the option_error, and let it fall back to [B].

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove grammatically ambiguous "unexpected option" diagnostic

This commit decreases 15 shift/reduce conflicts.

The location of this error recovery is ambiguous.

For example, there are two ways to interpret the following code:

  1 config FOO
  2         bool "foo"

 [A] Both lines are reduced together into a config_stmt.

 [B] The only line 1 is reduced into a config_stmt, and the line 2
     matches to "option_name error T_EOL"

Of course, we expect [A], but [B] could be grammatically possible.

Kconfig has no terminator for a config block. So, we cannot detect its
end until we see a non-property keyword. People often insert a blank
line between two config blocks, but it is just a coding convention.
Blank lines are actually allowed anywhere in Kconfig files.

The real error is when a property keyword appears right after "endif",
"endchoice", "endmenu",  "source", "comment", or variable assignment.

Instead of fixing the grammatical ambiguity, I chose to simply remove
this error recovery.

The difference is

  unexpected option "bool"

... is turned into a more generic message:

  invalid statement

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: warn no new line at end of file

It would be nice to warn if a new line is missing at end of file.

We could do this by checkpatch.pl for arbitrary files, but new line
is rather essential as a statement terminator in Kconfig.

The warning message looks like this:

  kernel/Kconfig.preempt:60:warning: no new line at end of file

Currently, kernel/Kconfig.preempt is the only file with no new line
at end of file. Fix it.

I know there are some false negative cases. For example, no warning
is displayed when the last line contains some whitespaces/comments,
but no new line. Yet, this commit works well for most cases.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: clean up EOF handling in the lexer

A new file should always start in the INITIAL state.

When the lexer bumps into EOF, the lexer must get back to the INITIAL
state anyway. Remove the redundant <<EOF>> pattern in the PARAM state.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix ambiguous grammar in terms of new lines

This commit decreases 8 shift/reduce conflicts.

A certain amount of grammatical ambiguity comes from how to reduce
excessive T_EOL tokens.

Let's take a look at the example code below:

  1  config A
  2          bool "a"
  3
  4          depends on B
  5
  6  config B
  7          def_bool y

The line 3 is melt into "config_option_list", but the line 5 can be
either a part of "config_option_list" or "common_stmt" by itself.

Currently, the lexer converts '\n' to T_EOL verbatim. In Kconfig,
a new line works as a statement terminator, but new lines in empty
lines are not critical since empty lines (or lines that contain only
whitespaces/comments) are just no-op.

If the lexer simply discards no-op lines, the parser will not be
bothered by excessive T_EOL tokens.

Of course, this means we are shifting the complexity from the parser
to the lexer, but it is much easier than tackling on shift/reduce
conflicts.

I introduced the second stage lexer to tweak the behavior.

Discard T_EOL if the previous token is T_EOL or T_HELPTEXT.
Two T_EOL tokens in a row is meaningless. T_HELPTEXT is a special
token that is reduced without T_EOL.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: refactor pattern matching in STRING state

Here, similar matching patters are duplicated in order to look ahead
the '\n' character. If the next character is '\n', the lexer returns
T_WORD_QUOTE because it must be prepared to return T_EOL at the next
match.

Use unput('\n') trick to reduce the code duplication.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove unneeded pattern matching to whitespaces

Whitespaces are consumed in the COMMAND state anyway.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: require T_EOL to reduce visible statement

All line-oriented statements should be reduced when seeing a T_EOL
token. I guess missing T_EOL for the "visible" statement is just a
mistake. This commit decreases one shift/reduce conflict.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix memory leak when EOF is encountered in quotation

An unterminated string literal followed by new line is passed to the
parser (with "multi-line strings not supported" warning shown), then
handled properly there.

On the other hand, an unterminated string literal at end of file is
never passed to the parser, then results in memory leak.

[Test Code]

  ----------(Kconfig begin)----------
  source "Kconfig.inc"

  config A
          bool "a"
  -----------(Kconfig end)-----------

  --------(Kconfig.inc begin)--------
  config B
          bool "b\No new line at end of file
  ---------(Kconfig.inc end)---------

[Summary from Valgrind]

  Before the fix:

    LEAK SUMMARY:
       definitely lost: 16 bytes in 1 blocks
       ...

  After the fix:

    LEAK SUMMARY:
       definitely lost: 0 bytes in 0 blocks
       ...

Eliminate the memory leak path by handling this case. Of course, such
a Kconfig file is wrong already, so I will add an error message later.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix file name and line number of warn_ignored_character()

Currently, warn_ignore_character() displays invalid file name and
line number.

The lexer should use current_file->name and yylineno, while the parser
should use zconf_curname() and zconf_lineno().

This difference comes from that the lexer is always going ahead
of the parser. The parser needs to look ahead one token to make a
shift/reduce decision, so the lexer is requested to scan more text
from the input file.

This commit fixes the warning message from warn_ignored_character().

[Test Code]

  ----(Kconfig begin)----
  /
  -----(Kconfig end)-----

[Output]

  Before the fix:

  <none>:0:warning: ignoring unsupported character '/'

  After the fix:

  Kconfig:1:warning: ignoring unsupported character '/'

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove k_invalid from expr_parse_string() return type

The only possibility of k_invalid being returned was when
expr_parse_sting() parsed S_OTHER type symbol. This actually never
happened, and this is even clearer since S_OTHER has gone.

Clean up unreachable code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove S_OTHER symbol type and correct dependency tracking

The S_OTHER type could be set only when conf_read_simple() is reading
include/config/auto.conf file.

For example, CONFIG_FOO=y exists in include/config/auto.conf but it is
missing from the currently parsed Kconfig files, sym_lookup() allocates
a new symbol, and sets its type to S_OTHER.

Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines
below while it is obviously bool or tristate type. On the other hand,
when CONFIG_BAR="bar" is being dropped from include/config/auto.conf,
its type remains S_OTHER. Because for_all_symbols() omits S_OTHER
symbols, conf_touch_deps() misses to touch include/config/bar.h

This behavior has been a pretty mystery for me, and digging the git
histroy did not help. At least, touching depfiles is broken for string
type symbols.

I removed S_OTHER entirely, and reimplemented it more simply.

If CONFIG_FOO was visible in the previous syncconfig, but is missing
now, what we want to do is quite simple; just call conf_touch_dep()
to touch include/config/foo.h instead of allocating a new symbol data.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: split out code touching a file to conf_touch_dep()

conf_touch_deps() iterates over symbols, touching corresponding
include/config/*.h files as needed.

Split the part that touches a single file into a new helper so it can
be reused.

The new helper, conf_touch_dep(), takes a symbol name as a parameter,
and touches the corresponding include/config/*.h file.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename conf_split_config() to conf_touch_deps()

According to commit 2e3646e51b2d ("kconfig: integrate split config
into silentoldconfig"), this function was named after split-include
tool, which used to exist in old versions of Linux.

Setting aside the historical reason, rename it into a more intuitive
name. This function touches timestamp files under include/config/
in order to interact with the fixdep tool.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove unneeded setsym label in conf_read_simple()

The two 'goto setsym' statements are reachable only when sym == NULL.

The code below the 'setsym:' label does nothing when sym == NULL
since there is just one if-block guarded by 'if (sym && ...)'.

Hence, 'goto setsym' can be replaced with 'continue'.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove oldnoconfig target

As commit 312ee68752fa ("kconfig: announce removal of oldnoconfig if
used") announced, it is time for the removal.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: suppress "configuration written to .config" for syncconfig

The top-level Makefile invokes "make syncconfig" when necessary.
Then, Kconfig displays the following message when .config is updated.

  #
  # configuration written to .config
  #

It is distracting because "make syncconfig" happens during the build
stage, and does nothing important in most cases.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: improve the recursive dependency report

This commit improves the messages of the recursive dependency.
Currently, sym->dir_dep.expr is not checked.  Hence, any dependency
in property visibility is regarded as the dependency of the symbol.

[Test Code 1]

  config A
          bool "a"
          depends on B

  config B
          bool "b"
          depends on A

[Test Code 2]

  config A
          bool "a" if B

  config B
          bool "b"
          depends on A

For both cases above, the same message is displayed:

        symbol B depends on A
        symbol A depends on B

This commit changes the message for the latter, like this:

        symbol B depends on A
        symbol A prompt is visible depending on B

Also, 'select' and 'imply' are distinguished.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: report recursive dependency involving 'imply'

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: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: error out when seeing recursive dependency

Originally, recursive dependency was a fatal error for Kconfig
because Kconfig cannot compute symbol values in such a situation.

Commit d595cea62403 ("kconfig: print more info when we see a recursive
dependency") changed it to a warning, which I guess was not intentional.

Get it back to an error again.

Also, rename the unit test directory "warn_recursive_dep" to
"err_recursive_dep" so that it matches to the behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove P_ENV property type

This property is not set by anyone since commit 104daea149c4 ("kconfig:
reference environment variables directly and remove 'option env='").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove unused sym_get_env_prop() function

This function is unused since commit 104daea149c4 ("kconfig: reference
environment variables directly and remove 'option env='").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix the rule of mainmenu_stmt symbol

The rule of mainmenu_stmt does not have debug print of zconf_lineno(),
but if it had, it would print a wrong line number for the same reason
as commit b2d00d7c61c8 ("kconfig: fix line numbers for if-entries in
menu tree").

The mainmenu_stmt does not need to eat following empty lines because
they are reduced to common_stmt.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: allow all config targets to write auto.conf if missing

Currently, only syncconfig creates or updates include/config/auto.conf
and some other files.  Other config targets create or update only the
.config file.

When you configure and build the kernel from a pristine source tree,
any config target is followed by syncconfig in the build stage since
include/config/auto.conf is missing.

We are moving compiler tests from Makefile to Kconfig.  It means that
parsing Kconfig files will be more costly since Kconfig invokes the
compiler commands internally.  Thus, we want to avoid invoking Kconfig
twice (one for *config to create the .config, and one for syncconfig
to synchronize the auto.conf).  If auto.conf does not exist, we can
generate all configuration files in the first configuration stage,
which will save the syncconfig in the build stage.

Please note this should be done only when auto.conf is missing.  If
*config blindly did this, time stamp files under include/config/ would
be unnecessarily touched, triggering unneeded rebuild of objects.

I assume a scenario like this:

 1. You have a source tree that has already been built
    with CONFIG_FOO disabled

 2. Run "make menuconfig" to enable CONFIG_FOO

 3. CONFIG_FOO turns out to be unnecessary.
    Run "make menuconfig" again to disable CONFIG_FOO

 4. Run "make"

In this case, include/config/foo.h should not be touched since there
is no change in CONFIG_FOO.  The sync process should be delayed until
the user really attempts to build the kernel.

This commit has another motivation; I want to suppress the 'No such
file or directory' warning from the 'include' directive.

The top-level Makefile includes auto.conf with '-include' directive,
like this:

  ifeq ($(dot-config),1)
  -include include/config/auto.conf
  endif

This looks strange because auto.conf is mandatory when dot-config is 1.
I guess only the reason of using '-include' is to suppress the warning
'include/config/auto.conf: No such file or directory' when building
from a clean tree.  However, this has a side-effect; Make considers
the files included by '-include' are optional.  Hence, Make continues
to build even if it fails to generate include/config/auto.conf.  I will
change this in the next commit, but the warning message is annoying.
(At least, kbuild test robot reports it as a regression.)

With this commit, Kconfig will generate all configuration files together
with the .config and I guess it is a solution good enough to suppress
the warning.

Note:
GNU Make 4.2 or later does not display the warning from the 'include'
directive if include files are successfully generated.  See GNU Make
commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
errors.")  However, older GNU Make versions are still widely used.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: make syncconfig update .config regardless of sym_change_count

syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.

Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over.  Of course, this is just a
matter of comments, but why not fix it.

I see some scenarios where this happens.

Scenario A:

 1. You have a source tree that has already been configured.

 2. Linus increments the version number in the top-level Makefile
    (i.e. he commits a new release)

 3. You pull it, and run 'make'

 4. syncconfig is invoked because the environment variable,
    KERNELVERSION is updated, but the .config is not updated since
    no config symbol is changed.

 5. The .config file contains a kernel version in the top line:

    # Automatically generated file; DO NOT EDIT.
    # Linux/arm64 4.18.0-rc2 Kernel Configuration

    ... which points to a previous version.

Scenario B:

 1. You have a source tree that has already been configured.

 2. You upgrade the compiler, but it still has the same version number.
    This may happen if you regularly build the latest compiler from
    the source code.

 3. You run 'make'

 4. syncconfig is invoked because the environment variable,
    CC_VERSION_TEXT is updated, but the .config is not updated since
    no config symbol is changed.

 5. The .config file contains the version string of the compiler:

    #
    # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
    #

    ... which carries the information of the old compiler.

If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file.  Otherwise, it is fine to update it regardless of
sym_change_count.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: create directories needed for syncconfig by itself

'make syncconfig' creates some files such as include/config/auto.conf,
include/generate/autoconf.h, etc. but the necessary directory creation
relies on scripts/kconfig/Makefile.

To make Kconfig self-contained, create directories as needed in
conf_write_autoconf().

This change allows scripts/kconfig/Makefile cleanups; syncconfig can
be merged into simple-targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: split out useful helpers in confdata.c

Split out helpers:
 is_present() - check if the given path exists
 is_dir() - check if the given path exists and it is a directory
 make_parent_dir() - create the parent directories of the given path

These helpers will be reused in later commits.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename file_write_dep and move it to confdata.c

file_write_dep() is called only from conf_write_autoconf().
Move it from util.c to confdata.c to make it static.
Also, rename it to conf_write_dep() since it should belong to
the group of conf_write* functions.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: handle format string before calling conf_message_callback()

As you see in mconf.c and nconf.c, conf_message_callback() hooks are
likely to end up with the boilerplate of vsnprintf().  Process the
string format before calling conf_message_callback() so that it
receives a simple string.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE

Over time, the use of the flag SYMBOL_AUTO changed from initially
marking three automatically generated symbols ARCH, KERNELRELEASE and
UNAME_RELEASE to today's effect of protecting symbols from being
written out.

Currently, only symbols of type CHOICE and those with option
defconf_list set have that flag set.

Reflect that change in semantics in the flag's name.

Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: loop boundary condition fix

If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around
to (size_t)-1, leading to invalid memory accesses.

This has caused segmentation faults when trying to build the latest
kernel snapshots for i686 in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1592374

Signed-off-by: Jerry James <loganjerry@gmail.com>
[alexpl@fedoraproject.org: reformatted patch for submission]
Signed-off-by: Alexander Ploumistos <alexpl@fedoraproject.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: handle P_SYMBOL in print_symbol()

Each symbol has a property of type P_SYMBOL since commit
59e89e3ddf85 (kconfig: save location of config symbols).
Handle those properties in print_symbol().

Further, place a pointer to print_symbol() in the comment above the
list of known property type.

Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix line numbers for if-entries in menu tree

The line numers for if-entries in the menu tree are off by one or more
lines which is confusing when debugging for correctness of unrelated changes.

According to the git log, commit a02f0570ae201c49 (kconfig: improve
error handling in the parser) was the last one that changed that part
of the parser and replaced

"if_entry: T_IF expr T_EOL"
by
"if_entry: T_IF expr nl"

but the commit message does not state why this has been done.

When reverting that part of the commit, only the line numers are
corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
the menu tree remains unchanged (checked with zconfdump() enabled in
conf.c).

An example for the corrected line numbers:

drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
drivers/soc/tegra/Kconfig:4:if
drivers/soc/tegra/Kconfig:6:if

changes to:

drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
drivers/soc/tegra/Kconfig:1:if
drivers/soc/tegra/Kconfig:4:if

Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: Avoid format overflow warning from GCC 8.1

In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
  sprintf(newname, "%s%s", dirname, basename);
                      ^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
  sprintf(newname, "%s%s", dirname, basename);
                   ^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
  sprintf(newname, "%s%s", dirname, basename);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
                       ^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Increase the size of tmpname and newname to make GCC happy.

Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: error out if a recursive variable references itself

When using a recursively expanded variable, it is a common mistake
to make circular reference.

For example, Make terminates the following code:

  X = $(X)
  Y := $(X)

Let's detect the circular expansion in Kconfig, too.

On the other hand, a function that recurses itself is a commonly-used
programming technique.  So, Make does not check recursion in the
reference with 'call'.  For example, the following code continues
running eternally:

  X = $(call X)
  Y := $(X)

Kconfig allows circular expansion if one or more arguments are given,
but terminates when the same function is recursively invoked 1000 times,
assuming it is a programming mistake.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: add 'filename' and 'lineno' built-in variables

The special variables, $(filename) and $(lineno), are expanded to a
file name and its line number being parsed, respectively.

Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: add 'info', 'warning-if', and 'error-if' built-in functions

Syntax:
  $(info,<text>)
  $(warning-if,<condition>,<text>)
  $(error-if,<condition>,<text)

The 'info' function prints a message to stdout as in Make.

The 'warning-if' and 'error-if' are similar to 'warning' and 'error'
in Make, but take the condition parameter.  They are effective only
when the <condition> part is y.

Kconfig does not implement the lazy expansion as used in the 'if'
'and, 'or' functions in Make.  In other words, Kconfig does not
support conditional expansion.  The unconditional 'error' function
would always terminate the parsing, hence would be useless in Kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: expand lefthand side of assignment statement

Make expands the lefthand side of assignment statements.  In fact,
Kbuild relies on it since kernel makefiles mostly look like this:

  obj-$(CONFIG_FOO) += foo.o

Do likewise in Kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: support append assignment operator

Support += operator.  This appends a space and the text on the
righthand side to a variable.

The timing of the evaluation of the righthand side depends on the
flavor of the variable.  If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred.  Appending something to an
undefined variable results in a recursive variable.

To implement this, we need to remember the flavor of variables.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: support simply expanded variable

The previous commit added variable and user-defined function.  They
work similarly in the sense that the evaluation is deferred until
they are used.

This commit adds another type of variable, simply expanded variable,
as we see in Make.

The := operator defines a simply expanded variable, expanding the
righthand side immediately.  This works like traditional programming
language variables.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: support user-defined function and recursively expanded variable

Now, we got a basic ability to test compiler capability in Kconfig.

config CC_HAS_STACKPROTECTOR
        def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n)

This works, but it is ugly to repeat this long boilerplate.

We want to describe like this:

config CC_HAS_STACKPROTECTOR
        bool
        default $(cc-option,-fstack-protector)

It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like that.  Hence, here is another
feature, user-defined function.  This works as a textual shorthand
with parameterization.

A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions.  A user-defined
function in Make is referenced like $(call my-func,arg1,arg2), but I
omitted the 'call' to make the syntax shorter.

The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters.  It is grammatically valid
to pass more or fewer arguments when calling it.  We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.

By the way, a variable is supported as a subset of this feature since
a variable is "a user-defined function with zero argument".  In this
context, I mean "variable" as recursively expanded variable.  I will
add a different flavored variable in the next commit.

The code above can be written as follows:

[Example Code]

  success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n)
  cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)

  config CC_HAS_STACKPROTECTOR
          def_bool $(cc-option,-fstack-protector)

[Result]
  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_CC_HAS_STACKPROTECTOR=y

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: begin PARAM state only when seeing a command keyword

Currently, any statement line starts with a keyword with TF_COMMAND
flag.  So, the following three lines are dead code.

        alloc_string(yytext, yyleng);
        zconflval.string = text;
        return T_WORD;

If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.

The next commit will support the assignment statement where a line
starts with an arbitrary identifier.  So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: add 'shell' built-in function

This accepts a single command to execute.  It returns the standard
output from it.

[Example code]

  config HELLO
          string
          default "$(shell,echo hello world)"

  config Y
          def_bool $(shell,echo y)

[Result]

  $ make -s alldefconfig && tail -n 2 .config
  CONFIG_HELLO="hello world"
  CONFIG_Y=y

Caveat:
Like environments, functions are expanded in the lexer.  You cannot
pass symbols to function arguments.  This is a limitation to simplify
the implementation.  I want to avoid the dynamic function evaluation,
which would introduce much more complexity.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: add built-in function support

This commit adds a new concept 'function' to do more text processing
in Kconfig.

A function call looks like this:

  $(function,arg1,arg2,arg3,...)

This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: make default prompt of mainmenu less specific

If "mainmenu" is not specified, "Linux Kernel Configuration" is used
as a default prompt.

Given that Kconfig is used in other projects than Linux, let's use
a more generic prompt, "Main menu".

Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove sym_expand_string_value()

There is no more caller of sym_expand_string_value().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove string expansion for mainmenu after yyparse()

Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.

The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove string expansion in file_lookup()

There are two callers of file_lookup(), but there is no more reason
to expand the given path.

[1] zconf_initscan()
    This is used to open the first Kconfig.  sym_expand_string_value()
    has never been used in a useful way here; before opening the first
    Kconfig file, obviously there is no symbol to expand.  If you use
    expand_string_value() instead, environments in KBUILD_KCONFIG would
    be expanded, but I do not see practical benefits for that.

[2] zconf_nextfile()
    This is used to open the next file from 'source' statement.
    Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
    but it was replaced with the direct environment expansion.  The
    environment has already been expanded before the token is passed
    to the parser.

By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
        if (!strcmp(name, file->name)) {

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: reference environment variables directly and remove 'option env='

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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: drop localization support

The localization support is broken and appears unused.
There is no google hits on the update-po-config target.
And there is no recent (5 years) activity related to the localization.

So lets just drop this as it is no longer used.

Suggested-by: Ulf Magnusson <ulfalizer@gmail.com>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: extend output of 'listnewconfig'

We at Red Hat/Fedora have generally tried to have a per file breakdown of
every config option we set.  This makes it easy for us to add new options
when they are exposed and keep a changelog of why they were set.

A Fedora example is here:
  https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/configs/fedora/generic

Using various merge scripts, we build up a config file and run it through
'make listnewconfig' and 'make oldnoconfig'.   The idea is to print out new
config options that haven't been manually set and use the default until
a patch is posted to set it properly.

To speed things up, it would be nice to make it easier to generate a
patch to post the default setting.  The output of 'make listnewconfig'
has two issues that limit us:

- it doesn't provide the default value
- it doesn't provide the new 'choice' options that get flagged in
  'oldconfig'

This patch extends 'listnewconfig' to address the above two issues.

This allows us to run a script

make listnewconfig | rhconfig-tool -o patches; git send-email patches/

The output of 'make listnewconfig':

CONFIG_NET_EMATCH_IPT
CONFIG_IPVLAN
CONFIG_ICE
CONFIG_NET_VENDOR_NI
CONFIG_IEEE802154_MCR20A
CONFIG_IR_IMON_DECODER
CONFIG_IR_IMON_RAW

The new output of 'make listnewconfig':

CONFIG_KERNEL_XZ=n
CONFIG_KERNEL_LZO=n
CONFIG_NET_EMATCH_IPT=n
CONFIG_IPVLAN=n
CONFIG_ICE=n
CONFIG_NET_VENDOR_NI=y
CONFIG_IEEE802154_MCR20A=n
CONFIG_IR_IMON_DECODER=n
CONFIG_IR_IMON_RAW=n

Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: use yylineno option instead of manual lineno increments

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: detect recursive inclusion earlier

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove duplicated file name and lineno of recursive inclusion

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: make unmet dependency warnings readable

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: warn unmet direct dependency of tristate symbols selected by y

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: hide irrelevant sub-menus for oldconfig

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove redundant input_mode test for check_conf() loop

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: remove unneeded input_mode test in conf()

conf() is never called for listnewconfig / olddefconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: do not call check_conf() for olddefconfig

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: only write '# CONFIG_FOO is not set' for visible symbols

=== 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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: Print reverse dependencies in groups

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: clean-up reverse dependency help implementation

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>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: fix line number in recursive inclusion error message

When recursive inclusion is detected, the line number of the last
'included from:' is wrong.

[Test Case]

Kconfig:
  -------->8--------
  source "Kconfig2"
  -------->8--------

Kconfig2:
  -------->8--------
  source "Kconfig3"
  -------->8--------

Kconfig3:
  -------->8--------
  source "Kconfig"
  -------->8--------

[Result]

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  Kconfig:1: recursive inclusion detected. Inclusion path:
    current file : 'Kconfig'
    included from: 'Kconfig3:1'
    included from: 'Kconfig2:1'
    included from: 'Kconfig:3'
  scripts/kconfig/Makefile:89: recipe for target 'allyesconfig' failed
  make[1]: *** [allyesconfig] Error 1
  Makefile:512: recipe for target 'allyesconfig' failed
  make: *** [allyesconfig] Error 2

where we expect

    current file : 'Kconfig'
    included from: 'Kconfig3:1'
    included from: 'Kconfig2:1'
    included from: 'Kconfig:1'

The 'iter->lineno+1' in the second fpinrtf() should be 'iter->lineno-1'.
I refactored the code to merge the two fprintf() calls.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

kconfig: Don't leak choice names during parsing

The named choice is not used in the kernel tree, but if it were used,
it would not be freed.

The intention of the named choice can be seen in the log of
commit 5a1aa8a1aff6 ("kconfig: add named choice group").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>