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>

This fixes a warning when the module is unloaded on machines without SPIC.

------------[ cut here ]------------
WARNING: at drivers/base/driver.c:261 driver_unregister+0x6e/0x80()
Hardware name: OEM
Unexpected driver unregister!
Modules linked in: sony_laptop(-) rfkill af_packet i915
 drm i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect binfmt_misc
 ipv6 kvm_intel kvm acpi_cpufreq cpufreq_userspace cpufreq_powersave
 cpufreq_stats acpi_pad ac video output battery pci_slot sbs sbshc
 container iptable_filter ip_tables x_tables ext2 fuse
 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss
 snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event
 snd_seq snd_timer snd_seq_device snd fan sg serio_raw sr_mod cdrom
 soundcore button thermal processor thermal_sys floppy snd_page_alloc
 pcspkr intel_agp evdev [last unloaded: asus_atk0110]
Pid: 8136, comm: modprobe Not tainted 2.6.31-rc8debug #50
Call Trace:
[<ffffffff8121ec7e>] ? driver_unregister+0x6e/0x80
[<ffffffff81047577>] warn_slowpath_common+0x87/0xb0
[<ffffffff81047624>] warn_slowpath_fmt+0x64/0x70
[<ffffffff8119a360>] ? kobject_release+0x0/0x1f0
[<ffffffff8119a267>] ? kobject_put+0x27/0x60
[<ffffffff8121d346>] ? bus_put+0x16/0x20
[<ffffffff8121d406>] ? bus_remove_driver+0xb6/0xf0
[<ffffffff8121ec7e>] driver_unregister+0x6e/0x80
[<ffffffff811cab50>] acpi_bus_unregister_driver+0x10/0x12
[<ffffffffa035e86c>] sony_laptop_exit+0x2c/0x2e [sony_laptop]
[<ffffffff8107ddc6>] sys_delete_module+0x176/0x230
[<ffffffff8107186d>] ? trace_hardirqs_on_caller+0x14d/0x1a0
[<ffffffff81350a04>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8100bdab>] system_call_fastpath+0x16/0x1b
---[ end trace f638b6a59b19703e ]---
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

This is unnecessary as OSPM is supposed to call the method already when
the device is discovered.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

The SPIC irq is not really shareable, the IO port cannot be cleared and
always returns some data so there is no real way to understand if the irq
is for us or not. Moreover the _PRS acpi method says the irq is not
shareable.
In addition to this, in some cases, an additional write to the IO port has
to be performed in order to properly decode the event received from the
device. This generates another interrupt which may overlap with the
previous one. In the future this is going to be important for properly
decoding events.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Having separate drivers for SPIC showed to be useless, only type3 has a
slightly different behaviour than the others and there seem to be no real
conflict between them.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix this problem when CONFIG_THINKPAD_ACPI_HOTKEY_POLL is undefined:

  CHECK   drivers/platform/x86/thinkpad_acpi.c
drivers/platform/x86/thinkpad_acpi.c:1968:21: error: not an lvalue
  CC [M]  drivers/platform/x86/thinkpad_acpi.o
drivers/platform/x86/thinkpad_acpi.c: In function 'tpacpi_hotkey_driver_mask_set':
drivers/platform/x86/thinkpad_acpi.c:1968: error: lvalue required as left operand of assignment
Reported-by: NNoah Dain <noahdain@gmail.com>
Reported-by: NAudrius Kazukauskas <audrius@neutrino.lt>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Trigger a status update when the user hits a brightness key, allowing
userspace to present appropriate UI.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Reduce the number of magic numbers in the driver... note that they
were all explained and documented already.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add an internal API to the driver, to allow subdrivers to request and
receive HKEY 0x1000 events.  This API will be used by the backlight
(brightness up/down) and upcoming ALSA mixer (volume up/down/mute)
subdrivers.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Update the HKEY event driver to:

1. Handle better the second-gen firmware, which has no HKEY mask
   support but does report FN+F3, FN+F4 and FN+F12 without the need
   for NVRAM polling.

   a) always make the mask-related attributes available in sysfs;
   b) use DMI quirks to detect the second-gen firmware;
   c) properly report that FN+F3, FN+F4 and FN+F12 are enabled,
      and available even on mask-less second-gen firmware;

2. Decouple the issuing of hotkey events towards userspace from
   their reception from the firmware.  ALSA mixer and brightness
   event reporting support will need this feature.

3. Clean up the mess in the hotkey driver a great deal.  It is
   still very convoluted, and wants a full refactoring into a
   proper event API interface, but that is not going to happen
   today.

4. Fully reset firmware interface on resume (restore hotkey
   mask and status).

5. Stop losing polled events for no good reason when changing the
   mask and poll frequencies.  We will still lose them when the
   hotkey_source_mask is changed, as well as any that happened
   between driver suspend and driver resume.

The hotkey subdriver now has the notion of user-space-visible hotkey
event mask, as well as of the set of "hotkey" events the driver needs
(because brightness/volume change reports are not just keypress
reports in most ThinkPad models).

With this rewrite, the ABI level is bumped to 0x020500 should
userspace need to know it is dealing with the updated hotkey
subdriver.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

HKEY event 0x5010 is useless to us: old ThinkPads don't issue it.  Newer
ThinkPads won't issue it anymore.  And all ThinkPads issue 0x1010 and
0x1011 events.

Just silently drop it instead of sending it to userspace.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>