The HP touchsmart tablet has a key for rotating the UI from landscape to
portrait. Add support for it.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Commit 3e9b988e
"wmi: Free the allocated acpi objects through wmi_get_event_data"
had the same purpose as commit
44ef00e6
"hp-wmi: Fix two memleaks"

This should solve this regression:

http://bugzilla.kernel.org/show_bug.cgi?id=14890Signed-off-by: NAnisse Astier <anisse@astier.eu>
Reported-by: NSedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

When acpi_evaluate_object() is passed ACPI_ALLOCATE_BUFFER,
the caller must kfree the returned buffer if AE_OK is returned.

The callers of wmi_get_event_data() pass ACPI_ALLOCATE_BUFFER,
and thus must check its return value before accessing
or kfree() on the buffer.
Signed-off-by: NLen Brown <len.brown@intel.com>

Emphasize that that wmi_install_notify_handler() returns an acpi_status
rather than -errno by by testing ACPI_SUCCESS(), ACPI_FAILURE().

No functional change in this patch, but this confusion caused a bug in dell-wmi.
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

These function allocate an acpi object by calling wmi_get_event_data, which
then calls acpi_evaluate_object, and it is not freed afterwards.

And kernel doc is fixed for parameters of wmi_get_event_data.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

1) Add support for reading the hardware blocked state.  Previously
   we read a combination of the hardware and software blocked states,
   reporting it as the software blocked state.  This caused some
   confusing behaviour.

2) The software state is persistent, mark it as such.

3) Check rfkill in the resume handler.  Both the hard and soft
   blocked states may change over hibernation.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

rfkill_unregister() should always be followed by rfkill_destroy()
In this case, rfkill_destroy was called two times on wifi_rfkill and
never on bluetooth_rfkill.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Gets rid of the following warning:

Platform driver 'hp-wmi' needs updating - please use dev_pm_ops

I tested that the resume handler still works on my HP 2510p notebook.

[rjw: Fixed up the definition of hp_wmi_pm_ops.]
Signed-off-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Some systems may not support input events, or registering the input
handler may have failed. So check that an input device exists before
trying to set the docking and tablet mode state during resume.

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13865Reported-and-tested-by: NCédric Godin <cedric@belbone.be>
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NMatthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix the third (I think) polarity error I accidentally
introduced in the rfkill rewrite to make wireless work
again on (certain?) HP laptops.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

HP tablets send a WMI event when a tablet state change occurs, but use the
same method as is used for reporting docking and undocking. The same query
is used to obtain the state of the hardware. Bit 0 indicates the docking
state, while bit 2 indicates the tablet state. This patch breaks these out
and sends separate input events for tablet and dock state changes. An
additional sysfs file is added to report the tablet state.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

rfkill_set_global_sw_state() (previously rfkill_set_default()) will no
longer be exported by the rewritten rfkill core.

Instead, platform drivers which can provide persistent soft-rfkill state
across power-down/reboot should indicate their initial state by calling
rfkill_set_sw_state() before registration.  Otherwise, they will be
initialized to a default value during registration by a set_block call.

We remove existing calls to rfkill_set_sw_state() which happen before
registration, since these had no effect in the old model.  If these
drivers do have persistent state, the calls can be put back (subject
to testing :-).  This affects hp-wmi and acer-wmi.

Drivers with persistent state will affect the global state only if
rfkill-input is enabled.  This is required, otherwise booting with
wireless soft-blocked and pressing the wireless-toggle key once would
have no apparent effect.  This special case will be removed in future
along with rfkill-input, in favour of a more flexible userspace daemon
(see Documentation/feature-removal-schedule.txt).

Now rfkill_global_states[n].def is only used to preserve global states
over EPO, it is renamed to ".sav".
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Almost all drivers do not support user_claim, so remove it
completely and always report -EOPNOTSUPP to userspace. Since
userspace cannot really drive rfkill _anyway_ (due to the
odd restrictions imposed by the documentation) having this
code is just pointless.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is possible that the system gets docked or undocked while it's
suspended. Generate an input event on resume to notify user space
if there was a state change.

As it is a switch, we can generate the event unconditionally; the
input layer will only pass it on if there is an actual change.
Signed-off-by: NFrans Pop <elendil@planet.nl>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The error-path code can call rfkill_unregister() with a pointer which does
not contain the result of a call to rfkill_register().  It goes BUG().

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=12560.

Cc: Frans Pop <elendil@planet.nl>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Len Brown <lenb@kernel.org>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Reported-by: NHelge Deller <deller@gmx.de>
Testted-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the initial state is not set when the input device is set up, the first
docking event after the module is loaded will be lost.
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NMatthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Error was introduced in commit fe8e4e03 ("hp-wmi: handle
rfkill_register() failure").
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Compilation of the HP WMI hotkeys code results in the following:

  CC [M]  drivers/platform/x86/hp-wmi.o
drivers/platform/x86/hp-wmi.c: In function hp_wmi_bios_setup:
drivers/platform/x86/hp-wmi.c:431: warning: ignoring return value of rfkill_register,
	 declared with attribute warn_unused_result
drivers/platform/x86/hp-wmi.c:441: warning: ignoring return value of rfkill_register,
	 declared with attribute warn_unused_result
drivers/platform/x86/hp-wmi.c:450: warning: ignoring return value of rfkill_register,
	 declared with attribute warn_unused_result
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move x86 platform specific drivers from drivers/misc/
to a new home under drivers/platform/x86/.

The community has been maintaining x86 vendor-specific
platform specific drivers under /drivers/misc/ for a few years.
The oldest ones started life under drivers/acpi.
They moved out of drivers/acpi/ because they don't actually
implement the ACPI specification, but either simply
use ACPI, or implement vendor-specific ACPI extensions.

In the future we anticipate...
drivers/misc/ will go away.
other architectures will create drivers/platform/<arch>
Signed-off-by: NLen Brown <len.brown@intel.com>

On my HP 2510, pressing the (i) button generates an unknown keycode:
0x213b. So here is a patch adding support for it. However, as it seems
there is already support for a similar button connected to 0x231b as
keycode, I wonder if it could be a typo in the driver?
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make the needlessly global hp_wmi_notify() static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It turns out that event 0x4 merely indcates that a hotkey has been
pressed, not which one.  A further query is required in order to determine
the actual keypress.  The following patch adds support for that along with
the known keycodes.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

hp-wmi currently changes the RFKill state by altering the struct members
rather than using the dedicated interface, meaning that update events
won't be pushed to userspace.  This patch fixes that, along with fixing
the declared type of the WWAN kill switch.  It also ensures that rfkill
interfaces are only registered for hardware that exists.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <ivdoorn@gmail.com>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This driver adds support for reading and configuring certain information
on modern HP laptops with WMI BIOS interfaces.  It supports enabling and
disabling the ambient light sensor, querying attached displays and hard
drive temperature, sending events on docking and querying the state of the
dock and toggling the state of the wifi, bluetooth and wwan hardware via
rfkill.  It also makes the little "(i)" button work on machines that send
that via WMI rather than via the keyboard controller.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>