kernel.git/drivers/platform/x86/Kconfig, branch linux-5.14.y

platform/x86: Add and use a dual_accel_detect() helper

2021-07-29T11:14:07Z

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 Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com

platform/x86: intel_cht_int33fe: Move to its own subfolder

2021-06-22T09:32:30Z

Since we have started collecting Intel x86 specific drivers in their own folder, move intel_cht_int33fe to its own subfolder there. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210618125516.53510-8-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede

platform/x86: intel_skl_int3472: Move to intel/ subfolder

2021-06-22T09:32:02Z

Start collecting Intel x86 related drivers in its own subfolder. Move intel_skl_int3472 first. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210618125516.53510-7-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede

platform/x86: Remove "default n" entries

2021-06-22T09:05:08Z

Linus already once did that for PDx86, don't repeat our mistakes. TL;DR: 'n' *is* the default 'default'. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210618125516.53510-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede

platform/x86: Add intel_skl_int3472 driver

2021-06-16T15:49:53Z

ACPI devices with _HID INT3472 are currently matched to the tps68470 driver, however this does not cover all situations in which that _HID occurs. We've encountered three possibilities: 1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing a physical TPS68470 device) that requires a GPIO and OpRegion driver 2. On devices designed for Windows, an ACPI device with _HID INT3472 (again representing a physical TPS68470 device) which requires GPIO, Clock and Regulator drivers. 3. On other devices designed for Windows, an ACPI device with _HID INT3472 which does **not** represent a physical TPS68470, and is instead used as a dummy device to group some system GPIO lines which are meant to be consumed by the sensor that is dependent on this entry. This commit adds a new module, registering a platform driver to deal with the 3rd scenario plus an i2c driver to deal with #1 and #2, by querying the CLDB buffer found against INT3472 entries to determine which is most appropriate. Suggested-by: Laurent Pinchart Signed-off-by: Daniel Scally Link: https://lore.kernel.org/r/20210603224007.120560-6-djrscally@gmail.com [hdegoede@redhat.com Make skl_int3472_tps68470_calc_type() static] Signed-off-by: Hans de Goede

platform/x86: think-lmi: Add WMI interface support on Lenovo platforms

2021-06-16T15:47:52Z

For Lenovo platforms that support a WMI interface to the BIOS add support, using the firmware-attributes class, to allow users to access and modify various BIOS related settings. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20210530223111.25929-3-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: firmware_attributes_class: Create helper file for handling firmware-attributes class registration events

2021-06-16T15:47:51Z

This offers shared code for registering the firmware_attributes_class, which is used by the Dell and Lenovo WMI management drivers. Reported-by: kernel test robot Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20210530223111.25929-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: Rename hp-wireless to wireless-hotkey

2021-06-16T15:47:49Z

This driver was originally intended to support some HP laptops, but later support was added for Xioami and AMD laptops. Rename it to make it clear that it supports a larger variety of systems. Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20210519174405.30155-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede

platform/x86: intel_int0002_vgpio: Only call enable_irq_wake() when using s2idle

2021-05-19T13:59:47Z

Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") stopped passing irq_set_wake requests on to the parents IRQ because this was breaking suspend (causing immediate wakeups) on an Asus E202SA. This workaround for the Asus E202SA is causing wakeup by USB keyboard to not work on other devices with Airmont CPU cores such as the Medion Akoya E1239T. In hindsight the problem with the Asus E202SA has nothing to do with Silvermont vs Airmont CPU cores, so the differentiation between the 2 types of CPU cores introduced by the previous fix is wrong. The real issue at hand is s2idle vs S3 suspend where the suspend is mostly handled by firmware. The parent IRQ for the INT0002 device is shared with the ACPI SCI and the real problem is that the INT0002 code should not be messing with the wakeup settings of that IRQ when suspend/resume is being handled by the firmware. Note that on systems which support both s2idle and S3 suspend, which suspend method to use can be changed at runtime. This patch fixes both the Asus E202SA spurious wakeups issue as well as the wakeup by USB keyboard not working on the Medion Akoya E1239T issue. These are both fixed by replacing the old workaround with delaying the enable_irq_wake(parent_irq) call till system-suspend time and protecting it with a !pm_suspend_via_firmware() check so that we still do not call it on devices using firmware-based (S3) suspend such as the Asus E202SA. Note rather then adding #ifdef CONFIG_PM_SLEEP, this commit simply adds a "depends on PM_SLEEP" to the Kconfig since this drivers whole purpose is to deal with wakeup events, so using it without CONFIG_PM_SLEEP makes no sense. Cc: Maxim Mikityanskiy Fixes: 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20210512125523.55215-2-hdegoede@redhat.com

platform/x86: intel_pmc_core: add ACPI dependency

2021-04-21T14:11:44Z

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: 428131364f00 ("platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210421134957.3329062-1-arnd@kernel.org Signed-off-by: Hans de Goede