kernel/linux.git/drivers/platform, branch linux-5.11.y

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

2021-05-14T08:49:49+00:00

[ Upstream commit d21e5abd3a005253eb033090aab2e43bce090d89 ] 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: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reviewed-by: Andy Shevchenko Signed-off-by: Steffen Dirkwinkel Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: dell-wmi-sysman: Make init_bios_attributes() ACPI object parsing more robust

2021-05-14T08:49:45+00:00

[ Upstream commit 5e3f5973c8dfd2b80268f1825ed2f2ddf81d3267 ] 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: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi Cc: Mario Limonciello Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com Signed-off-by: Sasha Levin

platform/x86: intel_pmc_core: Don't use global pmcdev in quirks

2021-05-12T06:37:18+00:00

[ Upstream commit c9f86d6ca6b5e23d30d16ade4b9fff5b922a610a ] 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: David E. Box Reviewed-by: Hans de Goede Reviewed-by: Rajneesh Bhardwaj Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: ISST: Account for increased timeout in some cases

2021-05-12T06:37:16+00:00

[ Upstream commit 5c782817a981981917ec3c647cf521022ee07143 ] 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: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: thinkpad_acpi: Correct thermal sensor allocation

2021-05-07T09:11:25+00:00

commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream. 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: Mark Pearson Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events during suspend

2021-04-14T06:47:23+00:00

[ Upstream commit a3790a8a94fc0234c5d38013b48e74ef221ec84c ] 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: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede Reviewed-by: Elia Devito Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com Signed-off-by: Sasha Levin

platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms

2021-04-10T11:38:58+00:00

[ Upstream commit d1635448f1105e549b4041aab930dbc6945fc635 ] 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: David E. Box Reviewed-by: Sasha Neftin Cc: intel-wired-lan@lists.osuosl.org Reviewed-by: Rajneesh Bhardwaj Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: intel_pmt_class: Initial resource to 0

2021-04-10T11:38:57+00:00

[ Upstream commit 7547deff8a221e6bf1e563cf1b636844a8e5378a ] Initialize the struct resource in intel_pmt_dev_register to zero to avoid a fault should the char *name field be non-zero. Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20210317024455.3071477-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

2021-04-10T11:38:57+00:00

[ Upstream commit 3d677f12ea3a2097a16ded570623567403dea959 ] On many recent ThinkPad laptops, there's a new LED next to the ESC key, that indicates the FnLock status. When the Fn+ESC combo is pressed, FnLock is toggled, which causes the Media Key functionality to change, making it so that the media keys either perform their media key function, or function as an F-key by default. The Fn key can be used the access the alternate function at any time. With the current linux kernel, the LED doens't change state if you press the Fn+ESC key combo. However, the media key functionality *does* change. This is annoying, since the LED will stay on if it was on during bootup, and it makes it hard to keep track what the current state of the FnLock is. This patch calls an ACPI function, that gets the current media key state, when the Fn+ESC key combo is pressed. Through testing it was discovered that this function causes the LED to update correctly to reflect the current state when this function is called. The relevant ACPI calls are the following: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it. Relevant discussion: https://bugzilla.kernel.org/show_bug.cgi?id=207841 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 Signed-off-by: Esteve Varela Colominas Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2

2021-04-10T11:38:54+00:00

[ Upstream commit 56678a5f44ef5f0ad9a67194bbee2280c6286534 ] Like a few other system the Lenovo ThinkPad X1 Tablet Gen 2 miss the HEBC method, which prevent the power button from working. Add a quirk to enable the button array on this system family and fix the power button. Signed-off-by: Alban Bedel Tested-by: Alexander Kobel Link: https://lore.kernel.org/r/20210222141559.3775-1-albeu@free.fr Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin