From: Alexey Klimov <klimov.linux@gmail.com>

Add the B550M AORUS PRO-P motherboard description to
gigabyte_wmi_known_working_platforms.
Signed-off-by: NAlexey Klimov <klimov.linux@gmail.com>
Acked-by: NThomas Weißschuh <thomas@weissschuh.net>
Link: https://lore.kernel.org/r/20210421234156.3942343-1-aklimov@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The simple_write_to_buffer() can return success if even a single byte
is copied from user space.  In this case it can result in using
uninitalized data if the buf[] array is not fully initialized.  Really
we should only succeed if the whole buffer is copied.

Just using copy_from_user() is simpler and more appropriate.

Fixes: 8074a79f ("platform/x86: intel_pmc_core: Add option to set/clear LPM mode")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YIBCf+G9Ef8wrGJw@mwandaSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The driver now fails to build without ACPI:

drivers/platform/x86/intel_pmc_core.c: In function 'pmc_core_get_tgl_lpm_reqs':
drivers/platform/x86/intel_pmc_core.c:617:41: error: invalid use of undefined type 'struct acpi_device'
  617 |         out_obj = acpi_evaluate_dsm(adev->handle, &s0ix_dsm_guid, 0,

This could probably be made optional, but it won't be used without
ACPI in practice, so just add a Kconfig dependency.

Fixes: 42813136 ("platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210421134957.3329062-1-arnd@kernel.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The "funcs" variable is a u64.  If "func" is more than 31 then the
BIT() shift will wrap instead of testing the high bits.

Fixes: c167b9c7 ("platform/surface: Add Surface Aggregator subsystem")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMaximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/YH6UUhJhGk3mk13b@mwandaSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Change the type of ret form a size_t to a ssize_t, matching the prototype
of simple_write_to_buffer(), fixing this warning reported by smatch:

drivers/platform/x86/intel_pmc_core.c:1369 pmc_core_lpm_latch_mode_write() warn: unsigned 'ret' is never less than zero.

Fixes: 8074a79f ("platform/x86: intel_pmc_core: Add option to set/clear LPM mode")
Cc: David E. Box <david.e.box@linux.intel.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210419143109.30612-1-hdegoede@redhat.com

Add touchscreen info for the Teclast Tbook 11 tablet. This includes info
for getting the firmware directly from the UEFI, so that the user does
not need to manually install the firmware in /lib/firmware/silead.

This change will make the touchscreen on these devices work OOTB,
without requiring any manual setup.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210417173105.4134-1-hdegoede@redhat.com

Alder PCH-P is based on Tiger Lake PCH.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-10-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Just like Ice Lake, Tiger Lake uses Cannon Lake's LTR information
and supports a few additional registers. Hence add the LTR registers
specific to Tiger Lake to the cnp_ltr_show_map[].

Also adjust the number of LTR IPs for Tiger Lake to the correct amount.
Signed-off-by: NGayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-9-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

By default the Low Power Mode (LPM or sub-state) status registers will
latch condition status on every entry into Package C10. This is
configurable in the PMC to allow latching on any achievable sub-state. Add
a debugfs file to support this.

Also add the option to clear the status registers to 0. Clearing the status
registers before testing removes ambiguity around when the current values
were set.

The new file, latch_lpm_mode, looks like this:

	[c10] S0i2.0 S0i3.0 S0i2.1 S0i3.1 S0i3.2 clear
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-8-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add the debugfs file, substate_requirements, to view the low power mode
(LPM) requirements for each enabled mode alongside the last latched status
of the condition.

After this patch, the new file will look like this:

                    Element |    S0i2.0 |    S0i3.0 |    S0i2.1 |    S0i3.1 |    S0i3.2 |    Status |
            USB2PLL_OFF_STS |  Required |  Required |  Required |  Required |  Required |           |
PCIe/USB3.1_Gen2PLL_OFF_STS |  Required |  Required |  Required |  Required |  Required |           |
       PCIe_Gen3PLL_OFF_STS |  Required |  Required |  Required |  Required |  Required |       Yes |
            OPIOPLL_OFF_STS |  Required |  Required |  Required |  Required |  Required |       Yes |
              OCPLL_OFF_STS |  Required |  Required |  Required |  Required |  Required |       Yes |
            MainPLL_OFF_STS |           |  Required |           |  Required |  Required |           |
Signed-off-by: NGayatri Kammela <gayatri.kammela@intel.com>
Co-developed-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-7-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Platforms that support low power modes (LPM) such as Tiger Lake maintain
requirements for each sub-state that a readable in the PMC. However, unlike
LPM status registers, requirement registers are not memory mapped but are
available from an ACPI _DSM. Collect the requirements for Tiger Lake using
the _DSM method and store in a buffer.
Signed-off-by: NGayatri Kammela <gayatri.kammela@intel.com>
Co-developed-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-6-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Modify the low power mode (LPM or sub-state) residency counters to display
in microseconds just like the slp_s0_residency counter. The granularity of
the counter is approximately 30.5us per tick. Double this value then divide
by two to maintain accuracy.
Signed-off-by: NGayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-5-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The current implementation of pmc_core_substate_res_show() is written
specifically for Tiger Lake. However, new platform will also have
sub-states and may support different modes. Therefore rewrite the code to
handle sub-states generically.

Obtain the number and type of enabled states form the PMC. Use the Low
Power Mode (LPM) priority register to store the states in order from
shallowest to deepest for displays. Add a for_each macro to simplify
this. While changing the sub-state display it makes sense to show only the
"enabled" sub-states instead of showing all possible ones. After this
patch, the debugfs file looks like this:

Substate   Residency
S0i2.0     0
S0i3.0     0
S0i2.1     9329279
S0i3.1     0
S0i3.2     0
Suggested-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NGayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-4-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The intel_pmc_core driver did not always bind to a device which meant it
lacked a struct device that could be used to maintain driver data. So a
global instance of struct pmc_dev was used for this purpose and functions
accessed this directly. Since the driver now binds to an ACPI device,
remove the global pmc_dev in favor of one that is allocated during probe.
Modify users of the global to obtain the object by argument instead.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-3-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The DMI callbacks, used for quirks, currently access the PMC by getting
the address a global pmc_dev struct. Instead, have the callbacks set a
global quirk specific variable. In probe, after calling dmi_check_system(),
pass pmc_dev to a function that will handle each quirk if its variable
condition is met. This allows removing the global pmc_dev later.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Coccinelle noticed:
  drivers/platform/x86/intel_chtdc_ti_pwrbtn.c:59:7-32: ERROR: Threaded IRQ
with no primary handler requested without IRQF_ONESHOT
Signed-off-by: NGuangqing Zhu <zhuguangqing83@gmail.com>
Link: https://lore.kernel.org/r/20210415091435.10486-1-zhuguangqing83@gmail.comTested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Add the X570 AORUS ELITE to gigabyte_wmi_known_working_platforms
Signed-off-by: NJulian Labus <julian@labus-online.de>
Acked-By: NThomas Weißschuh <thomas@weissschuh.net>
Link: https://lore.kernel.org/r/20210415074526.1782-1-julian@labus-online.deSigned-off-by: NHans de Goede <hdegoede@redhat.com>

On EC version 3, the first 2 temperature sensors are always CPU and GPU
add labels for these.

This changes e.g. the "sensors" command output on a X1C8 from:

thinkpad-isa-0000
Adapter: ISA adapter
fan1:        2694 RPM
temp1:        +42.0°C
temp2:            N/A
temp3:        +33.0°C
temp4:         +0.0°C
temp5:        +35.0°C
temp6:        +42.0°C
temp7:        +42.0°C
temp8:            N/A

into:

thinkpad-isa-0000
Adapter: ISA adapter
fan1:        2694 RPM
CPU:          +42.0°C
GPU:              N/A
temp3:        +33.0°C
temp4:         +0.0°C
temp5:        +35.0°C
temp6:        +42.0°C
temp7:        +42.0°C
temp8:            N/A
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210413072112.183550-1-hdegoede@redhat.com

platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table

pmc_plt_clk* clocks are used for ethernet controllers, so need to stay
turned on. This adds the affected board family to critclk_systems DMI
table, so the clocks are marked as CLK_CRITICAL and not turned off.

This replaces the previously listed boards with a match for the whole
device family CBxx63. CBxx63 matches only baytrail devices.
There are new affected boards that would otherwise need to be listed.
There are unaffected boards in the family, but having the clocks
turned on is not an issue.

Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NSteffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Tested with
* X570 I Aorus Pro Wifi (rev 1.0)
* B550M DS3H
* B550 Gaming X V2 (rev.1.x)
* Z390 I AORUS PRO WIFI (rev. 1.0)

Those mainboards contain an ITE chips for management and
monitoring.

They could also be handled by drivers/hwmon/i87.c.
But the SuperIO range used by i87 is already claimed and used by the
firmware.

The following warning is printed at boot:

kernel: ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20200528/utaddress-204)
kernel: ACPI: This conflict may cause random problems and system instability
kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

This driver implements such an ACPI driver.

Unfortunately not all sensor registers are handled by the firmware and even
less are exposed via WMI.
Signed-off-by: NThomas Weißschuh <linux@weissschuh.net>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210412123513.628901-1-linux@weissschuh.netReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

During PCH (platform/board) manufacturing process a global platform
reset has to be induced in order for the configuration changes take
the effect upon following platform reset. This is an internal platform
state and is not intended to be used in the regular platform resets.
The setting is exposed via ETR3 (Extended Test Mode Register 3).
After the manufacturing process is completed the register cannot be
written anymore and is hardware locked.
This setting was commonly done by accessing PMC registers via /dev/mem
but due to security concerns /dev/mem access is much more restricted,
hence the reason for exposing this setting via the dedicated sysfs
interface.
To prevent post manufacturing abuse the register is protected
by hardware locking and the file is set to read-only mode via is_visible
handler.

The register in MMIO space is defined for Cannon Lake and newer PCHs.

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: David E Box <david.e.box@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTamar Mashiah <tamar.mashiah@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20210411141532.3004893-1-tomas.winkler@intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).

Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.

Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.
Signed-off-by: NMark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.

this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NMaximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/1617778852-26492-1-git-send-email-tiantao6@hisilicon.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.

this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Acked-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/1617785983-28878-1-git-send-email-tiantao6@hisilicon.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The BIOS team have added a new API that allows us to retrieve the
current performance profile without having to disable/enable CQL
mode. Adding the changes to use this API.

Tested on P15 and X1C8
Signed-off-by: NMark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210406233203.232860-1-markpearson@lenovo.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Sometimes, the "base connected" event that we rely on to (re-)attach the
device connected to the base is sent a bit too early. When this happens,
some devices may not be completely ready yet.

Specifically, the battery has been observed to report zero-values for
things like full charge capacity, which, however, is only loaded once
when the driver for that device probes. This can thus result in battery
readings being unavailable.

As we cannot easily and reliably discern between devices that are not
ready yet and devices that are not connected (i.e. will never be ready),
delay adding these devices. This should give them enough time to set up.

The delay is set to 2.5 seconds, which should give us a good safety
margin based on testing and still be fairly responsive for users.

To achieve that delay switch to updating via a delayed work struct,
which means that we can also get rid of some locking.
Signed-off-by: NMaximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210405231222.358113-1-luzmaximilian@gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

So that I can always be reached in the future if necessary, add a
personal email address.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Link: https://lore.kernel.org/r/20210401162206.26901-4-mario.limonciello@dell.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

This driver is maintained by Dell, but it was missing in MAINTAINERS.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Link: https://lore.kernel.org/r/20210401162206.26901-3-mario.limonciello@dell.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

In some cases when firmware is busy or updating, some mailbox commands
still timeout on some newer CPUs. To fix this issue, change how we
process timeout.

With this change, replaced timeout from using simple count with real
timeout in micro-seconds using ktime. When the command response takes
more than average processing time, yield to other tasks. The worst case
timeout is extended upto 1 milli-second.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Make init_bios_attributes() ACPI object parsing more robust:
1. Always check that the type of the return ACPI object is package, rather
   then only checking this for instance_id == 0
2. Check that the package has the minimum amount of elements which will
   be consumed by the populate_foo_data() for the attr_type

Note/TODO: The populate_foo_data() functions should also be made more
robust. The should check the type of each of the elements matches the
type which they expect and in case of populate_enum_data()
obj->package.count should be passed to it as an argument and it should
re-check this itself since it consume a variable number of elements.

Fixes: e8a60aa7 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com

The variable result is being assigned a value that is never
read and it is being updated later with a new value. The
assignment is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210326192022.623001-1-colin.king@canonical.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The "&client->ddev->lock" and "&ddev->lock" are the same thing.  Let's
use "&ddev->lock" consistently.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMaximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/YF3TgCcpcCYl3a//@mwandaSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Now that we have 2 separate input_dev-s for the buttons and the switches,
this is no longer used, remove it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210325123255.73103-1-hdegoede@redhat.com

* On recent ZenBooks the fn-lock is disabled
  by default on boot while running Windows.

* Add a module param ( fnlock_default ) that allows
  changing the default at probe time
Signed-off-by: NLuca Stefani <luca.stefani.ge1@gmail.com>
Link: https://lore.kernel.org/r/20210323210126.145286-1-luca.stefani.ge1@gmail.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Advantech sw_button is a ACPI event trigger button.

With this driver, we can report KEY_PROG1 on the
Advantech Tabletop Network Appliances products and it has been
tested in FWA1112VC.

Add the software define button support to report EV_REP key_event
(KEY_PROG1) by pressing button that could be get on user
interface and trigger the customized actions.
Signed-off-by: NAndrea.Ho <Andrea.Ho@advantech.com.tw>
Link: https://lore.kernel.org/r/20210319034427.23222-1-andrea.cs97g@nctu.edu.twReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Some devices send (duplicate) tablet-mode events when moved around even
though the mode has not changed; and they do this even when suspended.

Change the tablet-mode event handling when priv->wakeup_mode is set to
update the switch state in case it changed and then return immediately
(without calling pm_wakeup_hard_event()) to avoid spurious wakeups.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537
Fixes: 537b0dd4 ("platform/x86: intel-hid: Add support for SW_TABLET_MODE")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NElia Devito <eliadevito@gmail.com>
Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com

Some devices send (duplicate) tablet-mode events when moved around even
though the mode has not changed; and they do this even when suspended.

Change the tablet-mode event handling when priv->wakeup_mode is set to
update the switch state in case it changed and then return immediately
(without calling pm_wakeup_hard_event()) to avoid spurious wakeups.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537
Fixes: 537b0dd4 ("platform/x86: intel-hid: Add support for SW_TABLET_MODE")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NElia Devito <eliadevito@gmail.com>
Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com

Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle.  Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NSasha Neftin <sasha.neftin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Reviewed-by: NRajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The intel_pmc_core driver is mostly used as a debugging driver for Intel
platforms that support SLPS0 (S0ix). But the driver may also be used to
communicate actions to the PMC in order to ensure transition to SLPS0 on
some systems and architectures. As such the driver should be built on all
platforms it supports. Indicate this in the Kconfig. Also update the list
of supported features.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Suggested-by: NMario Limonciello <mario.limonciello@dell.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-1-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Fixes off-by-one bugs in the macro assignments for the crashlog control
bits. Was initially tested on emulation but bug revealed after testing on
silicon.

Fixes: 5ef9998c ("platform/x86: Intel PMT Crashlog capability driver")
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Link: https://lore.kernel.org/r/20210317024455.3071477-2-david.e.box@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>