linux/drivers/platform, branch v2.6.38

dell-laptop: Toggle the unsupported hardware killswitch

2011-02-21T22:06:21Z

It is found on Dell Inspiron 1018 that the firmware reports that the hardware killswitch is not supported. This makes the rfkill key not functional. This patch forces the driver to toggle the firmware rfkill status in the case that the hardware killswitch is indicated as unsupported by the firmware. Signed-off-by: Keng-Yu Lin Tested-by: Alessio Igor Bogani Signed-off-by: Matthew Garrett

thinkpad_acpi: Always report scancodes for hotkeys

2011-02-21T22:06:20Z

Some thinkpad hotkeys report key codes like KEY_FN_F8 when something like KEY_VOLUMEDOWN is desired. Always provide the scan codes in addition to the key codes to assist with debugging these issues. Also send the scan code before the key code to match what other drivers do, as some userspace utilities expect this ordering. Signed-off-by: Seth Forshee Signed-off-by: Matthew Garrett

acer-wmi: Fix capitalisation of GUID

2011-02-21T22:06:18Z

6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 needs to be 6AF4F258-B401-42FD-BE91-3D4AC2D7C0D3 to match the hardware alias. Signed-off-by: Matthew Garrett Acked-by: Carlos Corbacho Cc: stable@kernel.org

platform/x86: ideapad-laptop depends on INPUT

2011-02-21T22:06:17Z

Most platform/x86 drivers that use INPUT_SPARSEKMAP also depend on INPUT, so do the same for ideapad-laptop. This fixes a kconfig warning and subsequent build errors when CONFIG_INPUT is disabled. warning: (ACER_WMI && ASUS_LAPTOP && DELL_WMI && HP_WMI && PANASONIC_LAPTOP && IDEAPAD_LAPTOP && EEEPC_LAPTOP && EEEPC_WMI && MSI_WMI && TOPSTAR_LAPTOP && ACPI_TOSHIBA) selects INPUT_SPARSEKMAP which has unmet direct dependencies (!S390 && INPUT) ERROR: "input_free_device" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "input_register_device" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "sparse_keymap_setup" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "input_allocate_device" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "input_unregister_device" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "sparse_keymap_free" [drivers/platform/x86/ideapad-laptop.ko] undefined! ERROR: "sparse_keymap_report_event" [drivers/platform/x86/ideapad-laptop.ko] undefined! Signed-off-by: Randy Dunlap Cc: David Woodhouse Cc: Matthew Garrett Cc: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett

platform: x86: acer-wmi: world-writable sysfs threeg file

2011-02-21T22:06:15Z

Don't allow everybody to write to hardware registers. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett

platform: x86: asus_acpi: world-writable procfs files

2011-02-21T22:06:14Z

Don't allow everybody to change ACPI settings. The comment says that it is done deliberatelly, however, the comment before disp_proc_write() says that at least one of these setting is experimental. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett

platform: x86: tc1100-wmi: world-writable sysfs wireless and jogdial files

2011-02-21T22:06:13Z

Don't allow everybody to change WMI settings. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett

platform-drivers: x86: pmic: Use request_irq instead of chained handler

2011-02-21T22:06:11Z

There is no need to install a chained handler for this hardware. This is a plain x86 IOAPIC interrupt which is handled by the core code perfectly fine. There is nothing special about demultiplexing these gpio interrupts which justifies a custom hack. Replace it by a plain old interrupt handler installed with request_irq. That makes the code agnostic about the underlying primary interrupt hardware. The overhead for this is minimal, but it gives us the advantage of accounting, balancing and to detect interrupt storms. gpio interrupts are not really that performance critical. Patch fixups from akpm Signed-off-by: Thomas Gleixner Signed-off-by: Matthew Garrett Signed-off-by: Andrew Morton

platform-drivers: x86: pmic: Use irq_chip buslock mechanism

2011-02-07T21:52:28Z

The set_type function of the pmic irq chip is a horrible hack. It schedules work because it cannot access the scu chip from the set_type function. That breaks the assumption, that the type is set after set_type has returned. irq_chips provide buslock functions to avoid the above. Convert the driver to use the proper model. Signed-off-by: Thomas Gleixner Cc: Feng Tang Cc: Matthew Garrett Cc: Alan Cox Cc: Alek Du Signed-off-by: Matthew Garrett

platform-drivers: x86: Convert pmic to new irq_chip functions

2011-02-07T21:52:22Z

Old functions will go away soon. Remove the stray semicolons while at it. Signed-off-by: Thomas Gleixner Cc: Feng Tang Cc: Matthew Garrett Cc: Alan Cox Cc: Alek Du Signed-off-by: Matthew Garrett