1. 03 8月, 2010 5 次提交
  2. 18 5月, 2010 3 次提交
  3. 08 5月, 2010 1 次提交
    • R
      eeepc-wmi: depends on BACKLIGHT_CLASS_DEVICE · d89d63a9
      Randy Dunlap 提交于
      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: NRandy Dunlap <randy.dunlap@oracle.com>
      d89d63a9
  4. 13 4月, 2010 1 次提交
    • I
      eeepc-wmi: Build fix · fb48aef7
      Ingo Molnar 提交于
      -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: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      fb48aef7
  5. 01 4月, 2010 1 次提交
  6. 08 3月, 2010 1 次提交
    • R
      msi-laptop: depends on RFKILL · 410c1765
      Randy Dunlap 提交于
      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: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Lennart Poettering <mzxreary@0pointer.de>
      Cc: Lee, Chun-Yi <jlee@novell.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      410c1765
  7. 02 3月, 2010 1 次提交
    • I
      compal-laptop: Make it depend on CONFIG_RFKILL · 51c1410b
      Ingo Molnar 提交于
      -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: NIngo Molnar <mingo@elte.hu>
      51c1410b
  8. 01 3月, 2010 2 次提交
  9. 26 2月, 2010 2 次提交
  10. 16 1月, 2010 1 次提交
  11. 27 12月, 2009 2 次提交
  12. 24 12月, 2009 1 次提交
  13. 17 12月, 2009 4 次提交
  14. 10 12月, 2009 1 次提交
  15. 19 9月, 2009 1 次提交
  16. 29 8月, 2009 1 次提交
  17. 02 8月, 2009 2 次提交
    • H
      thinkpad-acpi: remove dock and bay subdrivers · 1f6fc2de
      Henrique de Moraes Holschuh 提交于
      The standard ACPI dock driver can handle the hotplug bays and docks of
      the ThinkPads just fine (including batteries) as of 2.6.27, and the
      code in thinkpad-acpi for the dock and bay subdrivers is currently
      broken anyway...
      
      Userspace needs some love to support the two-stage ejection nicely,
      but it is simple enough to do through udev rules (you don't even need
      HAL) so this wouldn't justify fixing the dock and bay subdrivers,
      either.
      
      That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
      as support for the weird dock of the model 570, but since such support
      has never left the "experimental" stage, it is also not a strong
      enough reason to find a way to fix this code.
      
      Users of ThinkPads with warm-swap bays are urged to request that _EJ3
      support be added to the regular ACPI dock driver, if such feature is
      indeed useful for them.
      Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1f6fc2de
    • H
      thinkpad-acpi: disable broken bay and dock subdrivers · 550e7fd8
      Henrique de Moraes Holschuh 提交于
      Currently, the ThinkPad-ACPI bay and dock drivers are completely
      broken, and cause a NULL pointer derreference in kernel mode (and,
      therefore, an OOPS) when they try to issue events (i.e. on dock,
      undock, bay ejection, etc).
      
      OTOH, the standard ACPI dock driver can handle the hotplug bays and
      docks of the ThinkPads just fine (including batteries) as of 2.6.27.
      In fact, it does a much better job of it than thinkpad-acpi ever did.
      
      It is just not worth the hassle to find a way to fix this crap without
      breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
      deprecated code that sees little testing or use.
      
      As a quick fix suitable for -stable backports, mark the thinkpad-acpi
      bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
      removed by a later patch.
      
      This fixes bugzilla #13669, and should be applied to 2.6.27 and later.
      Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Reported-by: NJoerg Platte <jplatte@naasa.net>
      Cc: stable@kernel.org
      Signed-off-by: NLen Brown <len.brown@intel.com>
      550e7fd8
  18. 30 6月, 2009 1 次提交
    • I
      eeepc-laptop: Fix build failure with HOTPLUG_PCI && !SYSFS · 44b3615b
      Ingo Molnar 提交于
      FYI, there's a post-rc1 build regression with certain configs:
      
       drivers/built-in.o: In function `pci_hp_deregister':
       (.text+0xb166): undefined reference to `pci_hp_remove_module_link'
       drivers/built-in.o: In function `pci_hp_deregister':
       (.text+0xb19f): undefined reference to `pci_destroy_slot'
       drivers/built-in.o: In function `__pci_hp_register':
       (.text+0xb583): undefined reference to `pci_create_slot'
       drivers/built-in.o: In function `__pci_hp_register':
       (.text+0xb5b1): undefined reference to `pci_hp_create_module_link'
       make: *** [.tmp_vmlinux1] Error 1
      
      Caused by:
      
      | 2b121bc2 is first bad commit
      | commit 2b121bc2
      | Date:   Thu Jun 25 13:25:36 2009 +0200
      |
      |     eeepc-laptop: Register as a pci-hotplug device
      
      which changed the driver to use the PCI hotplug infrastructure, but
      didn't do a good job on the Kconfig rules.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      44b3615b
  19. 26 6月, 2009 1 次提交
  20. 24 6月, 2009 4 次提交
  21. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      Johannes Berg 提交于
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df
  22. 04 4月, 2009 3 次提交