Intel Core i3/5 platforms with integrated graphics support both CPU and
GPU turbo mode.  CPU turbo mode is opportunistic: the CPU will use any
available power to increase core frequencies if thermal headroom is
available.  The GPU side is more manual however; the graphics driver
must monitor GPU power and temperature and coordinate with a core
thermal driver to take advantage of available thermal and power headroom
in the package.

The intelligent power sharing (IPS) driver is intended to coordinate
this activity by monitoring MCP (multi-chip package) temperature and
power, allowing the CPU and/or GPU to increase their power consumption,
and thus performance, when possible.  The goal is to maximize
performance within a given platform's TDP (thermal design point).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

msi-laptop uses i8042_*() interfaces, so it should depend on
SERIO_I8042.  E.g., when SERIO_I8042=m and MSI_LAPTOP=y:

msi-laptop.c:(.text+0x18a7fe): undefined reference to `i8042_install_filter'
msi-laptop.c:(.init.text+0xd69d): undefined reference to `i8042_remove_filter'
msi-laptop.c:(.exit.text+0x19c3): undefined reference to `i8042_remove_filter'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>

Randy Dunlap has reported that building classmate-laptop fails when
CONFIG_RFKILL=m and CONFIG_ACPI_CMPC=y. He suggested depending on
RFKILL, but, then, it will not be possible to select classmate-laptop
when RFKILL is off. There's no known problem with building and using
classmate-laptop with RFKILL off. So depend on RFKILL or RFKILL=n.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: platform-driver-x86@vger.kernel.org
Cc: Daniel Oliveira Nascimento <don@syst.com.br>

Give different error messages if device_enum is NULL or if its type field
has the wrong value.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
expression E,E1;
identifier f;
statement S1,S2,S3;
@@

if ((E == NULL && ...) || ...)
{
  ... when != if (...) S1 else S2
      when != E = E1
* E->f
  ... when any
  return ...;
}
else S3
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

- Improve error handling, by explictly return zero for success, error otherwise
- WMI query command can have arbitrary input sized params
- WMI query command can have specific output sized params (0, 4, 128,..) byte

I like to go on here, but this is a rather intrusive change that should
be looked at first. I am sure the one or other thing can be done better or
there might be typo/bug somewhere.

This did not get any testing yet, only compile tested.

Next steps could be:
  - Eventually introduce hp_wmi_perform_{read,write}_query macros
  - Introduce new wireless query interface (0x1B)
  - more
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

Depending on ACPI version (1.0 -> 32 bit) an integer could be
32 or 64 bit long. _WED internal concatenates two integers and
the return value will be 8 byte (2* 32 bit) or 16 byte (2* 64 bit)
long, depending on the ACPI version.

Also the data send with the WMI event is defined to be splitted into:
  - Event ID -> 4 bytes
  - Event Data -> 4 bytes

This gets messed up with new ACPI versions.
But it's a HP BIOS bug that may get fixed in the future
-> Support both, 16 and 8 byte _WED buffers.

Also the wrong assumption that from the event data sent, only the
first byte is relevant got cleaned up that it fits event_id/event_data
as described above.
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: robert.moore@intel.com
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: platform-driver-x86@vger.kernel.org
CC: linux-acpi@vger.kernel.org

Rather than print unknown events when we know what caused them
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

Event id 0x4 defines the hotkey event.
No need (or even wrong) to query HPWMI_HOTKEY_QUERY if event id is != 0x4.

Reorder the eventcode conditionals and use switch case instead of if/else.
Use an enum for the event ids cases.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org

This patch includes below fixes in error path:
1. fix a memory leak if device_create_file failed in
intel_menlow_add_one_attribute
2. properly free added attributes before return error in
intel_menlow_register_sensor error handler
3. properly call acpi_bus_unregister_driver before return error in
intel_menlow_module_init
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

- fix reversing of command/sub arguments
- fix a crash if the i2c interface is called before the device is found
Signed-off-by: NSreedhara DS <sreedhara.ds@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commands with data must set the length in the message.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Found the N014, N051 and CR620 are must the same with N034 there are
load scm serial model. So, this patch move N014, N051 and CR620 dmi
information to right dmi table: msi_load_scm_models_dmi_table[]
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>

drivers/platform/x86/eeepc-wmi.c: In function ‘eeepc_wmi_notify’:
drivers/platform/x86/eeepc-wmi.c:209: warning: ‘new’ may be used uninitialized in this function
drivers/platform/x86/eeepc-wmi.c:209: note: ‘new’ was declared here
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Yong Wang <yong.y.wang@intel.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Tejun Heo <tj@kernel.org>
Cc: platform-driver-x86@vger.kernel.org
Acked-By: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: platform-driver-x86@vger.kernel.org
CC: mjg59@srcf.ucam.org
CC: corentin.chary@gmail.com
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Output in log with debug=1:
ACPI: WMI: DEBUG Event INTEGER_TYPE - 65535
ACPI: WMI: DEBUG Event GUID: CC1A61AC-4256-41A3-B9E0-05A445ADE2F5
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: platform-driver-x86@vger.kernel.org
CC: mjg59@srcf.ucam.org
CC: corentin.chary@gmail.com
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

To give people easily an idea what could be WMI driven on their system.
Introduces:
wmi.debug=[01]

Tested on an acer:
ACPI: WMI: DEBUG Event INTEGER_TYPE - 65535

Situation where a driver registers for specific event and debug
handler gets overridden and set again if the registering driver gets
unloaded again is untested, but should work.
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: platform-driver-x86@vger.kernel.org
CC: mjg59@srcf.ucam.org
CC: corentin.chary@gmail.com
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Clean up i8042 filter, rfkill and cancel delayed work when msi-laptop driver initial fail or exit on MSI scm model.
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>

Cc: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There have some MSI netbook change devices state by EC when user press
wlan/bluetooth/wwan function keys. So, add a i8042 filter to sync sw
state with BIOS when function keys pressed.
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Setup Wlan/Bluetooth/3G rfkill initial state to sync with the hardware
state from EC 0x2e address.
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add new MSI notebook CR620 dmi information to scm models table.
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add new MSI netbook N014 and N051 dmi information to scm models table.
Signed-off-by: NLee, Chun-Yi <jlee@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use kmemdup when some other buffer is immediately copied into the
allocated region.

A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression from,to,size,flag;
statement S;
@@

-  to = \(kmalloc\|kzalloc\)(size,flag);
+  to = kmemdup(from,size,flag);
   if (to==NULL || ...) S
-  memcpy(to, from, size);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>

Use kzalloc rather than the combination of kmalloc and memset.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,size,flags;
statement S;
@@

-x = kmalloc(size,flags);
+x = kzalloc(size,flags);
 if (x == NULL) S
-memset(x, 0, size);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>

Make it clear that this driver is only needed for embedded hardware,
not PCs.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

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>
Cc: stable@kernel.org

The IPC (inter processor communications) is used to provide the
communications between kernel and system control units on some embedded
Intel x86 platforms.

(Various bits of clean up and restructuring by Alan Cox)
Signed-off-by: NSreedhara DS <sreedhara.ds@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>

The RFKILL device shares the same ACPI device used for backlight. So, it
required a new struct sharing both a backlight_device and a rfkill
device.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>

Document this, it is no fun to try to second guess why this sort of
stuff is in place years after it was added...
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

1. Remove <handle>_path, as its only user was already removed in
   a previous commit

2. Move all handle initialization, as well as <handle>_parent and
   <handle>_paths to __init.* sections.  This reduces the driver's
   runtime footprint nicely.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Don't depend on the contents of led_path to know which LED interface
the firmware wants.

This removes the only user of *_path for the thinkpad-acpi ACPI
handlers, which will simplify future code.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Log more human-friendly errors instead of numeric values when
setup_acpi_notify() fails to install a notification handler.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Use acpi_format_exception() in acpi_evalf() instead of logging numeric
errors.

Also, when ACPICA returns an error, we should not be touching the return
object, as it is invalid.  In debug mode, acpi_evalf() callers would
printk the returned crap (but fortunately, not use it).
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Use the EC HID (PNP0C09) to locate its main node, instead of a static
list.
Suggested-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg@redhat.com>

Disclose the user task doing ALSA access when requested by
the debug bitmask.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Handle multiple brightness hotkey presses between two polling cycles.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Extract the backlight level range size detection from the brightness
subdriver, and allow the other subdrivers access to that information.

This also allows us to relocate some code to a more convenient place.
The moved code was largerly unmodified, except for the return type of
tpacpi_check_std_acpi_brightness_support(), which now is correctly
marked as returning "unsigned int", and and two cosmetic fixes to make
checkpatch.pl happy.

Fixes for the NVRAM polling mode for the brightness hotkeys will need
this.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>