summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)Author
2021-11-17platform/x86: thinkpad_acpi: Fix bitwise vs. logical warningNathan Chancellor
[ Upstream commit fd96e35ea7b95f1e216277805be89d66e4ae962d ] A new warning in clang points out a use of bitwise OR with boolean expressions in this driver: drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] else if ((strlencmp(cmd, "level disengaged") == 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning 1 error generated. This should clearly be a logical OR so change it to fix the warning. Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") Link: https://github.com/ClangBuiltLinux/linux/issues/1476 Reported-by: Tor Vic <torvic9@mailbox.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-17platform/x86: wmi: do not fail if disabling failsBarnabás Pőcze
[ Upstream commit 1975718c488a39128f1f515b23ae61a5a214cc3d ] Previously, `__query_block()` would fail if the second WCxx method call failed. However, the WQxx method might have succeeded, and potentially allocated memory for the result. Instead of throwing away the result and potentially leaking memory, ignore the result of the second WCxx call. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Link: https://lore.kernel.org/r/20210904175450.156801-25-pobrn@protonmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-17platform/surface: aggregator_registry: Add support for Surface Laptop StudioMaximilian Luz
commit 4f042e40199ce8bac6bc2b853e81744ee4ea759c upstream. Add support for the Surface Laptop Studio. In contrast to previous Surface Laptop models, this one has its HID devices attached to target ID 1 (instead of 2). It also has a couple more of them, including a new notifier for when the pen is stashed / taken out of its place, a "Sys Control" device, and two other unidentified HID devices with unknown usages. Battery and performance profile interfaces remain the same. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20211021130904.862610-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-27platform/x86: intel_scu_ipc: Update timeout value in commentPrashant Malani
[ Upstream commit a0c5814b9933f25ecb6de169483c5b88cf632bca ] The comment decribing the IPC timeout hadn't been updated when the actual timeout was changed from 3 to 5 seconds in commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") . Since the value is anyway updated to 10s now, take this opportunity to update the value in the comment too. Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-4-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-27platform/x86: intel_scu_ipc: Increase virtual timeout to 10sPrashant Malani
[ Upstream commit 5c02b581ce84eea240d25c8318a1f65133a04415 ] Commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") states that the recommended timeout range is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10 seconds, to account for situations where the 5 seconds is insufficient for disconnect command success. Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-3-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-20platform/x86: intel_scu_ipc: Fix busy loop expiry timePrashant Malani
commit 41512e4dc0b84525495e784295092592adb87f1b upstream. The macro IPC_TIMEOUT is already in jiffies (it is also used like that elsewhere in the file when calling wait_for_completion_timeout()). Don’t convert it using helper functions for the purposes of calculating the busy loop expiry time. Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”) Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributesVadim Pasternak
commit db9cc7d6f95e7d89b0ce57e785cfd9d67a7505d8 upstream. Fix shift argument for function rol32(). It should be provided in bits, while was provided in bytes. Fixes: 86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() callVadim Pasternak
commit 9b024201693e397441668cca0d2df7055fe572eb upstream. Change kstrtou32() argument 'base' to be zero instead of 'len'. It works by chance for setting one bit value, but it is not supposed to work in case value passed to mlxreg_io_attr_store() is greater than 1. It works for example, for: echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable But it will fail for: echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable, where n > 1. The flow for input buffer conversion is as below: _kstrtoull(const char *s, unsigned int base, unsigned long long *res) calls: rv = _parse_integer(s, base, &_res); For the second case, where n > 1: - _parse_integer() converts 's' to 'val'. For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3 'len' is set to 3 (string buffer 0x33 0x0a), etcetera. - 'base' is equal or greater then '2' (length of input buffer). As a result, _parse_integer() exits with result zero (rv): rv = 0; while (1) { ... if (val >= base)-> (2 >= 2) break; ... rv++; ... } And _kstrtoull() in their turn will fail: if (rv == 0) return -EINVAL; Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20platform/x86: amd-pmc: Add alternative acpi id for PMC controllerSachi King
commit c0d84d2c7c23e9cf23a5abdda40eeaa79eabfe69 upstream. The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. Include AMD0005 in the acpi id list. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Cc: <stable@vger.kernel.org> # 5.14+ Signed-off-by: Sachi King <nakato@nakato.io> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.io Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2Zephaniah E. Loss-Cutler-Hull
commit 0f607d6b227470456a69a37d7c7badea51d52844 upstream. This works just fine on my system. Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211005044855.1429724-1-zephaniah@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-09platform/x86: gigabyte-wmi: add support for B550I Aorus Pro AXTobias Jakobi
[ Upstream commit 6f6aab1caf6c7fef46852aaab03f4e8250779e52 ] Tested with a AMD Ryzen 7 5800X. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Acked-by: Thomas Weißschuh <thomas@weissschuh.net> Link: https://lore.kernel.org/r/20210921100702.3838-1-tjakobi@math.uni-bielefeld.de Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-09platform/x86: touchscreen_dmi: Update info for the Chuwi Hi10 Plus (CWI527) ↵Hans de Goede
tablet [ Upstream commit 196159d278ae3b49e7bbb7c76822e6008fd89b97 ] Add info for getting the firmware directly from the UEFI for the Chuwi Hi10 Plus (CWI527), 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. Also tweak the min and width/height values a bit for more accurate position reporting. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210905130210.32810-2-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-09platform/x86: touchscreen_dmi: Add info for the Chuwi HiBook (CWI514) tabletHans de Goede
[ Upstream commit 3bf1669b0e033c885ebcb1ddc2334088dd125f2d ] Add touchscreen info for the Chuwi HiBook (CWI514) 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: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210905130210.32810-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-07platform/x86/intel: hid: Add DMI switches allow listJosé Expósito
commit b201cb0ebe87b209e252d85668e517ac1929e250 upstream. Some devices, even non convertible ones, can send incorrect SW_TABLET_MODE reports. Add an allow list and accept such reports only from devices in it. Bug reported for Dell XPS 17 9710 on: https://gitlab.freedesktop.org/libinput/libinput/-/issues/662 Reported-by: Tobias Gurtzick <magic@wizardtales.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Tobias Gurtzick <magic@wizardtales.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20210920160312.9787-1-jose.exposito89@gmail.com [hdegoede@redhat.com: Check dmi_switches_auto_add_allow_list only once] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-30platform/x86: dell: fix DELL_WMI_PRIVACY dependencies & build errorRandy Dunlap
[ Upstream commit 5b72dafaca73b33416c82457ae615e6f2022e901 ] When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there is a linker error since the LEDS trigger code is built as a loadable module. This happens because DELL_WMI_PRIVACY is a bool that depends on a tristate (LEDS_TRIGGER_AUDIO=m), which can be dangerous. ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe': dell-wmi-privacy.c:(.text+0x3df): undefined reference to `ledtrig_audio_get' Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Perry Yuan <Perry.Yuan@dell.com> Cc: Dell.Client.Kernel@dell.com Cc: platform-driver-x86@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <mgross@linux.intel.com> Link: https://lore.kernel.org/r/20210918044829.19222-1-rdunlap@infradead.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-30platform/x86/intel: punit_ipc: Drop wrong use of ACPI_PTR()Andy Shevchenko
[ Upstream commit 349bff48ae0f5f8aa2075d0bdc2091a30bd634f6 ] ACPI_PTR() is more harmful than helpful. For example, in this case if CONFIG_ACPI=n, the ID table left unused which is not what we want. Instead of adding ifdeffery here and there, drop ACPI_PTR() and unused acpi.h. Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210827145310.76239-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-30platform/x86: amd-pmc: Increase the response register timeoutMario Limonciello
commit 3c3c8e88c8712bfe06cd10d7ca77a94a33610cd6 upstream. There have been reports of approximately a 0.9%-1.7% failure rate in SMU communication timeouts with s0i3 entry on some OEM designs. Currently the design in amd-pmc is to try every 100us for up to 20ms. However the GPU driver which also communicates with the SMU using a mailbox register which the driver polls every 1us for up to 2000ms. In the GPU driver this was increased by commit 055162645a40 ("drm/amd/pm: increase time out value when sending msg to SMU") Increase the maximum timeout used by amd-pmc to 2000ms to match this behavior. This has been shown to improve the stability for machines that randomly have failures. Cc: stable@kernel.org Reported-by: Julian Sikorski <belegdol@gmail.com> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1629 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210914020115.655-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-26platform/chrome: cros_ec_trace: Fix format warningsGwendal Grignou
[ Upstream commit 4665584888ad2175831c972c004115741ec799e9 ] Fix printf format issues in new tracing events. Fixes: 814318242687 ("platform/chrome: cros_ec_trace: Add fields to command traces") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20210830180050.2077261-1-gwendal@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26platform/chrome: sensorhub: Add trace events for sampleGwendal Grignou
[ Upstream commit d453ceb6549af8798913de6a20444cb7200fdb69 ] Add trace event to report samples and their timestamp coming from the EC. It allows to check if the timestamps are correct and the filter is working correctly without introducing too much latency. To enable these events: cd /sys/kernel/debug/tracing/ echo 1 > events/cros_ec/enable echo 0 > events/cros_ec/cros_ec_request_start/enable echo 0 > events/cros_ec/cros_ec_request_done/enable echo 1 > tracing_on cat trace_pipe Observe event flowing: irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ... irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ... Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18platform/chrome: cros_ec_proto: Send command again when timeout occursPatryk Duda
commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream. Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Patryk Duda <pdk@semihalf.com> Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18platform/x86: dell-smbios-wmi: Add missing kfree in error-exit from ↵Hans de Goede
run_smbios_call [ Upstream commit 0487d4fc42d7f31a56cfd9e2237f9ebd889e6112 ] As pointed out be Kees Cook if we return -EIO because the obj->type != ACPI_TYPE_BUFFER, then we must kfree the output buffer before the return. Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Reported-by: Kees Cook <keescook@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210826140822.71198-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18platform/x86: ISST: Fix optimization with use of numaSrinivas Pandruvada
[ Upstream commit d36d4a1d75d2a8bd14ec00d5cb0ce166f6886146 ] When numa is used to map CPU to PCI device, the optimized path to read from cached data is not working and still calls _isst_if_get_pci_dev(). The reason is that when caching the mapping, numa information is not available as it is read later. So move the assignment of isst_cpu_info[cpu].numa_node before calling _isst_if_get_pci_dev(). Fixes: aa2ddd242572 ("platform/x86: ISST: Use numa node id for cpu pci dev mapping") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210727165052.427238-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-18platform/x86: gigabyte-wmi: add support for B450M S2H V2Thomas Weißschuh
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-901207693 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210818164435.99821-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-18platform/x86: gigabyte-wmi: add support for X570 GAMING XThomas Weißschuh
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-12platform/x86: asus-nb-wmi: Add tablet_mode_sw=lid-flip quirk for the TP200sHans de Goede
The Asus TP200s / E205SA 360 degree hinges 2-in-1 supports reporting SW_TABLET_MODE info through the ASUS_WMI_DEVID_LID_FLIP WMI device-id. Add a quirk to enable this. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210812145513.39117-2-hdegoede@redhat.com
2021-08-12platform/x86: asus-nb-wmi: Allow configuring SW_TABLET_MODE method with a ↵Hans de Goede
module option Unfortunately we have been unable to find a reliable way to detect if and how SW_TABLET_MODE reporting is supported, so we are relying on DMI quirks for this. Add a module-option to specify the SW_TABLET_MODE method so that this can be easily tested without needing to rebuild the kernel. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210812145513.39117-1-hdegoede@redhat.com
2021-08-06platform/x86: pcengines-apuv2: Add missing terminating entries to ↵Hans de Goede
gpio-lookup tables The gpiod_lookup_table.table passed to gpiod_add_lookup_table() must be terminated with an empty entry, add this. Note we have likely been getting away with this not being present because the GPIO lookup code first matches on the dev_id, causing most lookups to skip checking the table and the lookups which do check the table will find a matching entry before reaching the end. With that said, terminating these tables properly still is obviously the correct thing to do. Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210806115515.12184-1-hdegoede@redhat.com
2021-08-06platform/x86: Make dual_accel_detect() KIOX010A + KIOX020A detect more robustHans de Goede
360 degree hinges devices with dual KIOX010A + KIOX020A accelerometers always have both a KIOX010A and a KIOX020A ACPI device (one for each accel). Theoretical some vendor may re-use some DSDT for a non-convertible stripping out just the KIOX020A ACPI device from the DSDT. Check that both ACPI devices are present to make the check more robust. Fixes: 153cca9caa81 ("platform/x86: Add and use a dual_accel_detect() helper") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210802141000.978035-1-hdegoede@redhat.com
2021-07-29platform/x86: Add and use a dual_accel_detect() helperHans de Goede
Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers to allow the OS to determine the angle between the display and the base of the device. On Windows these are read by a special HingeAngleService process which calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is in tablet- or laptop-mode. The firmware may use this to disable the kbd and touchpad to avoid spurious input in tablet-mode as well as to report SW_TABLET_MODE info to the OS. Since Linux does not call these undocumented methods, the SW_TABLET_MODE info reported by various pdx86 drivers is incorrect on these devices. Before this commit the intel-hid and thinkpad_acpi code already had 2 hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid reporting broken info. And now we also have a bug-report about the same problem in the intel-vbtn code. Since there are at least 3 different ACPI hardware-ids in play, add a new dual_accel_detect() helper which checks for all 3, rather then adding different hardware-ids to the drivers as bug-reports trickle in. Having shared code which checks all known hardware-ids is esp. important for the intel-hid and intel-vbtn drivers as these are generic drivers which are used on a lot of devices. The BOSC0200 hardware-id requires special handling, because often it is used for a single-accelerometer setup. Only in a few cases it refers to a dual-accel setup, in which case there will be 2 I2cSerialBus resources in the device's resource-list, so the helper checks for this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011 Reported-and-tested-by: Julius Lehmann <julius@devpi.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com
2021-07-28platform/x86: gigabyte-wmi: add support for B550 Aorus Elite V2Thomas Weißschuh
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-879398883 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210726153630.65213-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-28platform/x86: intel-hid: add Alder Lake ACPI device IDPing Bao
Alder Lake has a new ACPI ID for Intel HID event filter device. Signed-off-by: Ping Bao <ping.a.bao@intel.com> Link: https://lore.kernel.org/r/20210721225615.20575-1-ping.a.bao@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-17platform/x86: think-lmi: Fix possible mem-leaks on tlmi_analyze() error-exitHans de Goede
Fix 2 possible memleaks on error-exits from tlmi_analyze(): 1. If the kzalloc of pwd_power fails, then not only free the atributes, but also the allocated pwd_admin struct. 2. Freeing the attributes should also free the possible_values strings. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210717143607.3580-3-hdegoede@redhat.com
2021-07-17platform/x86: think-lmi: Split kobject_init() and kobject_add() callsHans de Goede
tlmi_sysfs_init() calls tlmi_release_attr() on errors which calls kobject_put() for attributes created by tlmi_analyze(), but if we bail early because of an error, then this means that some of the kobjects will not have been initialized yet; and we should thus not call kobject_put() on them. Switch from using kobject_init_and_add() inside tlmi_sysfs_init() to initializing all the created kobjects directly in tlmi_analyze() and only adding them from tlmi_sysfs_init(). This way all kobjects will always be initialized when tlmi_release_attr() gets called. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210717143607.3580-2-hdegoede@redhat.com
2021-07-17platform/x86: think-lmi: Move pending_reboot_attr to the attributes sysfs dirMark Pearson
Move the pending_reboot node under attributes dir where it should live, as documented in: Documentation/ABI/testing/sysfs-class-firmware-attributes. Also move the create / remove code to be together with the other code populating / cleaning the attributes sysfs dir. In the removal path this is necessary so that the remove is done before the kset_unregister(tlmi_priv.attribute_kset) call. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210717143607.3580-1-hdegoede@redhat.com
2021-07-17platform/x86: amd-pmc: Fix undefined reference to __udivdi3Shyam Sundar S K
It was reported that on i386 config ------ on i386: ld: drivers/platform/x86/amd-pmc.o: in function `s0ix_stats_show': amd-pmc.c:(.text+0x100): undefined reference to `__udivdi3' ------- The reason for this is that 64-bit integer division is not supported on 32-bit architecture. Use do_div macro to fix this. Fixes: b9a4fa6978be ("platform/x86: amd-pmc: Add support for logging s0ix counters") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested Link: https://lore.kernel.org/r/20210716153802.2929670-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-15platform/x86: amd-pmc: Fix missing unlock on error in amd_pmc_send_cmd()Yang Yingliang
Add the missing unlock before return from function amd_pmc_send_cmd() in the error handling case. Fixes: 95e1b60f8dc8 ("platform/x86: amd-pmc: Fix command completion code") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210715074327.1966083-1-yangyingliang@huawei.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: wireless-hotkey: remove hardcoded "hp" from the error messageAlex Hung
This driver is no longer specific to HP laptops so "hp" in the error message is no longer applicable. Signed-off-by: Alex Hung <alex.hung@canonical.com> Link: https://lore.kernel.org/r/20210710190810.313104-1-alex.hung@canonical.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Use return code on suspendMario Limonciello
Right now the driver will still return success even if the OS_HINT command failed to send to the SMU. In the rare event of a failure, the suspend should really be aborted here so that relevant logs can may be captured. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210707141647.8871-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Add new acpi id for future PMC controllersShyam Sundar S K
The upcoming PMC controller would have a newer acpi id, add that to the supported acpid device list. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-8-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Add support for ACPI ID AMDI0006Shyam Sundar S K
Some newer BIOSes have added another ACPI ID for the uPEP device. SMU statistics behave identically on this device. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-7-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Add support for logging s0ix countersShyam Sundar S K
Even the FCH SSC registers provides certain level of information about the s0ix entry and exit times which comes handy when the SMU fails to report the statistics via the mailbox communication. This information is captured via a new debugfs file "s0ix_stats". A non-zero entry in this counters would mean that the system entered the s0ix state. If s0ix entry time and exit time don't change during suspend to idle, the silicon has not entered the deepest state. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-6-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Add support for logging SMU metricsShyam Sundar S K
SMU provides a way to dump the s0ix debug statistics in the form of a metrics table via a of set special mailbox commands. Add support to the driver which can send these commands to SMU and expose the information received via debugfs. The information contains the s0ix entry/exit, active time of each IP block etc. As a side note, SMU subsystem logging is not supported on Picasso based SoC's. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-5-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: call dump registers only onceShyam Sundar S K
Currently amd_pmc_dump_registers() routine is being called at multiple places. The best to call it is after command submission to SMU. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-4-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Fix SMU firmware reporting mechanismShyam Sundar S K
It was lately understood that the current mechanism available in the driver to get SMU firmware info works only on internal SMU builds and there is a separate way to get all the SMU logging counters (addressed in the next patch). Hence remove all the smu info shown via debugfs as it is no more useful. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-3-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: amd-pmc: Fix command completion codeShyam Sundar S K
The protocol to submit a job request to SMU is to wait for AMD_PMC_REGISTER_RESPONSE to return 1,meaning SMU is ready to take requests. PMC driver has to make sure that the response code is always AMD_PMC_RESULT_OK before making any command submissions. When we submit a message to SMU, we have to wait until it processes the request. Adding a read_poll_timeout() check as this was missing in the existing code. Also, add a mutex to protect amd_pmc_send_cmd() calls to SMU. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-2-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-14platform/x86: think-lmi: Add pending_reboot supportMark Pearson
The Think-lmi driver was missing pending_reboot support as it wasn't available from the BIOS. Turns out this is really useful to have from user space so implementing from a purely SW point of view. Thanks to Mario Limonciello for guidance on how fwupd would use this. Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mark Pearson <markpearson@lenovo.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210628222846.8830-1-markpearson@lenovo.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-07-05Merge tag 'driver-core-5.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core changes from Greg KH: "Here is the small set of driver core and debugfs updates for 5.14-rc1. Included in here are: - debugfs api cleanups (touched some drivers) - devres updates - tiny driver core updates and tweaks Nothing major in here at all, and all have been in linux-next for a while with no reported issues" * tag 'driver-core-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (27 commits) docs: ABI: testing: sysfs-firmware-memmap: add some memmap types. devres: Enable trace events devres: No need to call remove_nodes() when there none present devres: Use list_for_each_safe_from() in remove_nodes() devres: Make locking straight forward in release_nodes() kernfs: move revalidate to be near lookup drivers/base: Constify static attribute_group structs firmware_loader: remove unneeded 'comma' macro devcoredump: remove contact information driver core: Drop helper devm_platform_ioremap_resource_wc() component: Rename 'dev' to 'parent' component: Drop 'dev' argument to component_match_realloc() device property: Don't check for NULL twice in the loops driver core: auxiliary bus: Fix typo in the docs drivers/base/node.c: make CACHE_ATTR define static DEVICE_ATTR_RO debugfs: remove return value of debugfs_create_ulong() debugfs: remove return value of debugfs_create_bool() scsi: snic: debugfs: remove local storage of debugfs files b43: don't save dentries for debugfs b43legacy: don't save dentries for debugfs ...
2021-06-30Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID updates from Jiri Kosina: - patch series that ensures that hid-multitouch driver disables touch and button-press reporting on hid-mt devices during suspend when the device is not configured as a wakeup-source, from Hans de Goede - support for ISH DMA on Intel EHL platform, from Even Xu - support for Renoir and Cezanne SoCs, Ambient Light Sensor and Human Presence Detection sensor for amd-sfh driver, from Basavaraj Natikar - other assorted code cleanups and device-specific fixes/quirks * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (45 commits) HID: thrustmaster: Switch to kmemdup() when allocate change_request HID: multitouch: Disable event reporting on suspend when the device is not a wakeup-source HID: logitech-dj: Implement may_wakeup ll-driver callback HID: usbhid: Implement may_wakeup ll-driver callback HID: core: Add hid_hw_may_wakeup() function HID: input: Add support for Programmable Buttons HID: wacom: Correct base usage for capacitive ExpressKey status bits HID: amd_sfh: Add initial support for HPD sensor HID: amd_sfh: Extend ALS support for newer AMD platform HID: amd_sfh: Extend driver capabilities for multi-generation support HID: surface-hid: Fix get-report request HID: sony: fix freeze when inserting ghlive ps3/wii dongles HID: usbkbd: Avoid GFP_ATOMIC when GFP_KERNEL is possible HID: amd_sfh: change in maintainer HID: intel-ish-hid: ipc: Specify that EHL no cache snooping HID: intel-ish-hid: ishtp: Add dma_no_cache_snooping() callback HID: intel-ish-hid: Set ISH driver depends on x86 HID: hid-input: add Surface Go battery quirk HID: intel-ish-hid: Fix minor typos in comments HID: usbmouse: Avoid GFP_ATOMIC when GFP_KERNEL is possible ...
2021-06-30Merge branch 'for-5.14/intel-ish' into for-linusJiri Kosina
- support for ISH DMA on EHL platform from Even Xu - various code style fixes and cleanups from Lee Jones and Uwe Kleine-König
2021-06-28platform/x86: dell-wmi-sysman: Change user experience when Admin/System ↵Prasanth KSR
Password is modified Whenever user has changed an Admin/System Password using the sysfs, then we are automatically copying the new password to existing password field. Co-developed-by: Divya Bharathi <divya.bharathi@dell.com> Signed-off-by: Divya Bharathi <divya.bharathi@dell.com> Signed-off-by: Prasanth KSR <prasanth.ksr@dell.com> Link: https://lore.kernel.org/r/20210628084906.4233-1-prasanth.ksr@dell.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>