Call kstrtoint(), where appropriate, instead of using custom approach.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Simplify the user copy code by using strndup_user().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

It seems next_cmd() predates the strsep() implementation in the kernel.
For a long time we have the latter one, thus, replace next_cmd(&buf) with
strsep(&buf, ",").
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Setting the initial state of input-device switches must be done before
registering the input-device.

Otherwise the initial state will get send out as an event as soon
as input_sync() gets called.

E.g. when undocking a tablet using intel-vbtn to report SW_TABLET_MODE
and SW_DOCK before this commit we would get (evemu-record output):

E: 0.000001 0005 0005 0001	# EV_SW / SW_DOCK              1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000109 0005 0005 0000	# EV_SW / SW_DOCK              0
E: 0.000109 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000133 0005 0001 0001	# EV_SW / SW_TABLET_MODE       1
E: 0.000133 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms

The first SW_DOCK=1 report is spurious, setting the initial switch
state before registering the input-device fixes this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This is a preparation patch for calling detect_tablet_mode() from
intel_vbtn_input_setup() without needing a forward declaration.

Note this commit makes no functional changes, the moved block of code
is completely unchanged.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

On some Asus devices, e.g. the T100TA, when the charger is connected
we not only get a WMI event with code 0x58, but immediately after that
event we also get an even with code 0x79.

This is likely related to these devices having an Asus WMI device with a
device-id of 0x00120066, which seems to provide some sort of charger-type
info. The T100TA charger over a micro-USB connector, the embedded-
controller register read when calling asus_wmi_get_devstate(0x00120066)
returns different values when connected to a USB port (max 500mA charging)
vs when connected to a 2A capable wall-charger. But the AML code reading
this mangles the return value so that we can no longer tell the difference.
So for now the meaning of the value return when getting the status of
device-id 0x00120066 is unclear.

This commit adds a key-mapping of code 0x79 to KE_IGNORE, silencing the
kernel logging the following message every time the charger is plugged-in:

[   79.639548] asus_wmi: Unknown key 79 pressed
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

On Asus 2-in-1s with a detachable keyboard the Asus WMI interface
reports if the tablet is attached to the keyboard or not.

Report if the 2-in-1 is in tablet or clamshell mode to userspace
by reporting SW_TABLET_MODE events to userspace.

This has been tested on a T100TA, T100CHI, T100HA and T200TA.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Move the asus_wmi_input_init() and asus_wmi_input_exit() functions to
below the WMI helpers, so that further patches in this patch-set can use
the WMI helpers inside asus_wmi_input_init() without needing a forward
declaration.

Note this commit makes no functional changes, the moved block of code
is completely unchanged.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The variable status is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The WMI INIT method on for some reason turns on the camera LED on these
2-in-1s, without the WMI interface allowing further control over the LED.

To fix this commit b5f7311d ("platform/x86: asus-nb-wmi: Do not load
on Asus T100TA and T200TA") added a blacklist with these 2 models on it
since the WMI driver did not add any extra functionality to these models.

Recently I've been working on making more 2-in-1 models report their
tablet-mode (SW_TABLET_MODE) to userspace; and I've found that these 2
Asus models report this through WMI. This commit reverts the adding
of the blacklist, so that the Asus WMI driver can be used on these
models to report their tablet-mode.

Note, not calling INIT is also not an option, because then we will not
receive events when the tablet-mode changes. So the LED issue will need
to be fixed somewhere else entirely.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The thermal handle object may fail initialization when the module is
loaded in the first place. Avoid attempting to use it on resume then.

Fixes: 6d232b29 ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator")
Reported-by: NDominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

After commit 6d232b29 ("ACPICA: Dispatcher: always generate buffer
objects for ASL create_field() operator") ACPICA creates buffers even
when new fields are small enough to fit into an integer.
Many SNC calls counted on the old behaviour.
Since sony-laptop already handles the INTEGER/BUFFER case in
sony_nc_buffer_call, switch sony_nc_int_call to use its more generic
function instead.

Fixes: 6d232b29 ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator")
Reported-by: NDominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491Reported-by: NWilliam Bader <williambader@hotmail.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1830150Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

On some devices the INT33D6 vbtn device is only used to report
tablet-mode / docked status (switches) and there are no vbtn managed
buttons.

On these devices there is no VBDL object.

Move the VBDL check to a intel_vbtn_has_buttons() helper and only exit
from intel_vbtn_probe() with -ENODEV when there are both no buttons and
no switches. Also only report the buttons being present to userspace if
the has_buttons check has succeeded.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

platform/x86: intel-vbtn: Also handle tablet-mode switch on "Detachable" and "Portable" chassis-types

Commit de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode
switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally
reporting SW_TABLET_MODE = 1 to userspace on laptops.

Some devices with a detachable keyboard and using the intel-vbnt (INT33D6)
interface to report if they are in tablet mode (keyboard detached) or not,
report 32 / "Detachable" as chassis-type, e.g. the HP Pavilion X2 series.

Other devices with a detachable keyboard and using the intel-vbnt (INT33D6)
interface to report SW_TABLET_MODE, report 8 / "Portable" as chassis-type.
The Dell Venue 11 Pro 7130 is an example of this.

Extend the DMI chassis-type check to also accept Portables and Detachables
so that the intel-vbtn driver will report SW_TABLET_MODE on these devices.

Note the chassis-type check was originally added to avoid a false-positive
tablet-mode report on the Dell XPS 9360 laptop. To the best of my knowledge
that laptop is using a chassis-type of 9 / "Laptop", so after this commit
we still ignore the tablet-switch for that chassis-type.

Fixes: de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Commit de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode
switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally
reporting SW_TABLET_MODE = 1 to userspace on laptops (specifically on the
Dell XPS 9360), to avoid e.g. userspace ignoring touchpad events because
userspace thought the device was in tablet-mode.

But if we are not getting the initial status of the switch because the
device does not have a tablet mode, then we really should not advertise
the presence of a tablet-mode switch to userspace at all, as userspace may
use the mere presence of this switch for certain heuristics.

Fixes: de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Split the sparse keymap into 2 separate keymaps, a buttons and a switches
keymap and combine the 2 to a single map again in intel_vbtn_input_setup().

This is a preparation patch for not telling userspace that we have switches
when we do not have them (and for doing the same for the buttons).

Fixes: de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Use acpi_evaluate_integer() instead of open-coding it.

This is a preparation patch for adding a intel_vbtn_has_switches()
helper function.

Fixes: de9647ef ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the similar check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the similar check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the very same check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the similar check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the very same check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the very same check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

led_classdev_unregister() already has the very same check, so,
drop a duplicate in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

There is no need to have comma in terminator line. This will help
to find a potentially broken entries, due to placing after it,
during compilation time.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add support for Vinga Twizzle J116 Silead touchscreen which uses GSL1680 chip.
Signed-off-by: NAndrew Dunai <a@dun.ai>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Slim Bootloader(SBL) is a small open-source boot firmware,
designed for running on certain Intel platforms. SBL can be
thought-of as fulfilling the role of a minimal BIOS
implementation, i.e initializing the hardware and booting
Operating System.

Since SBL is not UEFI compliant, firmware update cannot be triggered
using standard UEFI runtime services. Further considering performance
impact, SBL doesn't look for a firmware update image on every reset
and does so only when firmware update signal is asserted.

SBL exposes an ACPI-WMI device which comes up in sysfs as
/sys/bus/wmi/44FADEB1xxx and this driver adds a
"firmware_update_request" device attribute. This attribute normally
has a value of 0 and userspace can signal SBL to update firmware,
on next reboot, by writing a value of 1 like:

echo 1 > /sys/bus/wmi/devices/44FADEB1xxx/firmware_update_request

This driver only implements a signaling mechanism, the actual firmware
update process and various details like firmware update image format,
firmware image location etc are defined by SBL and are not in the
scope of this driver.

DocLink: https://slimbootloader.github.io/security/firmware-update.htmlSigned-off-by: NJithu Joseph <jithu.joseph@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When both CONFIG_DEBUG_FS and CONFIG_PM_SLEEP are disabled, the
functions that got moved out of the #ifdef section now cause
a warning:

drivers/platform/x86/intel_pmc_core.c:654:13: error: 'pmc_core_lpm_display' defined but not used [-Werror=unused-function]
  654 | static void pmc_core_lpm_display(struct pmc_dev *pmcdev, struct device *dev,
      |             ^~~~~~~~~~~~~~~~~~~~
drivers/platform/x86/intel_pmc_core.c:617:13: error: 'pmc_core_slps0_display' defined but not used [-Werror=unused-function]
  617 | static void pmc_core_slps0_display(struct pmc_dev *pmcdev, struct device *dev,
      |             ^~~~~~~~~~~~~~~~~~~~~~

Rather than add even more #ifdefs here, remove them entirely and
let the compiler work it out, it can actually get rid of all the
debugfs calls without problems as long as the struct member is
there.

The two PM functions just need a __maybe_unused annotations to avoid
another warning instead of the #ifdef.

Fixes: aae43c2b ("platform/x86: intel_pmc_core: Relocate pmc_core_*_display() to outside of CONFIG_DEBUG_FS")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Intel Elkhart Lake exposes SCU/PMC as an ACPI device that only supports
IPC functionality so add a platform driver supporting it. Interrupt is
optional so we let intel_scu_ipc_probe() to decide based on the passed
platform data whether it uses interrupt or polling.
Co-developed-by: NDivya Sasidharan <divya.s.sasidharan@intel.com>
Signed-off-by: NDivya Sasidharan <divya.s.sasidharan@intel.com>
Co-developed-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Since 'value' is declared as unsigned long, the following statement is
always false.
	value < 0

So let's remove it.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This adds dual fan control for the following models:
P50, P51, P52, P70, P71, P72, P1 gen1, P2 gen2, X1E gen1 and X1E gen2.

Both fans are controlled together as if they were a single fan.

Tested on an X1 Extreme Gen1, an X1 Extreme Gen2, and a P50.

The patch is defensive, it adds only specific supported machines, and falls
back to the old behavior if both fans cannot be controlled.

Background:
I tested the BIOS default behavior on my X1E gen2 and both fans are always
changed together. So rather than adding controls for each fan, this controls
both fans together as the BIOS would do.

This was inspired by a discussion on dual fan support for the thinkfan tool
(see link below). All BIOS IDs are taken from there. The X1E gen2 ID is
verified on my machine.

Thanks to GitHub users voidworker and civic9 for the earlier patches and
BIOS IDs, and to users peter-stoll and sassman for testing the patch on
their machines.

BugLink: https://github.com/vmatare/thinkfan/issues/58Signed-off-by: NLars Hofhansl <larsh@apache.org>
[andy: massaged commit message to capitalize ID and convert to BugLink]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This driver only creates a bunch of platform devices sharing resources
belonging to the PMC device. This is pretty much what MFD subsystem is
for so move the driver there, renaming it to intel_pmc_bxt.c which
should be more clear what it is.

MFD subsystem provides nice helper APIs for subdevice creation so
convert the driver to use those. Unfortunately the ACPI device includes
separate resources for most of the subdevices so we cannot simply call
mfd_add_devices() to create all of them but instead we need to call it
separately for each device.

The new MFD driver continues to expose two sysfs attributes that allow
userspace to send IPC commands to the PMC/SCU to avoid breaking any
existing applications that may use these. Generally this is bad idea so
document this in the ABI documentation.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Add new function that allows telemetry modules to get pointer to the
platform specific configuration. This is needed to allow the telemetry
debugfs module to fetch PMC IPC instance in the subsequent patch.

This also allows us to replace telemetry_pltconfig_valid() with
telemetry_get_pltdata() as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The PCI probe driver in intel_pmc_ipc.c is a duplicate of what we
already have in intel_scu_pcidrv.c with the exception that the later also
creates SCU specific devices. Move the PCI IDs from the intel_pmc_ipc.c
to intel_scu.c and use driver_data to detect whether SCU devices need to
be created or not.

Also update Kconfig entry to mention all platforms supported by the
Intel SCU PCI driver and change dependency from X86_INTEL_MID to PCI
which is more generic.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Now that all callers have been converted over to the SCU IPC API we can
drop intel_pmc_ipc_command().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Convert the Intel Apollo Lake telemetry driver to use the new SCU IPC
API. This allows us to get rid of the duplicate PMC IPC implementation
which is now covered in SCU IPC driver.

Also move telemetry specific IPC message constant to the telemetry
driver where it belongs.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

SCU IPC is pretty much the same IPC implemented in the intel_pmc_ipc
driver so drop the duplicate implementation and call directly the SCU
IPC.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Drivers such as intel_pmc_ipc.c can be unloaded as well so in order to
support those in this driver add a new function that can be called to
unregister the SCU IPC when it is not needed anymore.

We also add a managed version of the intel_scu_ipc_register() that takes
care of calling intel_scu_ipc_unregister() automatically when the driver
is unbound.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Convert the IPC util to use the new SCU IPC API where the SCU IPC
instance is passed to the functions.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This converts the power button driver to use the new SCU IPC API where
the SCU IPC instance is passed to the functions.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>