linux-stable.git/drivers/platform, branch v5.17.2

platform/x86: asus-wmi: Fix regression when probing for fan curve control

2022-04-08T11:58:58+00:00

commit d717e4509af0380a94dbc28b61839df39f17e1eb upstream.

The fan curve control patches introduced a regression for at least the
TUF FX506 and possibly other TUF series laptops that do not have support
for fan curve control.

As part of the probing process, asus_wmi_evaluate_method_buf is called
to get the factory default fan curve . The WMI management function
returns 0 on certain laptops to indicate lack of fan curve control
instead of ASUS_WMI_UNSUPPORTED_METHOD. This 0 is transformed to
-ENODATA which results in failure when probing.

Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves")
Reported-and-tested-by: Abhijeet V 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20220205112840.33095-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman

platform/chrome: cros_ec_typec: Check for EC device

2022-04-08T11:58:58+00:00

commit ffebd90532728086007038986900426544e3df4e upstream.

The Type C ACPI device on older Chromebooks is not generated correctly
(since their EC firmware doesn't support the new commands required). In
such cases, the crafted ACPI device doesn't have an EC parent, and it is
therefore not useful (it shouldn't be generated in the first place since
the EC firmware doesn't support any of the Type C commands).

To handle devices which use these older firmware revisions, check for
the parent EC device handle, and fail the probe if it's not found.

Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver")
Reported-by: Alyssa Ross 
Reviewed-by: Tzung-Bi Shih 
Signed-off-by: Prashant Malani 
Acked-by: Heikki Krogerus 
Reviewed-by: Alyssa Ross 
Tested-by: Alyssa Ross 
Link: https://lore.kernel.org/r/20220126190219.3095419-1-pmalani@chromium.org
Signed-off-by: Benson Leung 
Signed-off-by: Greg Kroah-Hartman

platform: chrome: Split trace include file

2022-04-08T11:58:51+00:00

commit eabd9a3807e17e211690e6c40f1405b427b64c48 upstream.

cros_ec_trace.h defined 5 tracing events, 2 for cros_ec_proto and
3 for cros_ec_sensorhub_ring.
These 2 files are in different kernel modules, the traces are defined
twice in the kernel which leads to problem enabling only some traces.

Move sensorhub traces from cros_ec_trace.h to cros_ec_sensorhub_trace.h
and enable them only in cros_ec_sensorhub kernel module.

Check we can now enable any single traces: without this patch,
we can only enable all sensorhub traces or none.

Fixes: d453ceb6549a ("platform/chrome: sensorhub: Add trace events for sample")

Signed-off-by: Gwendal Grignou 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220122001301.640337-1-gwendal@chromium.org
Signed-off-by: Benson Leung 
Signed-off-by: Greg Kroah-Hartman

platform/x86: huawei-wmi: check the return value of device_create_file()

2022-04-08T11:58:16+00:00

[ Upstream commit c91a5b1c221a58d008485cf7d02ccce73108b119 ]

The function device_create_file() in huawei_wmi_battery_add() can fail,
so its return value should be checked.

Fixes: 355a070b09ab ("platform/x86: huawei-wmi: Add battery charging thresholds")
Reported-by: TOTE Robot 
Signed-off-by: Jia-Ju Bai 
Link: https://lore.kernel.org/r/20220303022421.313-1-baijiaju1990@gmail.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Signed-off-by: Sasha Levin

surface: surface3_power: Fix battery readings on batteries without a serial number

2022-02-24T12:48:39+00:00

The battery on the 2nd hand Surface 3 which I recently bought appears to
not have a serial number programmed in. This results in any I2C reads from
the registers containing the serial number failing with an I2C NACK.

This was causing mshw0011_bix() to fail causing the battery readings to
not work at all.

Ignore EREMOTEIO (I2C NACK) errors when retrieving the serial number and
continue with an empty serial number to fix this.

Fixes: b1f81b496b0d ("platform/x86: surface3_power: MSHW0011 rev-eng implementation")
BugLink: https://github.com/linux-surface/linux-surface/issues/608
Reviewed-by: Benjamin Tissoires 
Reviewed-by: Maximilian Luz 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20220224101848.7219-1-hdegoede@redhat.com

platform/x86: amd-pmc: Set QOS during suspend on CZN w/ timer wakeup

2022-02-24T12:48:34+00:00

commit 59348401ebed ("platform/x86: amd-pmc: Add special handling for
timer based S0i3 wakeup") adds support for using another platform timer
in lieu of the RTC which doesn't work properly on some systems. This path
was validated and worked well before submission. During the 5.16-rc1 merge
window other patches were merged that caused this to stop working properly.

When this feature was used with 5.16-rc1 or later some OEM laptops with the
matching firmware requirements from that commit would shutdown instead of
program a timer based wakeup.

This was bisected to commit 8d89835b0467 ("PM: suspend: Do not pause
cpuidle in the suspend-to-idle path").  This wasn't supposed to cause any
negative impacts and also tested well on both Intel and ARM platforms.
However this changed the semantics of when CPUs are allowed to be in the
deepest state. For the AMD systems in question it appears this causes a
firmware crash for timer based wakeup.

It's hypothesized to be caused by the `amd-pmc` driver sending `OS_HINT`
and all the CPUs going into a deep state while the timer is still being
programmed. It's likely a firmware bug, but to avoid it don't allow setting
CPUs into the deepest state while using CZN timer wakeup path.

If later it's discovered that this also occurs from "regular" suspends
without a timer as well or on other silicon, this may be later expanded to
run in the suspend path for more scenarios.

Cc: stable@vger.kernel.org # 5.16+
Suggested-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/linux-acpi/BL1PR12MB51570F5BD05980A0DCA1F3F4E23A9@BL1PR12MB5157.namprd12.prod.outlook.com/T/#mee35f39c41a04b624700ab2621c795367f19c90e
Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Fixes: 23f62d7ab25b ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions")
Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup"
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Mario Limonciello 
Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede

platform/x86: int3472: Add terminator to gpiod_lookup_table

2022-02-21T13:47:59+00:00

Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops.

Fixes: 19d8d6e36b4b ("platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell")
Signed-off-by: Daniel Scally 
Link: https://lore.kernel.org/r/20220216225304.53911-5-djrscally@gmail.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede

platform/x86: asus-wmi: Fix regression when probing for fan curve control

2022-02-05T13:46:08+00:00

The fan curve control patches introduced a regression for at least the
TUF FX506 and possibly other TUF series laptops that do not have support
for fan curve control.

As part of the probing process, asus_wmi_evaluate_method_buf is called
to get the factory default fan curve . The WMI management function
returns 0 on certain laptops to indicate lack of fan curve control
instead of ASUS_WMI_UNSUPPORTED_METHOD. This 0 is transformed to
-ENODATA which results in failure when probing.

Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves")
Reported-and-tested-by: Abhijeet V 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20220205112840.33095-1-hdegoede@redhat.com

platform/x86: thinkpad_acpi: Add dual-fan quirk for T15g (2nd gen)

2022-02-03T10:34:06+00:00

The ThinkPad T15g Gen 2 has 2 fan, add a TPACPI_FAN_2CTL quirk entry for
it to the fan_quirk_table[] so that both fans can be controllerd.

Reported-and-tested-by: David Dreschner 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20220203103302.49401-1-hdegoede@redhat.com

platform/x86: thinkpad_acpi: Fix incorrect use of platform profile on AMD platforms

2022-02-01T14:37:00+00:00

Lenovo AMD based platforms have been offering platform_profiles but they
are not working correctly. This is because the mode we are using on the
Intel platforms (MMC) is not available on the AMD platforms.

This commit adds checking of the functional capabilities returned by the
BIOS to confirm if MMC is supported or not. Profiles will not be
available if the platform is not MMC capable.

I'm investigating and working on an alternative for AMD platforms but
that is still work-in-progress.

Signed-off-by: Mark Pearson 
Link: https://lore.kernel.org/r/20220127190358.4078-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede 
Signed-off-by: Hans de Goede