1. 14 6月, 2013 1 次提交
  2. 30 5月, 2013 2 次提交
    • D
      kconfig/menu.c: fix multiple references to expressions in menu_add_prop() · e983b7b1
      Dirk Gouders 提交于
      menu_add_prop() applies upper menus' visibilities to actual prompts
      by AND-ing the prompts visibilities with the upper menus ones.
      
      This creates a further reference to the menu's visibilities and when
      the expression reduction functions do their work, they may remove or
      modify expressions that have multiple references, thus causing
      unpredictable side-effects.
      
      The following example Kconfig constructs a case where this causes
      problems: a menu and a prompt which's visibilities depend on the same
      symbol.  When invoking mconf with this Kconfig and pressing "Z" we
      see a problem caused by a free'd expression still referenced by the
      menu's visibility:
      
      ------------------------------------------------------------------------
      mainmenu "Kconfig Testing Configuration"
      
      config VISIBLE
      	def_bool n
      
      config Placeholder
      	bool "Place holder"
      
      menu "Invisible"
      	visible if VISIBLE
      
      config TEST_VAR
      	bool "Test option" if VISIBLE
      
      endmenu
      ------------------------------------------------------------------------
      
      This patch fixes this problem by creating copies of the menu's
      visibility expressions before AND-ing them with the prompt's one.
      Signed-off-by: NDirk Gouders <dirk@gouders.net>
      [yann.morin.1998@free.fr: move variable into its block-scope,
                                keep lines <80 chars, typo]
      Tested-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      e983b7b1
    • D
      mconf: handle keys in empty dialogs · 063f4661
      Dirk Gouders 提交于
      When entering an empty dialog, using the movement keys resulted in
      unexpected characters beeing displayed, other keys like "z" and "h"
      did not work as expected.
      
      This patch handles the movement keys as well as other keys, especially
      "z", "h" and "/".
      Signed-off-by: NDirk Gouders <dirk@gouders.net>
      [yann.morin.1998@free.fr: keep lines <80 chars, so reorder test]
      Tested-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      063f4661
  3. 23 5月, 2013 1 次提交
    • M
      kbuild: Don't assume dts files live in arch/*/boot/dts · ad061568
      Matthijs Kooijman 提交于
      In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
      dts building was changed to always use the C preprocessor. This meant
      that the .dts file passed to dtc is not the original, but the
      preprocessed one.
      
      When compiling with a separate build directory (i.e., with O=), this
      preprocessed file will not live in the same directory as the original.
      When the .dts file includes .dtsi files, dtc will look for them in the
      build directory, not in the source directory and compilation will fail.
      
      The commit referenced above tried to fix this by passing arch/*/boot/dts
      as an include path to dtc. However, for mips, the .dts files are not in
      this directory, so dts compilation on mips breaks for some targets.
      
      Instead of hardcoding this particular include path, this commit just
      uses the directory of the .dts file that is being compiled, which
      effectively restores the previous behaviour wrt includes. For most .dts
      files, this path is just the same as the previous hardcoded
      arch/*/boot/dts path.
      
      This was tested on a mips (rt3052) and an arm (bcm2835) target.
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      ad061568
  4. 20 5月, 2013 1 次提交
  5. 16 5月, 2013 1 次提交
  6. 07 5月, 2013 2 次提交
  7. 01 5月, 2013 1 次提交
  8. 30 4月, 2013 11 次提交
  9. 29 4月, 2013 1 次提交
  10. 27 4月, 2013 1 次提交
  11. 25 4月, 2013 5 次提交
    • Y
      kconfig: implement KCONFIG_PROBABILITY for randconfig · e43956e6
      Yann E. MORIN 提交于
      Currently the odds to set each symbol is (rounded):
          booleans:   y: 50%          n: 50%
          tristates:  y: 33%  m: 33%  n: 33%
      
      Introduce a KCONFIG_PROBABILITY environment variable to tweak the
      probabilities (in percentage), as such:
          KCONFIG_PROBABILITY     y:n split           y:m:n split
          -----------------------------------------------------------------
      [1] unset or empty          50  : 50            33  : 33  : 34
      [2] N                        N  : 100-N         N/2 : N/2 : 100-N
          N:M                     N+M : 100-(N+M)      N  :  M  : 100-(N+M)
          N:M:L                    N  : 100-N          M  :  L  : 100-(M+L)
      
      [1] The current behaviour is kept as default, for backward compatibility
      [2] The solution initially implemented by Peter for Buildroot, see:
          http://git.buildroot.org/buildroot/commit/?id=3435c1afb5Signed-off-by: NPeter Korsgaard <jacmet@uclibc.org>
      [yann.morin.1998@free.fr: add to Documentation/]
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      e43956e6
    • Y
      kconfig: allow specifying the seed for randconfig · 0d8024c6
      Yann E. MORIN 提交于
      For reproducibility, it can be useful to be able to specify the
      seed to use to seed the RNG.
      
      Add a new KCONFIG_SEED environment variable which can be set to
      the seed to use:
          $ make KCONFIG_SEED=42 randconfig
          $ sha1sum .config
          70a128c8dcc61303069e1be352cce64114dfcbca  .config
          $ make KCONFIG_SEED=42 randconfig
          $ sha1sum .config
          70a128c8dcc61303069e1be352cce64114dfcbca  .config
      
      It's very usefull for eg. debugging the kconfig parser.
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      0d8024c6
    • Y
      kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG · 422c809f
      Yann E. MORIN 提交于
      Currently, randconfig does randomise choice entries, unless KCONFIG_ALLCONFIG
      is specified.
      
      For example, given those two files (Thomas' test-case):
      
          ---8<--- Config.test.in
          config OPTIONA
              bool "Option A"
      
          choice
              prompt "This is a choice"
      
          config CHOICE_OPTIONA
              bool "Choice Option A"
      
          config CHOICE_OPTIONB
              bool "Choice Option B"
      
          endchoice
      
          config OPTIONB
              bool "Option B"
          ---8<--- Config.test.in
      
          ---8<--- config.defaults
          CONFIG_OPTIONA=y
          ---8<--- config.defaults
      
      And running:
          ./scripts/kconfig/conf --randconfig Config.test.in
      
      does properly randomise the two choice symbols (and the two booleans).
      
      However, running:
          KCONFIG_ALLCONFIG=config.defaults \
          ./scripts/kconfig/conf --randconfig Config.test.in
      
      does *not* reandomise the two choice entries, and only CHOICE_OPTIONA
      will ever be selected. (OPTIONA will always be set (expected), and
      OPTIONB will be be properly randomised (expected).)
      
      This patch defers setting that a choice has a value until a symbol for
      that choice is indeed set, so that choices are properly randomised when
      KCONFIG_ALLCONFIG is set, but not if a symbol for that choice is set.
      
      Also, as a side-efect, this patch fixes the following case:
      
          ---8<---
          choice
          config OPTION_A
              bool "Option A"
          config OPTION_B
              bool "Option B"
          config OPTION_C
              bool "Option C"
          endchoice
          ---8<---
      
      which could previously generate such .config files:
      
          ---8<---                            ---8<---
          CONFIG_OPTION_A=y                   CONFIG_OPTION_A=y
          CONFIG_OPTION_B=y                   # CONFIG_OPTION_B is not set
          # CONFIG_OPTION_C is not set        CONFIG_OPTION_C=y
          ---8<---                            ---8<---
      
      Ie., the first entry in a choice is always set, plus zero or one of
      the other options may be set.
      
      This patch ensures that only one option may be set for a choice.
      Reported-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Arnaud Lacombe <lacombar@gmail.com>
      
      ---
      Changes v2 -> v3
        - ensure only one symbol is set in a choice
      
      Changes v1 -> v2:
        - further postpone setting that a choice has a value until
          one is indeed set
        - do not print symbols that are part of an invisible choice
      422c809f
    • Y
      kconfig: do not override symbols already set · cfa98f2e
      Yann E. MORIN 提交于
      For randconfig, if a list of required symbols is specified with
      KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
      sym_has_value(), but have the "valid" flag set.
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      cfa98f2e
    • Y
      kconfig: fix randconfig tristate detection · 61fa0e17
      Yann E. MORIN 提交于
      Because the modules' symbole (CONFIG_MODULES) may not yet be set when
      we check a symbol's tristate capabilty, we'll always find that tristate
      symbols are booleans, even if we randomly decided that to enable modules:
      sym_get_type(sym) always return boolean for tristates when modules_sym
      has not been previously set to 'y' *and* its value calculated *and* its
      visibility calculated, both of which only occur after we randomly assign
      values to symbols.
      
      Fix that by looking at the raw type of symbols. Tristate set to 'm' will
      be promoted to 'y' when their values will be later calculated.
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      61fa0e17
  12. 18 4月, 2013 5 次提交
  13. 17 4月, 2013 3 次提交
  14. 10 4月, 2013 1 次提交
  15. 09 4月, 2013 1 次提交
  16. 08 4月, 2013 3 次提交