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

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: 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: add Gigabyte WMI temperature driver

2021-04-13T08:13:49Z

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: Thomas Weißschuh Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210412123513.628901-1-linux@weissschuh.net Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: add support for Advantech software defined button

2021-04-07T17:46:56Z

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: Andrea.Ho Link: https://lore.kernel.org/r/20210319034427.23222-1-andrea.cs97g@nctu.edu.tw Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: Move all dell drivers to their own subdirectory

2021-02-04T12:23:55Z

A user without a Dell system doesn't need to pick any of these drivers. Users with a Dell system can enable this submenu and all drivers behind it will be enabled. Suggested-by: Andy Shevchenko Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20210203195832.2950605-1-mario.limonciello@dell.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: intel_scu_wdt: Move driver from arch/x86

2021-01-25T18:05:32Z

The ACPI-enabled Intel MID platforms neither have WDAT table nor proper IDs to instantiate watchdog device. In order to keep them working move the board code from arch/x86 to drivers/platform/x86. Note, the complete SFI support is going to be removed, that's why PDx86 has been chosen as a new home for it. This is the only device which needs additional code so far. Signed-off-by: Andy Shevchenko Reviewed-by: Guenter Roeck Reviewed-by: Hans de Goede Acked-by: Linus Walleij