1. 13 3月, 2009 1 次提交
  2. 22 2月, 2009 1 次提交
  3. 19 2月, 2009 2 次提交
    • R
      x86: dell-laptop: depends on POWER_SUPPLY · 310d8c93
      Randy Dunlap 提交于
      Build breaks when DELL_LAPTOP=y and POWER_SUPPLY=m.  DELL_LAPTOP needs to
      depend on POWER_SUPPLY.
      
      dell-laptop.c:(.text+0x1ef3c4): undefined reference to `power_supply_is_system_supplied'
      dell-laptop.c:(.text+0x1ef45e): undefined reference to `power_supply_is_system_supplied'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      310d8c93
    • A
      eeepc: should depend on INPUT · 3a5093ee
      Alexey Dobriyan 提交于
      Otherwise with INPUT=m, EEEPC_LAPTOP=y one gets
      
      drivers/built-in.o: In function `input_sync':
      eeepc-laptop.c:(.text+0x18ce51): undefined reference to `input_event'
      drivers/built-in.o: In function `input_report_key':
      eeepc-laptop.c:(.text+0x18ce73): undefined reference to `input_event'
      drivers/built-in.o: In function `eeepc_hotk_check':
      eeepc-laptop.c:(.text+0x18d05f): undefined reference to `input_allocate_device'
      eeepc-laptop.c:(.text+0x18d10f): undefined reference to `input_register_device'
      eeepc-laptop.c:(.text+0x18d131): undefined reference to `input_free_device'
      drivers/built-in.o: In function `eeepc_backlight_exit':
      eeepc-laptop.c:(.text+0x18d546): undefined reference to `input_unregister_device'
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a5093ee
  4. 07 2月, 2009 1 次提交
    • D
      eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init · 7695fb04
      Darren Salt 提交于
      I got the following oops while changing the backlight brightness during
      startup.  When it happens, it prevents use of the hotkeys, Fn-Fx, and the
      lid button.
      
      It's a clear use-before-init, as I verified by testing with an
      appropriately-placed "else printk".
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000
      *pde = 00000000
      Oops: 0002 [#1] PREEMPT SMP
      Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901
      EIP: 0060:[<c0264e68>]  [<c0264e68>] eeepc_hotk_notify+26/da
      EFLAGS: 00010246 CPU: 1
      Using defaults from ksymoops -t elf32-i386 -a i386
      EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64
      ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
       f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f
       f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80
       c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091
      Call Trace:
       [<c02164ac>] ? acpi_ev_notify_dispatch+4c/55
       [<c02112e6>] ? acpi_os_execute_deferred+1d/25
       [<c012b62f>] ? run_workqueue+71/f1
       [<c012bdba>] ? worker_thread+0/bf
       [<c012be6e>] ? worker_thread+b4/bf
       [<c012e198>] ? autoremove_wake_function+0/2b
       [<c012bdba>] ? worker_thread+0/bf
       [<c012e0c9>] ? kthread+38/5f
       [<c012e091>] ? kthread+0/5f
       [<c0103abf>] ? kernel_thread_helper+7/10
      Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42
      e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c
      50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01
      Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7695fb04
  5. 06 2月, 2009 1 次提交
  6. 30 1月, 2009 2 次提交
  7. 21 1月, 2009 10 次提交
  8. 18 1月, 2009 1 次提交
  9. 17 1月, 2009 2 次提交
  10. 16 1月, 2009 12 次提交
  11. 10 1月, 2009 1 次提交
    • L
      hp-wmi: handle rfkill_register() failure · fe8e4e03
      Larry Finger 提交于
      Compilation of the HP WMI hotkeys code results in the following:
      
        CC [M]  drivers/platform/x86/hp-wmi.o
      drivers/platform/x86/hp-wmi.c: In function hp_wmi_bios_setup:
      drivers/platform/x86/hp-wmi.c:431: warning: ignoring return value of rfkill_register,
      	 declared with attribute warn_unused_result
      drivers/platform/x86/hp-wmi.c:441: warning: ignoring return value of rfkill_register,
      	 declared with attribute warn_unused_result
      drivers/platform/x86/hp-wmi.c:450: warning: ignoring return value of rfkill_register,
      	 declared with attribute warn_unused_result
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fe8e4e03
  12. 19 12月, 2008 2 次提交
    • L
      ACPI: move wmi, asus_acpi, toshiba_acpi to drivers/platform/x86 · b4f9fe12
      Len Brown 提交于
      These are platform specific drivers that happen to use ACPI,
      while drivers/acpi/ is for code that implements ACPI itself.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b4f9fe12
    • L
      create drivers/platform/x86/ from drivers/misc/ · 41b16dce
      Len Brown 提交于
      Move x86 platform specific drivers from drivers/misc/
      to a new home under drivers/platform/x86/.
      
      The community has been maintaining x86 vendor-specific
      platform specific drivers under /drivers/misc/ for a few years.
      The oldest ones started life under drivers/acpi.
      They moved out of drivers/acpi/ because they don't actually
      implement the ACPI specification, but either simply
      use ACPI, or implement vendor-specific ACPI extensions.
      
      In the future we anticipate...
      drivers/misc/ will go away.
      other architectures will create drivers/platform/<arch>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      41b16dce