fix styles problems introduced by commit
e86bda235a08b6a8e64c1e8bb9d175f6961554e3
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Lenovo SL series laptop has a very similar DSDT with Asus laptops. We can
easily have the extra ACPI function support with little modification in
asus-laptop.c

Here is the hotkey enablement for Lenovo SL series laptop.

This patch will enable the following hotkey:
 - Volumn Up
 - Volumn Down
 - Mute
 - Screen Lock (Fn+F2)
 - Battery Status (Fn+F3)
 - WLAN switch (Fn+F5)
 - Video output switch (Fn+F7)
 - Touchpad switch (Fn+F8)
 - Screen Magnifier (Fn+Space)

The following function of Lenovo SL laptop is still need to be enabled:
 - Hotkey: KEY_SUSPEND (Fn+F4), KEY_SLEEP (Fn+F12), Dock Eject (Fn+F9)
 - Rfkill for bluetooth and wlan
 - LenovoCare LED
 - Hwmon for fan speed
 - Fingerprint scanner
 - Active Protection System
Signed-off-by: NIke Panhc <ike.pan@canonical.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The same key is used in toshiba-laptop, and there is no
reserved key for that.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Callback methods should not refer to a variable like "eeepc" (formally
"ehotk").  Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on.  The "eeepc" variable can then be removed.

In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them.  However this makes it harder to review them for
correctness.  This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).

This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).

The hwmon sub-device is a special case.  It uses ec_{read,write} which
are defined to communicate with the (first) EC, so it does not require
any driver data.  It should still only be instantiated in the context of
an ASUS010 device because we don't have a safe way to probe for it.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

eeepc-laptop now does a lot more than just hotkeys.  Replace the "hotk"
names used throughout the driver with some slightly more appropriate
names.  The actual strings used in kernel messages and sysfs are left
unchanged.

e.g.
	EEEPC_HOTK_FILE  -> EEEPC_LAPTOP_FILE
	EEEPC_HOTK_HID   -> EEEPC_ACPI_HID

	eeepc_hotk_notify -> eeepc_acpi_notify
	struct eeepc_hotk -> struct eeepc_laptop
	ehotk             -> eeepc

I'm about to refactor the entire driver to remove the global "ehotk"
variable, and I don't wish to add "struct eeepc_hotk *ehotk" to
functions which have nothing to do with hotkeys.

Also
 - fix the name of "eepc_get_entry_by_keycode()"
 - remove the unused definition of NOTIFY_WLAN_ON.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Move e.g. backlight_init() and backlight_exit() together along with the
other backlight functions, instead of grouping init() and exit()
functions.  Move e.g. backlight_ops to follow the functions it refers
to, and remove the forward declarations.  The code itself should remain
unchanged.

The eeepc-laptop driver implements a number of interfaces like the
backlight class driver.  This change makes it easier to examine the
implementation of one interface at at a time, without having to search
through the file to find init() and exit() functions etc.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

This moves the sysfs_create_group() call just after the declaration of
the platform device attributes.  It should make it easier to examine
the implementation of the platform device attributes in isolation
from the rest of the code.  (The next commit will apply this pattern
to all of the sub-devices as well).

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk
Signed-off-by: NLen Brown <len.brown@intel.com>

Strictly speaking we should register the platform driver exactly once,
whether there are zero, one, or multiple matching acpi devices.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Separate out input_notify(), in a similar way to how notify_brn()
is already separated.  This will allow all the functions which refer to
the input device to be grouped together.

This includes a small behaviour change - we now synthesize brightness
up/down key events even if the brightness is already at the
maximum/minimum value.  This is consistent with the new uevent
interface.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The hwmon device uses ec_write() to write values to the EC.  So for
consistency it should use ec_read() to read values.  The extra layers
of indirection used did not add any value.

This may mean we no longer take the ACPI global lock for such reads
(if the EC operation region requires the lock and the EC does not).
But there is no point locking each one-byte read individually, when
write operations do not use the lock at all.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

We don't need to store init_flags after using them.  And we don't use
the result of INIT, so we don't need to allocate a buffer for it.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

We already tell the backlight class our maximum brightness value; it
will validate the user requested values for us.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL.
We check both variables for allocation failure and would bail out before
the notifier is registered.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

If the control method does not exist, return -ENODEV for consistency
with get_acpi()
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

If we bail out because we can't create the led class device, we need to
ensure the led workqueue is cleaned up.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Create the workqueue thread used by tpd_led_set() *before* we register
the led device.  (And vice versa for unregistration).
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Documentation/hwmon/sysfs-interface tells us that automatic fan speed
control should be represented by a value of 2 or above for pwm1_enable.
Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control.

Setting "1" for manual control is already consistent with the
documentation, so this remains unchanged.

Let's preserve the ABI for this specific driver, so that writing "0"
will still invoke automatic control.

(The documentation says setting "0" should leave the fan at full speed
all the time.  This mode is not directly supported by our hardware. Full
speed is rather noisy on my 701 and the automatic control has never used
it.  If you really want this e.g. to prolong the life of an EeePC used
as a server, you can always use manual mode.  hwmon has always been
fairly machine-specific, and you're in a tiny minority (or elite :-).
I'm sure you're smart enough to notice that the fan doesn't turn on to
full speed when you try this mode, either by ear or checking
fan_input1.

We could even claim to be honouring the spirit of the documentation.
"0" really means "safe mode".  EeePCs default to automatic mode, ie that
is what Asus will actually test.  Since we do not provide any way to
tamper with the temperature threshold, automatic mode _is_ the safe
option).
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

This led can be found on Eeepc 1005 series.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently, reading from the disp attribute fails with "No such device",
which is misleading. According to CMSG table on acpi4asus project site,
no models have a getter method corresponding to SDSP. Change the file
permission to disallow reads.

If some joker changes the permission to permit reads, then return -EIO
to be consistent with sysfs' behaviour when no show() method is
provided.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Return temperature in milidegree instead of degree, as sysfs-api requires
the temperature in milidegree.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Tested-by: NBorislav Petkov <petkovbb@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is a problem in the quirk tables used by tpacpi_is_fw_known() and
tpacpi_check_outdated_fw(), which causes outdated BIOSes that are lacking
the EC firmware ID DMI field to never match.

This breaks module loading on, e.g.  a T23 with outdated BIOS, and the
module will refuse to load unless the "force_load=1" parameter is given.

Fix the quirk tables so that they can also match the outdated BIOSes,
which in turn will both fix the module loading, and also warn the user
that he is using outdated firmware and should upgrade.

This fixes a serious regression, introduced by commit
e675abaf, "thinkpad-acpi: be more strict
when detecting a ThinkPad".

http://bugzilla.kernel.org/show_bug.cgi?id=14597Reported-by: NPaul Kimoto <kimoto@lightlink.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NPaul Kimoto <kimoto@lightlink.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The returned error should be negative
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Switching the camera takes 500ms, checking if it's on is almost free...
The BIOS remembers the setting through reboots, so there's good chance the
camera is already enabled.
Signed-off-by: NLuca Niccoli <lultimouomo@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

rt2860sta is fine with the patch as is, but iwl3945 isn't
(eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means
that we're back to causing the rt2860sta panic

This reverts commit b56ab33d.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

This works around what I think is actually a bug in rt2860sta which is
triggered when the hardware "disappears" from beneath the driver, i.e. when
wireless is toggled off via ACPI. It does so by ensuring that the rfkill
soft-block flag is set before the hardware is disabled.

I do not know whether this patch is required if rt2800pci is in use instead
of rt2860sta; at the time of submission of this patch, I've not been able to
test this.

(Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390)
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently the annotation for function eeepc_enable_camera() is
__init, and refers to a
function eeepc_hotk_add() which is non-init. Use __devinit for both
functions which is
more appropriate and fixes a section mismatch warning.

 We were warned by the following warning:

  LD      drivers/platform/x86/built-in.o
WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section
mismatch in reference from the function eeepc_hotk_add() to the
function .init.text:eeepc_enable_camera()
The function eeepc_hotk_add() references
the function __init eeepc_enable_camera().
This is often because eeepc_hotk_add lacks a __init
annotation or the annotation of eeepc_enable_camera is wrong.
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

A follow-up 2.6.32-rc1's

1e384cb0
"fujitsu-laptop: support led-class as module"

It's a trivial fix for one of the CONFIG_LEDS_CLASS ifdefs
which was somehow missed in the original patch.
Signed-off-by: NJonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: NLen Brown <len.brown@intel.com>

Without this, the hard-blocked state will be reported incorrectly if
the hardware switch is changed while the laptop is suspended.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: NNorbert Preining <preining@logic.at>
Acked-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet)...

After turning off and on again the hard-switch the events were right."

We can fix this by querying the firmware at load time and calling
rfkill_set_hw_state().
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: NNorbert Preining <preining@logic.at>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NMattia Dongili <malattia@linux.it>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>