ACPI: thinkpad-acpi: hotkey_report_mode read-write support

ACPI: thinkpad-acpi: hotkey_report_mode read-write support

ACPI core can send events over netlink in 2.6.23 and later, and
thinkpad-acpi will use a different strategy to keep backwards compatibility
with older userspace, without the need for the Kconfig option
CONFIG_THINKPAD_ACPI_INPUT_ENABLED.

Hotkey events are always sent to the input devices, and never sent to the
ACPI netlink event interface.  A new module parameter is added:
hotkey_report_mode, that selects whether events are sent to the (now)
legacy ACPI procfs event socket: 0 default mode; 1 - issue hot key events
over procfs; 2 - do not issue hot key events over procfs.

The default mode is "issue hot key events" in 2.6.23 and later.  It is
"runtime selectable" in driver backports to kernels that lack the ACPI
netlink even interface.

The way hot keys are being reported is available through the sysfs
attribute hotkey_report_mode.  This sysfs attribute is read-only on 2.6.23,
but it is read write on the backports to earlier kernels if no module
parameter was used to set hotkey_report_mode.

Hot key handling will be unconditionally enabled at driver load, along with
the best possible mask.  This follows the Windows behaviour.  Users can
modify hot key handling state it at runtime, or at load time by using the
hotkey=disable module parameter.

Userspace guidelines (using HAL as an example):

Old HAL:
	It will just work, as long as the user doesn't set
	hotkey_report_mode=2.  Old HAL will get the events (including hot
	key presses) from the ACPI procfs event interface, and it will
	ignore the input devices.

New HAL (one that supports ACPI events over netlink):

	New HAL must be able to work through ACPI netlink + thinkpad-acpi
	(and ACPI core) input devices, because that's what the ACPI
	interface has been migrated to.  It likely will need to still be
	able to work using procfs ACPI events when netlink is not
	available, to support 2.6.22 and earlier kernels.  This is not
	particular to thinkpad-acpi.

	HAL should be able to work with procfs ACPI events + thinkpad-acpi
	input devices if it wants to support enhanced functionality for
	thinkpad-acpi in earlier kernels than 2.6.23, provided through
	thinkpad-acpi backports.

	HAL must be able to work in the way old HAL does, using only the
	ACPI procfs event interface, if it wants to be usable in 2.6.22 and
	earlier kernels.  Again, this is not particular to thinkpad-acpi.

	When the ACPI netlink event interface is available, New HAL must
	use the ACPI netlink event interface + thinkpad-acpi input devices.
	In that case, don't bother with the stuff below.

	When ACPI netlink event reporting is **not** available:

	1. If no hotkey_report_mode sysfs attribute is available from
	thinkpad-acpi: work as old HAL did (i.e. just get events through
	procfs, *ignore the thinkpad-acpi input devices, if any, for
	maximum compatibilty with older thinkpad-acpi backports*).  This is
	compatible with previous thinkpad-acpi releases in mainline, and
	also with ibm-acpi.

	2. If the hotkey_report_mode sysfs attribute is available from
	thinkpad-acpi, check if it is set to 2.  If (and only if!) it is
	not 2, try to set it to 2 to avoid receiving duplicate events from
	the thinkpad-acpi input devices and ACPI procfs event interface.
	If no error is returned, HAL should work using the ACPI procfs
	event interface, and thinkpad-acpi input devices.

	If a write to hotkey_report_mode receives -EPERM or -EACCES, work
	as old HAL did (just procfs, no thinkpad-acpi input devices).

	Note that thinkpad-acpi with hotkey_report_mode set to 2 really
	doesn't care if netlink or procfs is used, and delivers exactly the
	same functionality over both... but since procfs ACPI interfaces
	are going away eventually, HAL really is to switch to netlink when
	it is available.

Signed-off-by: Henrique 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>