- 20 Mar, 2012 39 commits
-
-
Mika Westerberg authored
Intel MSIC MFD driver provides common register access interface to the devices in the MSIC die so we use that instead of SCU IPC. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com>
-
Mika Westerberg authored
In newer boards this device is called "msic_thermal" instead of "msic_sensor". To support both we add suitable alias for the driver. Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
Corentin Chary <corentin.chary@gmail.com> Signed-off-by:
-
Corentin Chary authored
asus_acpi only support old models, it has been deprecated since 2009 in favor of asus-laptop, it's not built by any (sane) distro, so it is time to say good bye. Thanks to Julien Lerouge and Karol Kozimor for the work they have done on it, I would never have wrote asus-laptop and other asus related drivers without asus_acpi. Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
But don't try to do than on pegatron tablets to avoid any conflict. Signed-off-by:
-
Corentin Chary authored
Let the user tells if BLED and WLED should be exposed as led or rfkill (the old sysfs are still here, but this adds a standard interface to control the device). For example on my A6JC, with WAPF=1, I would do: $ modprobe asus-laptop wled_type=led bluetooth_type=rfkill There is still no known way to automatically guess what BLED and WLED methods will control, it's why user information is needed. A userspace database could do that automatically, and maybe some DMI matching in the driver. Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Joe Perches authored
Use pr_warn not pr_warning. Coalesce formats. Argument aligning. Remove superfluous parentheses. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Signed-off-by:
-
Joe Perches authored
Use pr_warn not pr_warning. Coalesce formats. Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Corentin Chary authored
- don't output error when probing features at load - print the SABI signature if samsung_sabi_init() succeed Signed-off-by:
-
Corentin Chary authored
We still need to figure out exactly what each of different fields represent, but they contain at least model and version informations. Signed-off-by:
-
Corentin Chary authored
This enable the driver for everything that look like a laptop and is from vendor "SAMSUNG ELECTRONICS CO., LTD.". Note that laptop supported by samsung-q10 seem to have a different vendor strict. Also remove every log output until we know that we have a SABI interface (except if the driver is forced to load, or debug is enabled). Keeping a whitelist of laptop with a model granularity is something that can't work without close vendor cooperation (and we don't have that). Signed-off-by:
-
Corentin Chary authored
The wireless status get and get commands seems to use one byte per device. First byte is for wlan and third is for bluetooh, we will have to find what the other are for. Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
Signed-off-by:
-
Corentin Chary authored
We can now do the self test using debugfs, so remove the code and keep the debug flag to enable more traces. Signed-off-by:
-
Corentin Chary authored
This allow to call arbitrary sabi commands wihout modifying the driver at all. For example, setting the keyboard backlight brightness to 5 using debugfs interface can be done like that: ; Set the command echo 0x78 > command ; Set the data echo 0x0582 > d0 ; Fill the rest with 0 echo 0 > d1 echo 0 > d2 echo 0 > d3 ; And issue the command cat call Signed-off-by:
-
Corentin Chary authored
* SABI command are on 16 bits, not 8 * SABI can read/write up to 11 byte of data * There is not real difference between "get" and "set" commands, so refactorise the code of both functions Signed-off-by:
-
Corentin Chary authored
Will be usefull later when we will have more platform sysfs files like battery_life_extender or usb_charge. Signed-off-by:
-
Corentin Chary authored
samsung-laptop is not at all related to ACPI, but since this interface is not documented at all, and the driver has to use it at load to understand how it works on the laptop, I think it's a good idea to disable it if a better solution is available. Signed-off-by:
-
Corentin Chary authored
Create _init()/_exit() function for each subsystem, remove the local struct samsung_laptop * and only keep a struct platform_device * that can only be used in samsung_init() and samsung_exit(). Signed-off-by:
-
Corentin Chary authored
Even if this driver can only be loaded once, it is still a good idea to create some kind of context structure. Signed-off-by:
-
Axel Lin authored
This patch converts the drivers in drivers/platform/x86/* to use the module_platform_driver() macro which makes the code smaller and a bit simpler. Cc: Hong Liu <hong.liu@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Daniel Drake <dsd@laptop.org> Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
Borislav Petkov authored
Turn off the following triggered with gcc 4.6.1 on Debian testing: drivers/platform/x86/hdaps.c: In function ‘hdaps_temp2_show’: drivers/platform/x86/hdaps.c:398:16: warning: ‘temp’ may be used uninitialized in this function [-Wuninitialized] drivers/platform/x86/hdaps.c: In function ‘hdaps_temp1_show’: drivers/platform/x86/hdaps.c:385:16: warning: ‘temp’ may be used uninitialized in this function [-Wuninitialized] Cc: Frank Seidel <frank@f-seidel.de> Cc: Matthew Garrett <mjg@redhat.com> Cc: platform-driver-x86@vger.kernel.org Signed-off-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
AceLan Kao authored
Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work. Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
-
John Hughes authored
Fix scancodes returned by driver to match scancodes used to remap keys. (Before the patch FN/E returned scancode 0x1B, but to remap scancode 0x14 had to be used). The scancodes returned by the sony-laptop driver for function keys did not match the scancodes used to remap keys. Also, since the scancode was sent to the input subsystem after the mapped keysym the /lib/udev/keymap utility was confused about which scancode to report for which keysym. This patch fixes the driver so the correct scancode is shown for each key. It also adds to the documentation a description of where to find the scancodes. Signed-off-by:
John Hughes <john@calva.com> Acked-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Alan Cox authored
All the production devices use the PC compatible version of this device so don't use the SCU interfaces or the SCU firmware interfaces. Delete lots of code and conditional paths Signed-off-by:
-
Dmitry Torokhov authored
Use MODULE_DEVCE_TABLE instead of rolling MODULE_ALIAS by hand. Signed-off-by:
-
Dmitry Torokhov authored
Use MODULE_DEVCE_TABLE instead of rolling MODULE_ALIAS by hand. Signed-off-by:
-
Dmitry Torokhov authored
Use MODULE_DEVCE_TABLE instead of rolling MODULE_ALIAS by hand. Signed-off-by:
-
Marcos Paulo de Souza authored
Signed-off-by:
Marcos Paulo de Souza <marcos.mage@gmail.com> Signed-off-by:
-
Josh Boyer authored
When the keyboard backlight support was originally added, the commit said to default it to on with a 10 second timeout. That actually wasn't the case, as the default value is commented out for the kbd_backlight parameter. Because it is a static variable, it gets set to 0 by default without some other form of initialization. However, it seems the function to set the value wasn't actually called immediately, so whatever state the keyboard was in initially would remain. Then commit df410d52 was introduced during the 2.6.39 timeframe to immediately set whatever value was present (as well as attempt to restore/reset the state on module removal or resume). That seems to have now forced the light off immediately when the module is loaded unless the option kbd_backlight=1 is specified. Let's enable it by default again (for the first time). This should solve https://bugzilla.redhat.com/show_bug.cgi?id=728478Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Acked-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
-
- 18 Mar, 2012 1 commit
-
-
Linus Torvalds authored
-
