This patch adds the accelerometer axis data to the IIO subsystem.

Currently reporting the X, Y and Z values, as no other data can be
queried given the fact that the accelerometer chip itself is hidden
behind the Toshiba proprietary interface.
Signed-off-by: NAzael Avalos <coproscefalo@gmail.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Some new Dell AIO systems have a button that generates a WMI event to
turn the LCD on/off.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This patch reworks code for generating sparse keymap and processing WMI
events. It unifies procedure for generating sparse keymap and also unifies
big switch code for processing WMI events of different types. After this
patch dell-wmi driver does not differ between "old" and "new" hotkey type.

It constructs sparse keymap table with all WMI codes. It is because on some
laptops (e.g. Dell Latitude E6440) ACPI/firmware send both event types (old
and new).

Each WMI code in sparse keymap table is prefixed by 16bit event type, so it
does not change functionality on laptops with "old" hotkey support (those
without scancodes in DMI).

This allow us to distinguish between same WMI codes with different types in
sparse keymap. Thanks to this WMI events of type 0x0011 were moved from big
switch into sparse keymap table too.

This patch also fixes possible bug in parsing WMI event buffer introduced
in commit 5ea25597 ("dell-wmi: Add support for new Dell systems"). That
commit changed buffer type from int* to u16* without fixing code. More at:
http://lkml.iu.edu/hypermail/linux/kernel/1507.0/01950.htmlSigned-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

ACPI DSDT tables have defined other WMI codes, but does not contain any
description when those codes are emitted. Some other codes can be found in
logs on internet. In this patch are all which I saw, but lot of them are
not tested properly (e.g. for duplicate events with AT keyboard). Now we
have all WMI event codes at one place and in future after proper testing
those codes can be correctly enabled or disabled...
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

For better readability of keymap table, sort events by codes and also
update comments for events to be more informative.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

>From Dell we know that WMI event code 0xe045 is for Num Lock key, but it is
unclear due to message in commit 0b3f6109 ("dell-wmi: new driver for
hotkey control").
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Link: https://lkml.org/lkml/2015/7/7/830Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This patch adds the Power Management Controller driver as a PCI driver
for Intel Core SoC architecture.

This driver can utilize debugging capabilities and supported features
as exposed by the Power Management Controller.

Please refer to the below specification for more details on PMC features.
http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html

The current version of this driver exposes SLP_S0_RESIDENCY counter.
This counter can be used for detecting fragile SLP_S0 signal related
failures and take corrective actions when PCH SLP_S0 signal is not
asserted after kernel freeze as part of suspend to idle flow
(echo freeze > /sys/power/state).

Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
detects favorable conditions to enter its low power mode. As a
pre-requisite the SoC should be in deepest possible Package C-State
and devices should be in low power mode. For example, on Skylake SoC
the deepest Package C-State is Package C10 or PC10. Suspend to idle
flow generally leads to PC10 state but PC10 state may not be sufficient
for realizing the platform wide power potential which SLP_S0 signal
assertion can provide.

SLP_S0 signal is often connected to the Embedded Controller (EC) and the
Power Management IC (PMIC) for other platform power management related
optimizations.

In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
power gated + PLL Idle.

As part of this driver, a mechanism to read the SLP_S0_RESIDENCY is exposed
as an API and also debugfs features are added to indicate SLP_S0 signal
assertion residency in microseconds.

echo freeze > /sys/power/state
wake the system
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NVishwanath Somayaji <vishwanath.somayaji@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Some BIOSes unconditionally send an ACPI notification to RBTN when the
system is resuming from suspend. This makes dell-rbtn send an input
event to userspace as if a function key was pressed. Prevent this by
ignoring all the notifications received while the device is suspended.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: NAlex Hung <alex.hung@canonical.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Override default LED class suspend/resume handles, by keeping track of
the brightness level before suspending so that it can be automatically
restored on resume by calling default resume handler.
Signed-off-by: NMarco Trevisan (Treviño) <mail@3v1n0.net>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

aux0_show and aux1_show consists of almost identical code. Pull that
into a common helper and make them thin wrappers. Similarly for
_store.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Asus Zenbook ux31a is providing ACPI0008 interface for ALS
(Ambient Light Sensor), which is accessible for OS => Win 7.
This sensor can be used with iio/acpi-als driver.
Since it is disabled by default, we should use asus-wmi
interface to enable it.
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

My patch to the ideapad-laptop driver to get the ESC key working on the
Yoga 1170 (Yoga 3) failed to do the same for the following model, the
Lenovo Yoga 700.

Denis Gordienko managed to get it working by adding another GUID for the
new WMI interface. I have adapted his patch to normal coding style
and simplified it a bit for inclusion, but this patch is currently
untested.

Link: https://forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/YOGA-3-14-How-to-reclaim-my-Esc-key-and-permanently-disable/m-p/3317499Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Tested-by: NDenis Gordienko <denis.gordienko.mail@gmail.com>
[dvhart: Whitespace cleanup, static const char *const array declaration]
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Microsoft Surface Book has a tablet mode button. Print another message
once on this event instead of repeating "Unknown event...".

Unfortunately, proper support involves the _DSM method, which is not a
discoverable interface. Just print a warning for now.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Instead of opencoding let's use generic UUID library functions here.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Older VAIO laptops without the SN00 ACPI method will have the "handles"
variable unset. Return early from sony_nc_function_cleanup when "handles"
is null.
Signed-off-by: NLawrence Yiu <lawyiu.dev@gmail.com>
Acked-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The telemetry_core_ops structures are never modified, so declare them as
const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Acked-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Properly return rv back to the caller in the case of an error in
parse_arg. In the process remove a unused variable 'out'.
Signed-off-by: NGiedrius Statkevičius <giedrius.statkevicius@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Initializing rv to AE_OK is pointless because later function results are
assigned to them and only then the variable is used
Signed-off-by: NGiedrius Statkevičius <giedrius.statkevicius@gmail.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

It is possible that acpi_evaluate_integer might fail and value would not be
set to any value so correct this defect by returning 0 in case of an
error. This is also the correct thing to return because the backlight
subsystem will print the old value of brightness in this case.
Signed-off-by: NGiedrius Statkevičius <giedrius.statkevicius@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Commit 52cbae01 ("toshiba_acpi: Change default Hotkey enabling value")
changed the hotkeys enabling value, as it was the same value Windows uses,
however, it turns out that the value tells the EC that the driver will now
take care of the hardware events like the physical RFKill switch or the
pointing device toggle button.

This patch reverts such commit by changing the default hotkey enabling
value to 0x09, which enables hotkey events only, making the hardware
buttons working again.

Fixes bugs 113331 and 114941.
Signed-off-by: NAzael Avalos <coproscefalo@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Currently the optional IPC resources prevent telemetry driver from
probing if these resources are not in ACPI table. This patch decouples
telemetry driver from these optional resources, so that telemetry driver
has dependency only on the necessary ACPI resources.
Signed-off-by: NAubrey Li <aubrey.li@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

If fan_get_status() fails then "s" is not initialized.  Tweak the error
handling a bit to silence this warning.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Presumably "pss_period" and "ioss_period" can't both be zero, but this
function is never called so we can't infer that using static analysis
alone.

Silence the warning by setting "ret" to zero.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

If acpi_evaluate_integer() fails then "lret" isn't initialized.  I've
tweaked the error handling to avoid this issue.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Lifebook E734/E744/E754 has a LED which the manual calls "radio
components indicator".  It should be lit when any radio transmitter is
enabled.  Its state can be read and set using ACPI (FUNC interface,
RFKILL method).

Since the Lifebook E734/E744/E754 only has a button (as compared to a
slider) for enabling/disabling radio transmitters, I believe the LED in
question is meant to indicate whether all radio transmitters are
currently on or off.  However, pressing the radio toggle button does not
automatically change the hardware state of the transmitters: it looks
like this machine relies on soft rfkill.

As for detecting whether the LED is present on a given machine, I had to
resort to educated guesswork.  I assumed this LED is present on all
devices which have a radio toggle button instead of a slider.  My
Lifebook E744 holds 0x01010001 in BTNI.  By comparing the bits and
buttons with those of a Lifebook E8420 (BTNI=0x000F0101, has a slider),
I put my money on bit 24 as the indicator of the radio toggle button
being present.  Furthermore, bit 24 is also clear on the S7020 which
does not have the toggle button or an RF LED.

Figuring out how the LED is controlled was more deterministic as all it
took was decompiling the DSDT and taking a look at method S000 (the
RFKILL method of the FUNC interface).

The LED control method implemented here is unsuitable for use with
"heavy" LED triggers, like phy0rx.  Once blinking frequency achieves a
certain level, the system hangs.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
[jwoithe: Comment on bit 24 in BTNI, expanded commit msg]
Signed-off-by: NJonathan Woithe <jwoithe@just42.net>
[dvhart: Minor style and commit log adjustments]
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

HP ProBook 440 G3 laptop needs a non-standard mapping (x_inverted_usd).
Signed-off-by: NMartin Vajnar <martin.vajnar@gmail.com>
Acked-by: NÉric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Use shiny new acpi_dev_found() and remove all the boilerplate
to search for a particular ACPI device. No functional change.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NLee, Chun-Yi <jlee@suse.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use shiny new acpi_dev_found() and remove all the boilerplate
to search for a particular ACPI device. No functional change.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is the same as the original workaround from S3 but for S4.  Without
this workaround, a rfkill event will be received and it will toggle
wireless devices when radio hotkey is not pressed.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

GPS rfkill support via pre-2009 WMI interface uses hp_wmi_get_sw_state()
and hp_wmi_get_hw_state() to query its current hard and soft block state,
respectively.

In hp_wmi_get_sw_state() a mask is calculated which bit should be checked
in an int value returned by firmware to get current block state: 0x200 <<
(r * 8) which with r being 3 for GPS results in overflow and mask of zero.
The same goes for hp_wmi_get_hw_state().

This effectively means that GPS rfkill on this WMI interface is considered
always both hard and soft blocked.

Unfortunately, later when rfkill subsystem calls hp_wmi_set_block() to sync
this block to hardware firmware at least on my old nc6400 gets confused and
sets both hard and soft blocks on WiFi and BT.

This happens for example on hp-wmi module load.

Since due to overflow described above it is dubious that this ever worked
correctly and HP laptops with modems having GPS support seem to all have
been released well past year 2009 let's just remove GPS rfkill support via
pre-2009 WMI interface.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

rfkill registration order in hp_wmi_rfkill_setup() is:
1) WiFi,
2) BT,
3) WWAN,
5) GPS.

Unregistration when cleaning up on error return should happen in reverse
order.

This means that: If BT rfkill fails to be allocated we possibly need to
first unregister WiFi rfkill before destroying it.

The same goes with (WWAN, BT) and (GPS, WWAN) pairs.

Also, if WWAN rfkill fails to register we need to (possibly) unregister BT
not the GPS one.  And if GPS rfkill fails to register we need to unregister
WWAN not the BT one.

We never need to unregister GPS rfkill here since if GPS rfkill
registration succeeds this function returns without error so no cleanup is
necessary.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Similarly to Dell Vostro V131, Dell Inspiron M5110 also requires an
SMBIOS request to be issued in order for WMI events to be generated and
does not raise an i8042 interrupt when the Dell Instant Launch hotkey is
pressed.  However, the event code for that hotkey on this machine is
0xe029, so add it to the legacy keymap.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NDarek Stojaczyk <darek.stojaczyk@gmail.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

On models on which an SMBIOS request needs to be issued in order for WMI
events to be generated, pressing the Dell Instant Launch hotkey does not
raise an i8042 interrupt - only a WMI event is generated (0xe025 on Dell
Vostro V131).  As that WMI event is the only way the kernel will be
notified about pressing the Dell Instant Launch hotkey on such machines,
the relevant keymap entry has to be changed to a KE_KEY one.  However,
the same WMI event should still be ignored on machines which do not
require an SMBIOS request for enabling WMI, so filter it conditionally
in dell_wmi_process_key().
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

On some laptop models (e.g. Dell Vostro V131), WMI events are not
generated until a specific SMBIOS request is issued to register an event
listener [1].  As there seems to be no ACPI method or SMBIOS request to
determine without possible side effects whether a given machine needs to
issue this SMBIOS request in order to receive WMI events, DMI matching
is used to whitelist the models which need it.

[1] https://lists.us.dell.com/pipermail/libsmbios-devel/2015-July/000612.htmlSigned-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

As dell_smi_error() is exported by dell-smbios, its prefix should be
consistent with other exported symbols, so change function name to
dell_smbios_error().
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The dell_smi_error() method could be used by modules other than
dell-laptop for convenient translation of SMBIOS request errors into
errno values.  Thus, move it to dell-smbios.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Some Lenovo ideapad models lack a physical rfkill switch.
On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK,
ideapad-laptop would wrongly report all radios as blocked by
hardware which caused wireless network connections to fail.

Add these models without an rfkill switch to the no_hw_rfkill list.
Signed-off-by: NJohn Dahlstrom <jodarom@sdf.org>
Cc: <stable@vger.kernel.org> # 3.17.x-: 4fa9dabc: ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked
Cc: <stable@vger.kernel.org>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Lifebook E734/E744/E754 has a radio toggle button which uses code 0x420.
Map it to KEY_RFKILL.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Acked-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>