toshiba_acpi: Additional hotkey scancodes

Appart from reporting hotkeys, the INFO method is used
as a system wide event notifier for hardware or
software changes.

This patch adds additional "events" to the keymap list,
ignored by now, until we find them a good use.

Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
toshiba_acpi: Fix illumination not available on certain models

Some Toshiba models with illumination support set a different
value on the returned codes, thus not allowing the illumination
LED to be registered, where it should be.

This patch removes a check from toshiba_illumination_available
function to allow such models to register the illumination LED.

Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
toshiba_acpi: Change touchpad store to check for invalid values

The function toshiba_touchpad_store is not checking
for invalid values and simply returns silently.

This patch checks for invalid values and returns accordingly.

Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
toshiba_acpi: Support new keyboard backlight type

Newer Toshiba models now come with a new (and different) keyboard
backlight implementation with three modes of operation: TIMER,
ON and OFF, and the LED is now controlled internally by the firmware.

This patch adds support for that type of backlight, changing the
existing code to accomodate the new implementation.

The timeout value range is now 1-60 seconds, and the accepted
modes are now: 1 (FN-Z), 2 (AUTO or TIMER), 8 (ON) and 10 (OFF),
this adds two new entries kbd_type and available_kbd_modes,
the first shows the keyboard type and the latter shows the
supported modes depending on the keyboard type.

Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
x86: thinkpad_acpi.c: fixed spacing coding style issue

Fixed 22 similar coding style issues: "ERROR: spaces required around that '?'"

Signed-off-by: Jan van den Berg <janvdberg@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
intel-rst: Use ACPI_FAILURE() macro instead !ACPI_SUCCESS() for error checking

ACPI_SUCCESS is defined as:
#define ACPI_SUCCESS(a)			(!(a))

There is no need for the the double ! since there is already a macro
defined for failures: ACPI_FAILURE()

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
intel-rst: Clean up ACPI add function

There is no need to initialize the error since it is going to be assigned
with the return status of at least on of the device_create_file() call.

We can return directly in case the first file creation fails.
All the labels for goto can be removed (along with the gotos) as well.
Tell the compiler that the failures are unlikely so it can create better
binaries.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: simplify parse_arg()

parse_arg() has three possible return values:
    -EINVAL if sscanf(), in short, fails;
    zero if "count" is zero; and
    "count" in all other cases

But "count" will never be zero. See, parse_arg() is called by the
various store functions. And the callchain of these functions starts
with sysfs_kf_write(). And that function checks for a zero "count". So
we can stop checking for a zero "count", drop the "count" argument
entirely, and transform parse_arg() into a function that returns zero on
success or a negative error. That, in turn, allows to make those store
functions just return "count" on success. The net effect is that the
code becomes a bit easier to understand.

A nice side effect is that this GCC warning is silenced too:
    drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’:
    drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      int rv, value;

Which is, of course, the reason to have a look at parse_arg().

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: clean up coding style

Correct indentation and brace usage to comply with
Documentation/CodingStyle.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: change sysfs function names to API expectations

The eeepc-laptop driver follows the function naming convention
<action>_<attrname>(), while the sysfs macros are built around the
convention <attrname>_<action>(). Rename the sysfs functions to the
convention used by sysfs. This makes it easier to use the available API
later on.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: use DEVICE_ATTR* to instantiate device_attributes

Device attributes are instantiated manually, while we have DEVICE_ATTR*
macros available to do much of the work for us. Let's use them.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: pull out ACPI_STORE_FUNC and ACPI_SHOW_FUNC macros

Pull out macros EEEPC_ACPI_STORE_FUNC and EEEPC_ACPI_SHOW_FUNC. These
macros define functions that call store_sys_acpi() and show_sys_acpi()
respectively. This helps prevent duplication later on.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: tell sysfs that the disp attribute is write-only

The disp attribute is write-only, but sysfs doesn't know this. Currently
show_sys_acpi() is mimicking sysfs behavior, if the underlying acpi call
should fail. This was introduced in 6dff29b63a5bf2eaf3 "eeepc-laptop:
disp attribute should be write-only". This is not ideal; behaving like
sysfs is better left to sysfs.

Introduce EEEPC_CREATE_DEVICE_ATTR_WO() to instantiate a write-only
attribute, and declare the disp attribute with it. Sysfs makes sure
userspace can only write to disp at all times. This removes the need for
mimicking the sysfs behavior in show_sys_acpi() and store_sys_acpi(),
but we'll stick with -EIO, as changing sysfs return values should not be
taken lightly.

This change also causes EEEPC_CREATE_DEVICE_ATTR() to be used only for
R/W attributes. This enables us to drop the _mode argument from the
macro and use DEVICE_ATTR_RW() internally while we're at it. Append _RW
to the name for readability.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: pull out SENSOR_STORE_FUNC and SENSOR_SHOW_FUNC macros

Pull out EEEPC_SENSOR_STORE_FUNC and EEEPC_SENSOR_SHOW_FUNC. These
macros define functions that call store_sys_hwmon() and show_sys_hwmon()
respectively. This helps prevent duplication later on.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: make fan1_input really read-only

In the instantiation of the fan1_input device attribute, NULL is passed
as set function to store_sys_hwmon. The function pointer is never
checked before dereferencing it. This is fine if we can guarantee that
it will never be called with an invalid pointer, but we can't. If
someone from user space decides to change the permissions on this
attribute and write to it, kernel will crash.

Introduce EEEPC_CREATE_SENSOR_ATTR_RO() to instantiate a read-only
attribute, and declare fan1_input with it. This ensures store_sys_hwmon
is never called with NULL parameters. If someone tries to write the
attribute, the system will at least keep its sanity.

This also causes EEEPC_CREATE_SENSOR_ATTR() to be only used for R/W
attributes.This enables us to drop the _mode argument from the macro
and use DEVICE_ATTR_RW() internally while we're at it. Append _RW to the
name for readability.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: check proper return values in get_cpufv

In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value is checked for errors, it is and'ed with 0xff.
This means c->cur can never be less than zero. Besides that, the actual
error value is ignored.

c->num is also and'ed with 0xff, which means we can ignore values below
zero.

Check the result of get_acpi() right away. While at it, propagate the
error if we got one.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: store_cpufv: return error if set_acpi fails

The result of set_acpi is left unchecked, but it may return errors. If
one occurs, send the error to the caller. There's no reason to lie about
it, if set_acpi fails.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: clean up control flow in *_rfkill_notifier

Handle errors immediately in eeepc_register_rfkill_notifier and
eeepc_unregister_rfkill_notifier. This clears up the control flow for the
reader. It also removes unnecessary indentation.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
eeepc-laptop: flatten control flow

In eeepc_rfkill_hotplug there's an if statement with a big tail that
ends right before the out_unlock label. We might as well invert the
condition and jump to out_unlock in that case. This removes an
indentation level for a large chunk of code.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: don't break user visible strings

As per Documentation/CodingStyle ch. 2, it is preferred that we don't
break user visible strings, in order to allow users to grep for them.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>