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>

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>

We want the size of the struct, not of a pointer to it. To be future
proof, just dereference the pointer to get the desired type.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The Kconfig currently controlling compilation of this code is:

drivers/platform/x86/Kconfig:config INTEL_SCU_IPC
drivers/platform/x86/Kconfig:   bool "Intel SCU IPC Support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_pci_driver() uses the same init level priority as
builtin_pci_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We don't replace module.h with init.h since the file already has that.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: platform-driver-x86@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

During legacy suspend flow, IPC1 commands are being requested
from opregion driver. But the PMC_IPC1 command will timeout as example:

[  281.444600] ipc_debug##: ipc_send_command: cmd=0x201ff,
[  281.444648] wbuf[0]=0x4ea6
[  281.444668] wbuf[1]=0x0
[  281.444674] wbuf[2]=0x0
[  281.444676] wbuf[3]=0x0
[  284.446467] pmc-ipc-plat INT34D2:00: IPC timed out, TS=0x4, CMD=0x200ff

This is because before the opregion driver could send IPC1 commands,
the PMC_IPC irq is already suspended. Which makes the IPC command to
timeout.

Solution: register pmc_ipc irq as IRQF_NO_SUSPEND
Signed-off-by: NAnanth Krishna R <ananth.krishna.r@intel.com>
Signed-off-by: NBharath K Veera <bharath.k.veera@intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

GCR register (pmc_cfg register) is at offset 0x1008, and
remapping of 0x4 bytes is enough.
Signed-off-by: NFrancois-Nicolas Muller <francois-nicolas.muller@intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module
is loaded with wapf=4 option. Add quirk for this.
Signed-off-by: NOleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Due to a recent fix in the firmware, the Punit verbosity control bits
now adhere to the correct pattern. Hence remove the workaround and
do a read-modify-write of the register.
Signed-off-by: NSouvik Kumar Chakravarty <souvik.k.chakravarty@intel.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

On the XPS 13 9350, the dell-rbtn mechanism has a new device id, and
the DSDT turns it off if a new enough _OSI is supported.  Add a
comment about why we don't bother supporting it.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The XPS 13 9350 sends WMI keypress events that aren't enumerated in
the DMI table.  Add a table listing them.  To avoid breaking things
that worked before, these un-enumerated hotkeys won't be used if the
DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we
might want to rethink how we handle events in general.  As an
example, a whole lot of things map to KEY_PROG3 via the DMI table.

This doesn't send keypress events for any of the new events.  They
appear to all be handled by other means (keyboard illumination is
handled automatically and rfkill is handled by intel-hid).
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Checking the table for a minimum size of 7 bytes makes no sense: any valid
hotkey table has a size that's a multiple of 4.

Clean this up: replace the hardcoded header length with a sizeof and
change the check to ignore an empty hotkey table.  The only behavior
change is that a 7-byte table (which is nonsensical) will now be
treated as absent instead of as valid but empty.
Reported-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

dell-wmi and dell-laptop will compile but won't work right if DMI
isn't selected.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>

[arnd: Use depends instead of selects to avoid recursive dependencies]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The dmi_walk function maps the DMI table, walks it, and unmaps it.
This means that the dell_bios_hotkey_table that find_hk_type stores
points to unmapped memory by the time it gets read.

I've been able to trigger crashes caused by the stale pointer a
couple of times, but never on a stock kernel.

Fix it by generating the keymap in the dmi_walk callback instead of
storing a pointer.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

As dell-laptop has been changed to use dell_smbios_find_token() instead
of directly accessing members of the da_tokens table, the latter can be
marked static.
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>

As dell-laptop has been changed to use dell_smbios_find_token() instead
of find_token_id() and find_token_location(), these functions can be
safely removed.
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>

Replace all uses of find_token_location() with dell_smbios_find_token()
to avoid directly accessing the da_tokens table.
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>

Replace all uses of find_token_id() with dell_smbios_find_token() to
avoid directly accessing the da_tokens table.
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>

Ultimately, the da_tokens table should not be exported from dell-smbios.
Currently, in some cases, dell-laptop accesses that table's members
directly, so implement a new function, dell_smbios_find_token(), which
returns a pointer to an entry inside the da_tokens table with the given
token ID (or NULL if it is not found).
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>

As dell-laptop has been changed to always retrieve a pointer to the
SMBIOS buffer using dell_smbios_get_buffer(), the SMBIOS buffer can be
marked static.
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>

Ultimately, the SMBIOS buffer should not be exported from dell-smbios.
Currently, dell-laptop accesses it directly using a global variable, so
make dell_smbios_get_buffer() return a pointer to the SMBIOS buffer and
replace all uses of the global variable with local variables.
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>

An SMBIOS buffer pointer does not need to be returned by
dell_smbios_send_request(), because SMBIOS call results are stored in
the buffer exported by the module.
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>

Passing an SMBIOS buffer pointer to dell_smbios_send_request() is
redundant as it should always operate on the SMBIOS buffer exported from
the module.
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>

As dell_send_request() is exported from the module, its prefix should be
consistent with other exported symbols, so change function name to
dell_smbios_send_request().
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>

As release_buffer() is exported from the module, it has to be renamed to
something less generic, so add a "dell_smbios_" prefix to the function
name.
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>