1. 25 4月, 2013 3 次提交
    • 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
  2. 17 4月, 2013 3 次提交
  3. 10 4月, 2013 1 次提交
  4. 07 3月, 2013 2 次提交
  5. 03 3月, 2013 3 次提交
  6. 28 2月, 2013 3 次提交
  7. 25 2月, 2013 1 次提交
  8. 22 2月, 2013 16 次提交
  9. 19 2月, 2013 1 次提交
  10. 14 2月, 2013 1 次提交
  11. 13 2月, 2013 1 次提交
    • S
      kbuild: limit dtc+cpp include path · e570d7c1
      Stephen Warren 提交于
      Device tree source files may now include header files. The intent is
      that those header files define/name constants used as part of the DT
      bindings. Currently this feature is open to abuse, since any kernel
      header file at all can be included, This could allow device tree files
      to become dependant on kernel headers files, and thus make them no
      longer OS-independent. This would also prevent separating the device
      tree source files from the kernel repository.
      
      Solve this by limiting the cpp include path for device tree files to
      separate directories.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      e570d7c1
  12. 09 2月, 2013 2 次提交
  13. 08 2月, 2013 1 次提交
  14. 05 2月, 2013 1 次提交
  15. 30 1月, 2013 1 次提交