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: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: coding style: fix indentation

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: coding style: add curly braces around else compound

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: coding style: add curly braces around else compound

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: return -ENXIO if acpi getter or setter fails

get_acpi(), set_acpi() and acpi_setter_handle() return -ENODEV on error.
However, of the available options, ENXIO seems more appropriate, since
we're dealing with both devices and addresses here:

	#define EIO              5      /* I/O error */
	#define ENXIO            6      /* No such device or address */
	#define ENODEV          19      /* No such device */

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: use symbolic permissions in device attributes

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: use DEVICE_ATTR to instantiate device_attributes

Signed-off-by: Frans Klaver <fransklaver@gmail.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>
eeepc-laptop: make disp attribute really 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 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 of course leaves no
reason to override actual errors produced in store_sys_acpi() and
show_sys_acpi() anymore.

Signed-off-by: Frans Klaver <fransklaver@gmail.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>
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.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
eeepc-laptop: compare 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>
eeepc-laptop: propagate errors from get_cpufv

In show_available_cpufv, show_cpufv, and store_cpufv, errors from
get_cpufv are mapped to -ENODEV. To paint a clear picture to callers,
propagate the errors instead.

Signed-off-by: Frans Klaver <fransklaver@gmail.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.

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