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: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Dominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Andy 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: Dominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491Reported-by: William Bader <williambader@hotmail.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1830150Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Update version to include 5.8 series enhancements.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

turbo-freq enable, requires clos enable. So this is a two step process,
when "-a" option is used. This is causing confusion to users. So enable
clos by default for turbo-freq enable.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

On CLX-N, the perf-profile-level's output is terminated before the
speed-select-base-freq-properties are output which results in a corrupt
json file.

Adjust the output of speed-select-base-freq-properties by one on CLX-N.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: platform-driver-x86@vger.kernel.org
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

On CLX-N the perf-profile output is missing the package, die, and cpu
output.  On CLX-N the pkg_dev struct will never be evaluated by the core
code so pkg_dev.processed is always 0 and the package, die, and cpu
information is never output.

Set the pkg_dev.processed flag to 1 for CLX-N processors.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: andriy.shevchenko@linux.intel.com
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: platform-driver-x86@vger.kernel.org

When turbo-freq or base-freq feature is not supported, the enable will
fail. So first check support status and print error.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

When turbo-freq is enabled, we can't disable core-power. Currently
it prints debug message to warn. Change this to error message.

While here remove "\n" from calls to isst_display_error_info_message(),
as it will be added again during actual print.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

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

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

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

When the MFD driver is a loadable module, the watchdog driver fails
to get linked into the kernel:

drivers/watchdog/iTCO_wdt.o: In function `update_no_reboot_bit_pmc':
iTCO_wdt.c:(.text+0x54f): undefined reference to `intel_pmc_gcr_update'

The code is written to support operation without the MFD driver, so
add a Kconfig dependency that allows this, while disallowing the watchdog
to be built-in when the MFD driver is a module.

Fixes: 25f1ca31 ("platform/x86: intel_pmc_ipc: Convert to MFD")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy 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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Add support for Vinga Twizzle J116 Silead touchscreen which uses GSL1680 chip.
Signed-off-by: Andrew Dunai <a@dun.ai>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy 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: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Andy 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: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

I will be helping the x86 platform driver maintainers to look after
Intel SCU drivers.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy 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: Divya Sasidharan <divya.s.sasidharan@intel.com>
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Co-developed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy 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: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Andy 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: Lars Hofhansl <larsh@apache.org>
[andy: massaged commit message to capitalize ID and convert to BugLink]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Merge branch 'ib-mfd-x86-usb-watchdog-v5.7' of
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
to avoid conflicts in PDx86.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

The driver lives now under MFD so split the current entry into two parts
and add me as co-maintainer of the Intel Broxton PMC driver. While there
correct formatting of Zha Qipeng's email address.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

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: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>