1. 26 3月, 2018 3 次提交
  2. 09 3月, 2018 2 次提交
    • J
      kbuild: Handle builtin dtb file names containing hyphens · 55fe6da9
      James Hogan 提交于
      cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree
      FDT (that is, the .dtb file) as binary data in the kernel image. This
      assembly source contains labels before and after the binary data. The
      label names incorporate the file name of the corresponding .dtb file.
      Hyphens are not legal characters in labels, so .dtb files built into the
      kernel with hyphens in the file name result in errors like the
      following:
      
      bcm3368-netgear-cvg834g.dtb.S: Assembler messages:
      bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'
      bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'
      bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'
      bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-'
      
      Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file
      name to underscores when constructing the labels.
      
      As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC
      contain hyphens in their names, but the issue only currently manifests
      on Broadcom MIPS platforms, as that is the only place where such files
      are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y,
      or on BMIPS kernels when the dtbs target is used (in the latter case it
      admittedly shouldn't really build all the dtb.o files, but thats a
      separate issue).
      
      Fixes: 69583551 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Reviewed-by: NFrank Rowand <frowand.list@gmail.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      55fe6da9
    • M
      scripts/bloat-o-meter: fix typos in help · 61fc4708
      Matteo Croce 提交于
      The bloat-o-meter script has two typos in the help, fix both.
      
      Fixes: 192efb7a ("bloat-o-meter: provide 3 different arguments for data, function and All")
      Signed-off-by: NMatteo Croce <mcroce@redhat.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      61fc4708
  3. 05 3月, 2018 3 次提交
    • R
      fixdep: do not ignore kconfig.h · 638e69cf
      Rasmus Villemoes 提交于
      kconfig.h was excluded from consideration by fixdep by
      6a5be57f (fixdep: fix extraneous dependencies) to avoid some false
      positive hits
      
      (1) include/config/.h
      (2) include/config/h.h
      (3) include/config/foo.h
      
      (1) occurred because kconfig.h contains the string CONFIG_ in a
      comment. However, since dee81e98 (fixdep: faster CONFIG_ search), we
      have a check that the part after CONFIG_ is non-empty, so this does not
      happen anymore (and CONFIG_ appears by itself elsewhere, so that check
      is worthwhile).
      
      (2) comes from the include guard, __LINUX_KCONFIG_H. But with the
      previous patch, we no longer match that either.
      
      That leaves (3), which amounts to one [1] false dependency (aka stat() call
      done by make), which I think we can live with:
      
      We've already had one case [2] where the lack of include/linux/kconfig.h in
      the .o.cmd file caused a missing rebuild, and while I originally thought
      we should just put kconfig.h in the dependency list without parsing it
      for the CONFIG_ pattern, we actually do have some real CONFIG_ symbols
      mentioned in it, and one can imagine some translation unit that just
      does '#ifdef __BIG_ENDIAN' but doesn't through some other header
      actually depend on CONFIG_CPU_BIG_ENDIAN - so changing the target
      endianness could end up rebuilding the world, minus that small
      TU. Quoting Linus,
      
        ... when missing dependencies cause a missed re-compile, the resulting
        bugs can be _really_ subtle.
      
      [1] well, two, we now also have CONFIG_BOOGER/booger.h - we could change
      that to FOO if we care
      
      [2] https://lkml.org/lkml/2018/2/22/838
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      638e69cf
    • R
      fixdep: remove some false CONFIG_ matches · 5b8ad96d
      Rasmus Villemoes 提交于
      The string CONFIG_ quite often appears after other alphanumerics,
      meaning that that instance cannot be referencing a Kconfig
      symbol. Omitting these means make has fewer files to stat() when
      deciding what needs to be rebuilt - for a defconfig build, this seems to
      remove about 2% of the (wildcard ...) lines from the .o.cmd files.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      5b8ad96d
    • R
      fixdep: remove stale references to uml-config.h · 14a596a7
      Rasmus Villemoes 提交于
      uml-config.h hasn't existed in this decade (87e299e5 - x86, um: get
      rid of uml-config.h). The few remaining UML_CONFIG instances are defined
      directly in terms of their real CONFIG symbol in common-offsets.h, so
      unlike when the symbols got defined via a sed script, anything that uses
      UML_CONFIG_FOO now should also automatically pick up a dependency on
      CONFIG_FOO via the normal fixdep mechanism (since common-offsets.h
      should at least recursively be a dependency). Hence I believe we should
      actually be able to ignore the HELLO_CONFIG_BOOM cases.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: user-mode-linux-devel@lists.sourceforge.net
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      14a596a7
  4. 02 3月, 2018 7 次提交
  5. 01 3月, 2018 1 次提交
  6. 21 2月, 2018 3 次提交
  7. 10 2月, 2018 2 次提交
  8. 09 2月, 2018 6 次提交
    • M
      kconfig: send error messages to stderr · 9e3e10c7
      Masahiro Yamada 提交于
      These messages should be directed to stderr.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      9e3e10c7
    • M
      kconfig: echo stdin to stdout if either is redirected · f3ff6fb5
      Masahiro Yamada 提交于
      If stdio is not tty, conf_askvalue() puts additional new line to
      prevent prompts from being concatenated into a single line.  This
      care is missing in conf_choice(), so a 'choice' prompt and the next
      prompt are shown in the same line.
      
      Move the code into xfgets() to cater to all cases.  To improve this
      more, let's echo stdin to stdout.  This clarifies what keys were
      input from stdio and the stdout looks like as if it were from tty.
      
      I removed the isatty(2) check since stderr is unrelated here.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      f3ff6fb5
    • M
      kconfig: remove check_stdin() · d2a04648
      Masahiro Yamada 提交于
      Except silentoldconfig, valid_stdin is 1, so check_stdin() is no-op.
      
      oldconfig and silentoldconfig work almost in the same way except that
      the latter generates additional files under include/.  Both ask users
      for input for new symbols.
      
      I do not know why only silentoldconfig requires stdio be tty.
      
        $ rm -f .config; touch .config
        $ yes "" | make oldconfig > stdout
        $ rm -f .config; touch .config
        $ yes "" | make silentoldconfig > stdout
        make[1]: *** [silentoldconfig] Error 1
        make: *** [silentoldconfig] Error 2
        $ tail -n 4 stdout
        Console input/output is redirected. Run 'make oldconfig' to update configuration.
      
        scripts/kconfig/Makefile:40: recipe for target 'silentoldconfig' failed
        Makefile:507: recipe for target 'silentoldconfig' failed
      
      Redirection is useful, for example, for testing where we want to give
      particular key inputs from a test file, then check the result.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      d2a04648
    • M
      kconfig: remove 'config*' pattern from .gitignnore · cd58a91d
      Masahiro Yamada 提交于
      I could not figure out why this pattern should be ignored.
      Checking commit 1e65174a ("Add some basic .gitignore files")
      did not help.
      
      Let's remove this pattern, then see if it is really needed.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      cd58a91d
    • M
      kconfig: show '?' prompt even if no help text is available · 4f208f39
      Masahiro Yamada 提交于
      'make config', 'make oldconfig', etc. always receive '?' as a valid
      input and show useful information even if no help text is available.
      
      ------------------------>8------------------------
      foo (FOO) [N/y] (NEW) ?
      
      There is no help available for this option.
      Symbol: FOO [=n]
      Type  : bool
      Prompt: foo
        Defined at Kconfig:1
      ------------------------>8------------------------
      
      However, '?' is not shown in the prompt if its help text is missing.
      Let's show '?' all the time so that the prompt and the behavior match.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      4f208f39
    • M
      kconfig: do not write choice values when their dependency becomes n · cb67ab2c
      Masahiro Yamada 提交于
      "# CONFIG_... is not set" for choice values are wrongly written into
      the .config file if they are once visible, then become invisible later.
      
        Test case
        ---------
      
      ---------------------------(Kconfig)----------------------------
      config A
      	bool "A"
      
      choice
      	prompt "Choice ?"
      	depends on A
      
      config CHOICE_B
      	bool "Choice B"
      
      config CHOICE_C
      	bool "Choice C"
      
      endchoice
      ----------------------------------------------------------------
      
      ---------------------------(.config)----------------------------
      CONFIG_A=y
      ----------------------------------------------------------------
      
      With the Kconfig and .config above,
      
        $ make config
        scripts/kconfig/conf  --oldaskconfig Kconfig
        *
        * Linux Kernel Configuration
        *
        A (A) [Y/n] n
        #
        # configuration written to .config
        #
        $ cat .config
        #
        # Automatically generated file; DO NOT EDIT.
        # Linux Kernel Configuration
        #
        # CONFIG_A is not set
        # CONFIG_CHOICE_B is not set
        # CONFIG_CHOICE_C is not set
      
      Here,
      
        # CONFIG_CHOICE_B is not set
        # CONFIG_CHOICE_C is not set
      
      should not be written into the .config file because their dependency
      "depends on A" is unmet.
      
      Currently, there is no code that clears SYMBOL_WRITE of choice values.
      
      Clear SYMBOL_WRITE for all symbols in sym_calc_value(), then set it
      again after calculating visibility.  To simplify the logic, set the
      flag if they have non-n visibility, regardless of types, and regardless
      of whether they are choice values or not.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      cb67ab2c
  9. 07 2月, 2018 13 次提交