aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi/pmic
diff options
context:
space:
mode:
authorDaniel Scally <djrscally@gmail.com>2021-06-03 23:40:06 +0100
committerHans de Goede <hdegoede@redhat.com>2021-06-16 17:49:53 +0200
commit5de691bffe57fd0fc2b4dcdcf13815c56d11db10 (patch)
treef7c03b1d956b7224c50984c9731f9b783b2e313e /drivers/acpi/pmic
parentMerge remote-tracking branch 'linux-pm/acpi-scan' into review-hans (diff)
downloadlinux-dev-5de691bffe57fd0fc2b4dcdcf13815c56d11db10.tar.xz
linux-dev-5de691bffe57fd0fc2b4dcdcf13815c56d11db10.zip
platform/x86: Add intel_skl_int3472 driver
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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> 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 <hdegoede@redhat.com>
Diffstat (limited to 'drivers/acpi/pmic')
0 files changed, 0 insertions, 0 deletions