An error occurred fetching the project authors.
  1. 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
  2. 28 Feb, 2010 2 commits
  3. 26 Feb, 2010 1 commit
    • Henrique de Moraes Holschuh's avatar
      thinkpad-acpi: lock down video output state access · b525c06c
      Henrique de Moraes Holschuh authored
      Given the right combination of ThinkPad and X.org, just reading the
      video output control state is enough to hard-crash X.org.
      
      Until the day I somehow find out a model or BIOS cut date to not
      provide this feature to ThinkPads that can do video switching through
      X RandR, change permissions so that only processes with CAP_SYS_ADMIN
      can access any sort of video output control state.
      
      This bug could be considered a local DoS I suppose, as it allows any
      non-privledged local user to cause some versions of X.org to
      hard-crash some ThinkPads.
      Reported-by: default avatarJidanni <jidanni@jidanni.org>
      Signed-off-by: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: stable@kernel.org
      b525c06c
  4. 25 Feb, 2010 1 commit
  5. 16 Jan, 2010 1 commit
  6. 27 Dec, 2009 2 commits
  7. 24 Dec, 2009 1 commit
  8. 16 Dec, 2009 4 commits
  9. 09 Dec, 2009 1 commit
  10. 19 Sep, 2009 1 commit
  11. 28 Aug, 2009 1 commit
  12. 02 Aug, 2009 2 commits
    • Henrique de Moraes Holschuh's avatar
      thinkpad-acpi: remove dock and bay subdrivers · 1f6fc2de
      Henrique de Moraes Holschuh authored
      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: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      1f6fc2de
    • Henrique de Moraes Holschuh's avatar
      thinkpad-acpi: disable broken bay and dock subdrivers · 550e7fd8
      Henrique de Moraes Holschuh authored
      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: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Reported-by: default avatarJoerg Platte <jplatte@naasa.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      550e7fd8
  13. 29 Jun, 2009 1 commit
    • Ingo Molnar's avatar
      eeepc-laptop: Fix build failure with HOTPLUG_PCI && !SYSFS · 44b3615b
      Ingo Molnar authored
      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: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      44b3615b
  14. 26 Jun, 2009 1 commit
  15. 24 Jun, 2009 4 commits
  16. 03 Jun, 2009 1 commit
    • Johannes Berg's avatar
      rfkill: rewrite · 19d337df
      Johannes Berg authored
      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: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19d337df
  17. 04 Apr, 2009 2 commits
    • Henrique de Moraes Holschuh's avatar
      thinkpad-acpi: restrict access to some firmware LEDs · a4d5effc
      Henrique de Moraes Holschuh authored
      Some of the ThinkPad LEDs indicate critical conditions that can cause
      data loss or cause hardware damage when ignored (e.g. force-ejecting
      a powered up bay; ignoring a failing battery, or empty battery; force-
      undocking with the dock buses still active, etc).
      
      On almost all ThinkPads, LED access is write-only, and the firmware
      usually does fire-and-forget signaling on them, so you effectively
      lose whatever message the firmware was trying to convey to the user
      when you override the LED state, without any chance to restore it.
      
      Restrict access to all LEDs that can convey important alarms, or that
      could mislead the user into incorrectly operating the hardware.  This
      will make the Lenovo engineers less unhappy about the whole issue.
      
      Allow users that really want it to still control all LEDs, it is the
      unaware user that we have to worry about.
      Signed-off-by: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      a4d5effc
    • Matthew Garrett's avatar
      dell-wmi: new driver for hotkey control · 0b3f6109
      Matthew Garrett authored
      Add a WMI driver for Dell laptops. Currently it does nothing but send a
      generic input event when a button with a picture of a battery on it is
      pressed, but maybe other uses will appear over time.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      0b3f6109
  18. 03 Apr, 2009 1 commit
  19. 16 Mar, 2009 4 commits
  20. 18 Feb, 2009 2 commits
    • Randy Dunlap's avatar
      x86: dell-laptop: depends on POWER_SUPPLY · 310d8c93
      Randy Dunlap authored
      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: default avatarRandy 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      310d8c93
    • Alexey Dobriyan's avatar
      eeepc: should depend on INPUT · 3a5093ee
      Alexey Dobriyan authored
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a5093ee
  21. 20 Jan, 2009 1 commit
  22. 16 Jan, 2009 1 commit
  23. 15 Jan, 2009 1 commit
  24. 19 Dec, 2008 3 commits