1. 10 Jan, 2011 1 commit
    • Mark Brown's avatar
      platform/x86: Consistently select LEDS Kconfig options · 0c51a4d8
      Mark Brown authored
      
      
      Currently the x86 platform devices are not consistent about selecting
      or depending on the LEDs Kconfig variables, and this inconsistency
      leads to Kconfig getting upset and refusing to offer LEDs (even on
      non-x86 platforms):
      
      drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
      drivers/platform/x86/Kconfig:422:       symbol EEEPC_WMI depends on ACPI_WMI
      drivers/platform/x86/Kconfig:438:       symbol ACPI_WMI is selected by ACER_WMI
      drivers/platform/x86/Kconfig:18:        symbol ACER_WMI depends on LEDS_CLASS
      drivers/leds/Kconfig:10:        symbol LEDS_CLASS is selected by EEEPC_WMI
      
      Fix this by always selecting rather than depending on the symbols as
      slightly more drivers use this approach already and it seems more
      user friendly.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      0c51a4d8
  2. 07 Jan, 2011 6 commits
  3. 21 Oct, 2010 10 commits
  4. 23 Aug, 2010 1 commit
    • Jonathan Corbet's avatar
      ACPI_TOSHIBA needs LEDS support · c76a3e1d
      Jonathan Corbet authored
      
      
      Don't ask how ACPI_TOSHIBA got enabled on in desktop system's .config -
      I don't know.  But it has silently been there until I tried 2.6.36-rc2,
      where it broke the build because I don't have LED support turned on.
      Attached patch fixes things up.
      
      (I had to change BACKLIGHT_CLASS_DEVICE to "depends" because otherwise
      I get unsightly core dumps out of scripts/kconfig/conf).
      
      jon
      
      --
      toshiba: make sure we pull in LED support
      
      The Toshiba extras driver uses the LED module, so make sure we have it
      configure in.
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      c76a3e1d
  5. 10 Aug, 2010 1 commit
  6. 03 Aug, 2010 8 commits
  7. 17 May, 2010 3 commits
  8. 07 May, 2010 1 commit
    • Randy Dunlap's avatar
      eeepc-wmi: depends on BACKLIGHT_CLASS_DEVICE · d89d63a9
      Randy Dunlap authored
      
      
      eeepc-wmi uses backlight*() interfaces so it should depend on
      BACKLIGHT_CLASS_DEVICE.
      
      eeepc-wmi.c:(.text+0x2d7f54): undefined reference to `backlight_force_update'
      eeepc-wmi.c:(.text+0x2d8012): undefined reference to `backlight_device_register'
      eeepc-wmi.c:(.devinit.text+0x1c31c): undefined reference to `backlight_device_unregister'
      eeepc-wmi.c:(.devexit.text+0x2f8b): undefined reference to `backlight_device_unregister'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      d89d63a9
  9. 12 Apr, 2010 1 commit
    • Ingo Molnar's avatar
      eeepc-wmi: Build fix · fb48aef7
      Ingo Molnar authored
      
      
      -tip testing found:
      
      eeepc-wmi.c:(.text+0x36673c): undefined reference to `sparse_keymap_report_event'
      drivers/built-in.o: In function `eeepc_wmi_init':
      eeepc-wmi.c:(.init.text+0x19cd0): undefined reference to `sparse_keymap_setup'
      eeepc-wmi.c:(.init.text+0x19cf0): undefined reference to `sparse_keymap_free'
      eeepc-wmi.c:(.init.text+0x19d0b): undefined reference to `sparse_keymap_free'
      drivers/built-in.o: In function `eeepc_wmi_exit':
      eeepc-wmi.c:(.exit.text+0x2e87): undefined reference to `sparse_keymap_free'
      
      To fix this select INPUT_SPARSEKMAP, like the ASUS driver does.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      fb48aef7
  10. 31 Mar, 2010 1 commit
  11. 07 Mar, 2010 1 commit
    • Randy Dunlap's avatar
      msi-laptop: depends on RFKILL · 410c1765
      Randy Dunlap authored
      
      
      msi-laptop uses rfkill*() interfaces so it should depend on RFKILL.
      
      msi-laptop.c:(.text+0x1fcd1b): undefined reference to `rfkill_alloc'
      msi-laptop.c:(.text+0x1fcd76): undefined reference to `rfkill_register'
      msi-laptop.c:(.text+0x1fcdc8): undefined reference to `rfkill_destroy'
      msi-laptop.c:(.text+0x1fcdd9): undefined reference to `rfkill_unregister'
      
      This repairs "msi-laptop: Detect 3G device exists by standard ec command",
      which is in some gregkh tree.
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Lennart Poettering <mzxreary@0pointer.de>
      Cc: Lee, Chun-Yi <jlee@novell.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      410c1765
  12. 02 Mar, 2010 1 commit
    • Ingo Molnar's avatar
      compal-laptop: Make it depend on CONFIG_RFKILL · 51c1410b
      Ingo Molnar authored
      
      
      -tip testing found this build failure (x86 randconfig):
      
       drivers/built-in.o: In function `setup_rfkill':
       compal-laptop.c:(.text+0x36abe8): undefined reference to `rfkill_alloc'
       compal-laptop.c:(.text+0x36abfc): undefined reference to `rfkill_register'
       compal-laptop.c:(.text+0x36ac30): undefined reference to `rfkill_alloc'
       compal-laptop.c:(.text+0x36ac44): undefined reference to `rfkill_register'
      
      Which can happen with CONFIG_COMPAL_LAPTOP=y but COMPAL_LAPTOP=m.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      51c1410b
  13. 28 Feb, 2010 2 commits
  14. 25 Feb, 2010 2 commits
  15. 15 Jan, 2010 1 commit