Refactor and organize the code a bit for the NVRAM polling support:

1. Split hotkey_get/set into hotkey_status_get/set and hotkey_mask_get/set;
2. Cache the status of hot key mask for later driver use;
3. Make sure the cache of hot key mask is refreshed when needed;
4. log a printk notice when the firmware doesn't set the hot key
   mask to exactly what we asked it to;
5. Add proper locking to the data structures.

Only (4) should be user-noticeable, but there is a chance (5) fixes
some unknown/unreported race conditions.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Publish the requirements for keymap changes.  This is a documentation
change, only.

Currently, people look at the thinkpad-acpi default keymaps, and think:
"modifying this is a trivial thing, it can't break systems, and there are
keys defined for foo and bar, but the driver has them as KEY_RESERVED.
Must have been an oversight, let me change it."

And since they never get to see the bug reports, because they are not
really a part of the Linux ThinkPad users community (linux-thinkpad
mailinglist, thinkwiki wiki, thinkpad forums) and laptop users are slow
to complain to distros about any breakages...
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Starting in 2.6.23...

Several reports from X60 users complained that the default Lenovo keymap
issuing EV_KEY KEY_BRIGHTNESS_UP/DOWN input events caused major issues when
the proper brightness support through ACPI video.c was loaded.

Therefore, remove the generation of these events by default, which is the
right thing for T60, X60, R60, T61, X61 and R61 with their latest BIOSes.

Distros that want to misuse these events into OSD reporting (which requires
an ugly hack from hell in HAL) are welcome to set up the key map they need
through HAL.  That way, we don't break everyone else's systems.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

set_ibm_param() could OOPS with a NULL pointer derreference if one did not give
any values for a module parameter it handles.  This would, of course, cause all
sort of trouble for future modprobing and require a reboot to clean up
properly.

Fix it by returning -EINVAL if no values are given for the parameter, and also
avoid any nastyness from BUG_ON while at it.

How to reproduce: modprobe thinkpad-acpi brightness
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NMike Kershaw <dragorn@kismetwireless.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The code calling brightness_set() can't handle EINTR/ERESTARTSYS well, nor
is it checking brightness_set() return status properly.

Fix it.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Map an mutex_lock_interruptible() error return into ERESTARTSYS, as the
only possible error from mutex_lock_interruptible is EINTR, and that will
only happen if signal_pending() causes the mutex lock attempt to abort.

This still allows signals to be delivered ASAP, which is much nicer than
just doing mutex_lock, and still shadows userspace from EINTR when
SA_RESTART is active.

Problem reported by Peter Jordan.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Peter Jordan <usernetwork@gmx.info>
Cc: Richard Neill <rn214@hermes.cam.ac.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

The lm-sensors 3.0.0/libsensors4 compatibility changes are reason enough to
bump up the version string.  Do it.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Newer Lenovo BIOSes support the standard ACPI backlight brightness
interface (_BCM, _BQC, _BCL).  It should be used instead of the native
thinkpad backlight brightness control interface when possible.

This patch disables the native brightness support in the driver by default
when we detect that the standard ACPI interface is available.  The local
admin can still enable it using the module parameter "brightness_enable".

Note that we need to detect the standard ACPI backlight interface only in
boxes for which we would load the native backlight interface in the first
place, and that no ThinkPad BIOS has _BCL but misses the other methods, so
the detection routines can be really simple.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add a "brightness_enable" module parameter that allows the local admin to
force the backlight support to not be enabled.

It can also be used to force the backlight support to be enabled, but that
is currently a no-op as the backlight support is enabled by default when
available.  This will be changed by a different patch.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Lenovo ThinkPads often have 16 brightness levels in EC, and not just eight
levels like older ThinkPads.  They also have standard ACPI backlight
brightness control.

We detect the number of brightness levels by the presence of a BCLL package
with 16 entries.  If BCLL is not there, we assume eight levels (Z6*).  If
it is there, but it doesn't have 16 entries, we assume eight levels (T60).
Otherwise we assume sixteen levels (T61, X61, etc).

We don't use _BCL because it can have side-effects in thinkpads.  Thanks to
Thomas Renninger <trenn@suse.de> for notifying me of this potential
problem.

Using the standard ACPI backlight brightness control *instead* of the
native thinkpad backlight control is a better idea, though.  A different
patch will take care of this.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Revert commit fba956c4, "Map volume and
brightness events on thinkpads".

That commit made some modifications to the default keymaps that cause bad
behaviour on all IBM ThinkPads if HAL doesn't know to change them into
passive (on-screen-display only) events.

The proper solution for IBM ThinkPads is to use the _NOTIFY version of the
key codes for the IBM default map (which are not available in mainline
yet), and for the Lenovo keymap, it will take some studying of the various
DSDTs and testing to know the best path (which I will do shortly).

For more data, refer to:
http://thread.gmane.org/gmane.linux.kernel/591037/focus=591045Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Jeremy Katz <katzj@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
Signed-off-by: NJeremy Katz <katzj@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Skip blanks not just at the tail of sysfs writes, but also at the head.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert from class_device to device for hwmon_device_register/unregister
Signed-off-by: NTony Jones <tonyj@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NMark M. Hoffman <mhoffman@lightlink.com>

Three main sets of changes:

1) dmi_get_system_info() return value should have been marked const,
   since callers should not be changing that data.

2) const-ify DMI internals, since DMI firmware tables should,
   whenever possible, be marked const to ensure we never ever write to
   that data area.

3) const-ify DMI API, to enable marking tables const where possible
   in low-level drivers.

And if we're really lucky, this might enable some additional
optimizations on the part of the compiler.

The bulk of the changes are #2 and #3, which are interrelated.  #1 could
have been a separate patch, but it was so small compared to the others,
it was easier to roll it into this changeset.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Thinkpad-acpi has some driver attributes (debug level, sysfs interface
version, etc) that also belong to the new hwmon driver.  Duplicate them
there.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use a separate platform device and driver ("thinkpad_hwmon") to attach
hwmon attributes and class, and add a name attribute of "thinkpad" to
it, which defines the hwmon device name for libsensors4.

This makes thinkpad-acpi compatible with libsensors4 from lm-sensors, and
the platform driver and device split will make it much easier to separate
hwmon functionality into its own module later on.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

We were letting ThinkPad-specific LID events through to userspace again,
instead of dropping them.  Fix it.  We don't want to give userspace the
option of not using generic LID handling.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Receive all pending HKEY events at once from a single notification, and don't
complain if the queue is empty.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Check the HKEY firmware version (HKEY.MHKV handler), and refuse to load if
it is unknown.  Use this instead of the presence of HKEY.DHKV to detect hot
key mask capability.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Keep track of module state (init, running, exit).  This makes it trivially
easy to avoid running any interrupt handlers, threads, or any other async
activity before we are ready, or when we want to go away.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Protect the input device event sending path with a mutex, since hot key
input events are not atomic and require an cohesive event block to be sent
together.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

We were missing a input_sync on the radio switch event report path. Add it.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Name it thinkpad-acpi version 0.16 to avoid any confusion with some 0.15
thinkpad-acpi development snapshots and backports that had input layer
support, but no hotkey_report_mode support.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Revert new 2.6.23 CONFIG_THINKPAD_ACPI_INPUT_ENABLED Kconfig option because
it would create a legacy we don't want to support.

CONFIG_THINKPAD_ACPI_INPUT_ENABLED was added to try to fix an issue that is
now moot with the addition of the netlink ACPI event report interface to
the ACPI core.

Now that ACPI core can send events over netlink, we can use a different
strategy to keep backwards compatibility with older userspace, without the
need for the CONFIG_THINKPAD_ACPI_INPUT_ENABLED games.  And it arrived
before CONFIG_THINKPAD_ACPI_INPUT_ENABLED made it to a stable mainline
kernel, even, which is Good.

This patch is in sync with some changes to thinkpad-acpi backports, that
will keep things sane for userspace across different combinations of kernel
versions, thinkpad-acpi backports (or the lack thereof), and userspace
capabilities:

Unless a module parameter is used, thinkpad-acpi will now behave in such a
way that it will work well (by default) with userspace that still uses only
the old ACPI procfs event interface and doesn't care for thinkpad-acpi
input devices.

It will also always work well with userspace that has been updated to use
both the thinkpad-acpi input devices, and ACPI core netlink event
interface, regardless of any module parameter.

The module parameter was added to allow thinkpad-acpi to work with
userspace that has been partially updated to use thinkpad-acpi input
devices, but not the new ACPI core netlink event interface.  To use this
mode of hot key reporting, one has to specify the hotkey_report_mode=2
module parameter.

The thinkpad-acpi driver exports the value of hotkey_report_mode through
sysfs, as well.  thinkpad-acpi backports to older kernels, that do not
support the new ACPI core netlink interface, have code to allow userspace
to switch hotkey_report_mode at runtime through sysfs.  This capability
will not be provided in mainline thinkpad-acpi as it is not needed there.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Richard Hughes <hughsient@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Schedule /proc/acpi/event for removal in 6 months.

Re-name acpi_bus_generate_event() to acpi_bus_generate_proc_event()
to make sure there is no confusion that it is for /proc/acpi/event only.

Add CONFIG_ACPI_PROC_EVENT to allow removal of /proc/acpi/event.
There is no functional change if CONFIG_ACPI_PROC_EVENT=y
Signed-off-by: NLen Brown <len.brown@intel.com>

The previous events patch added a netlink event for every
user of the legacy /proc/acpi/event interface.

However, some users of /proc/acpi/event are really input events,
and they already report their events via the input layer.

Introduce a new interface, acpi_bus_generate_netlink_event(),
which is explicitly called by devices that want to repoprt
events via netlink.  This allows the input-like events
to opt-out of generating netlink events.  In summary:

events that are sent via netlink:
	ac/battery/sbs
	thermal
	processor
	thinkpad_acpi dock/bay

events that are sent via input layer:
	button
	video hotkey
	thinkpad_acpi hotkey
	asus_acpi/asus-laptop hotkey
	sonypi/sonylaptop
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Thomas Renninger reports that if one tries to load thinkpad-acpi in a
non-thinkpad, one gets:

Call Trace:
 [<ffffffff802fa57d>] kref_get+0x2f/0x36
 [<ffffffff802f97f7>] kobject_get+0x12/0x17
 [<ffffffff8036dfd7>] get_driver+0x14/0x1a
 [<ffffffff8036dfee>] driver_remove_file+0x11/0x32
 [<ffffffff8823b9be>] :thinkpad_acpi:thinkpad_acpi_module_exit+0xa8/0xfc
 [<ffffffff8824b8a0>] :thinkpad_acpi:thinkpad_acpi_module_init+0x74a/0x776
 [<ffffffff8024f968>] __link_module+0x0/0x25
 [<ffffffff80252269>] sys_init_module+0x162c/0x178f
 [<ffffffff8020bc2e>] system_call+0x7e/0x83

So, track if the platform driver and its driver attributes were registered,
and only deallocate them in that case.

This patch is based on Thomas Renninger's patch for the issue.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

modpost is going to use these to create e.g. acpi:ACPI0001
in modules.alias.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

The backlight class does all the locking needed for sysfs access, but
offers no API to interface to that locking without an layer violation.

Since we need to mutex-lock procfs access, implement in-driver locking for
brightness.  It will go away the day thinkpad-acpi procfs goes away, or the
backlight class gives us a way to use its locks without a layer violation.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Name it thinkpad-acpi version 0.15.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Reading the 16 thermal sensors directly from the EC has been stable for
about one year, in all supported ThinkPad models.  Remove its
"experimental" label.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

We get +128 instead of -128 from the DSDT TMPx methods, due to errors when
converting a EC byte return that is a s8 to an ACPI handler return that is
an int.

Fix it once and for all, by clamping acceptable temperature readings from
DSDT TMPx so that anything outside the [-127,+127] range is converted to
TP_EC_THERMAL_TMP_NA (-128).
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Michael Olbrich <michael.olbrich@gmx.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Lenovo ThinkPads have a slightly different key map layout from IBM
ThinkPads (fn+f2 and fn+f3 are swapped).  Knowing which one we are dealing
with, we can properly set a few more hot keys up by default.

Also, export the correct vendor in the input device, as that information
might be useful to userspace.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

It appears that Lenovo decided to break the EC brightness control interface
in a weird way in their latest BIOSes.  Fortunately, the old CMOS NVRAM
interface works just fine in such BIOSes.

Add a module parameter that allows the user to select which strategy to use
for brightness control: EC, NVRAM, or both.  By default, do both (which is
the way thinkpad-acpi used to work until now) on IBM ThinkPads, and use
NVRAM only on Lenovo ThinkPads.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Keep note of ThinkPad model, BIOS and EC firmware information, and log it
on startup.  Makes for far more readable code in places, too.

This patch also adds Lenovo's PCI ID to the pci ids table.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some of the module parameters are boolean in nature.  Make it so in fact.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Rename an internal driver constant, on request by Len Brown.  Also,
document exactly what it is for.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

The change in the way hotkey events are handled by default, and the use of
the input layer for the hotkey events are important enough features to
warrant increasing the major field of the sysfs interface version.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

The expected user case for the radio slider switch on a ThinkPad includes
interfacing to applications, so that the user gets an offer to find and
associate with a wireless network when the switch is changed from disabled
to enabled (ThinkVantage suite).

Export the information about the switch state, and switch change events as
an EV_SW SW_RADIO event over the input layer.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ivo van Doorn <ivdoorn@gmail.com>
Cc: Richard Hughes <hughsient@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>