summaryrefslogtreecommitdiff
path: root/drivers/platform/x86/intel/int3472/discrete.c
AgeCommit message (Collapse)Author
2026-07-08platform: int3472: discrete: con_id vana for Sony IMX471 as power enableKate Hsuan
Update the con_id for the Sony IMX471 sensor to "vana" to serve as the power enable. Additionally, the HID values SONY471A and TBE20A0, both associated with the IMX471 image sensor, have been identified on Lenovo laptops. Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-04-13platform/x86: int3472: Add support for GPIO type 0x02 (IR flood LED)Marco Nenciarini
Add support for GPIO type 0x02, which controls an IR flood LED used for face authentication on some laptops (e.g. Dell Pro Max 16 Premium). Without this patch, the kernel logs "GPIO type 0x02 unknown; the sensor may not work" and IR sensors paired with a flood LED cannot function. The flood LED is registered through the LED subsystem like the existing privacy LED, including a lookup entry to allow future consumer drivers to find and control it via led_get(). To support multiple LEDs per INT3472 device, convert the single led struct member to an array with a counter. Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260401203638.1601661-5-mnencia@kcore.it Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-10platform/x86: int3472: Parameterize LED con_id in registrationMarco Nenciarini
Add a con_id parameter to skl_int3472_register_led() to allow callers to specify both the LED name suffix and lookup con_id instead of hardcoding "privacy". This prepares for registering additional LED types with different names. While at it, rename the privacy LED's GPIO con_id from "privacy-led" to "privacy" in int3472_get_con_id_and_polarity() and pass it directly to skl_int3472_register_led(), reducing churn when adding new LED types. No functional change. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Link: https://patch.msgid.link/20260401203638.1601661-4-mnencia@kcore.it Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-10platform/x86: int3472: Rename pled to led in LED registration codeMarco Nenciarini
Rename the privacy LED type, struct member, and functions from "pled" to "led" in preparation for supporting additional LED types beyond just the privacy LED. No functional change. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Link: https://patch.msgid.link/20260401203638.1601661-3-mnencia@kcore.it Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-02-23platform/x86: int3472: Handle GPIO type 0x10 (DOVDD)Leif Skunberg
The Lenovo ThinkPad X1 Fold 16 Gen 1 has an OV5675 sensor (ACPI HID OVTI5675) behind an INT3472 discrete PMIC controller. The INT3472 _DSM returns GPIO type 0x10 for one of the pins, which controls the DOVDD (digital I/O power) regulator enable. Type 0x10 is not currently handled by the driver, causing the GPIO to be ignored with a warning. Add INT3472_GPIO_TYPE_DOVDD (0x10) and handle it as a regulator with con_id "dovdd" to match the supply name used by sensor drivers (e.g. ov5675). Also increase GPIO_SUPPLY_NAME_LENGTH from 5 to 6 to accommodate the "dovdd" name (5 chars + null terminator). Signed-off-by: Leif Skunberg <diamondback@cohunt.app> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260210132129.17943-1-diamondback@cohunt.app Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-02-21Convert 'alloc_flex' family to use the new default GFP_KERNEL argumentLinus Torvalds
This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2025-10-04Merge tag 'platform-drivers-x86-v6.18-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Ilpo Järvinen: - amd/pmf: - Add support for adjusting PMF PPT and PPT APU thresholds - Extend custom BIOS inputs for more policies - Update ta_pmf_action structure to the latest PMF TA - arm64: - thinkpad-t14s-ec: Add EC driver for ThinkPad T14s Gen6 Snapdragon - int3472: - Increase handshake GPIO delay - intel/pmc: - SSRAM support for Lunar Lake and Panther Lake - Support reading substate requirements data from S0ix blockers (for platforms starting from Panther Lake) - Wildcat Lake support - intel-uncore-freq: - Solve duplicate sysfs entry warnings - Present unique domain ID per package - portwell-ec: - Support suspend/resume - Add hwmon support for voltage and temperature - redmi-wmi: - Add WMI driver for Redmibook keyboard - think-lmi: - Certificate support for ThinkCenter - x86-android-tables + others: - Convert away from legacy GPIO APIs - x86-android-tables: - Add support for Acer A1-840 tablet - Fix modules list for Lenovo devices - Stop using EPROBE_DEFER - Miscellaneous cleanups / refactoring / improvements * tag 'platform-drivers-x86-v6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (63 commits) platform/x86: pcengines-apuv2: Use static device properties platform/x86: meraki-mx100: Use static device properties platform/x86: barco-p50-gpio: use software nodes for gpio-leds/keys platform/x86: x86-android-tablets: Stop using EPROBE_DEFER platform/x86: x86-android-tablets: Fix modules lists for Lenovo devices platform/x86: x86-android-tablets: Simplify lenovo_yoga_tab2_830_1050_exit() platform/x86: x86-android-tablets: Add support for Acer A1-840 tablet platform/x86: x86-android-tablets: Move Acer info to its own file platform/x86: x86-android-tablets: Update my email address platform/x86: x86-android-tablets: Simplify node-group [un]registration platform/x86: x86-android-tablets: use swnode_group instead of manual registering platform/x86: x86-android-tablets: replace bat_swnode with swnode_group platform/x86: x86-android-tablets: convert gpio_keys devices to GPIO references platform/x86: x86-android-tablets: remove support for GPIO lookup tables platform/x86: x86-android-tablets: convert Yoga Tab2 fast charger to GPIO references platform/x86: x86-android-tablets: convert HID-I2C devices to GPIO references platform/x86: x86-android-tablets: convert wm1502 devices to GPIO references platform/x86: x86-android-tablets: convert int3496 devices to GPIO references platform/x86: x86-android-tablets: convert EDT devices to GPIO references platform/x86: x86-android-tablets: convert Novatek devices to GPIO references ...
2025-08-19platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 msHans de Goede
On HP laptops with an ov08x40 sensor the 25 ms delay coming from Intel's out of tree drivers is not enough. Testing has confirmed that 45 ms does work. Add a quirk to the int3472_gpio_map[] to increase the delay to 45 ms to fix probing of the ov08x40 sensor failing on these laptops. Note this only impacts laptops which actually use an ov08x40 sensor with a handshake GPIO. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2333331 Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250725215259.402796-4-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-08-19platform/x86: int3472: Rework regulator enable-time handlingHans de Goede
Instead of hardcoding the regulator enable-time for INT3472_GPIO_TYPE- POWER_ENABLE and -HANDSHAKE, make int3472_get_con_id_and_polarity() set the enable-time. This will allow overriding the enable time through quirks in the int3472_gpio_map[]. Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250725215259.402796-3-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-08-19platform/x86: int3472: Convert int3472_gpio_map to use C99 initializersHans de Goede
Convert int3472_gpio_map to use C99 initializers to make it clearer which struct field is set to which value. Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250725215259.402796-2-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-08-18platform/x86: int3472: add hpd pin supportDongcheng Yan
Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is being received. On the host side this is wired to a GPIO for polling or interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges lt6911uxe and lt6911uxc. The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it here as well. Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: 20244cbafbd6 ("media: i2c: change lt6911uxe irq_gpio name to "hpd"") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-05-08platform/x86: int3472: For mt9m114 sensors map powerdown to powerenableHans de Goede
mt9m114 atomisp designs declare both reset and powerdown pins in their GPIO type DSM, but the mt9m114 only has a reset pin. The powerdown pin seems to control the regulators suppyling power to the sensor and the privacy LED. Add a mapping of powerdown to powerenable for the mt9m114 for this. While at is also add a comment to document the ov7251 mapping. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250507184737.154747-6-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08platform/x86: int3472: Export int3472_discrete_parse_crs()Hans de Goede
At the moment the atomisp has duplicate code for parsing Intel camera sensor GPIOS and calling the special 79234640-9e10-4fea-a5c1-b5aa8b19756f _DSM to get the GPIO type and map it to the sensor. Export int3472_discrete_parse_crs() so that the atomisp driver can reuse the INT3472 code for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250507184737.154747-4-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08platform/x86: int3472: Stop using devm_gpiod_get()Hans de Goede
The intent is to re-use the INT3472 code for parsing Intel camera sensor GPIOs and mapping them to the sensor for the atomisp driver, which currently has duplicate code. On atomisp devices there is no special INT3472 ACPI device, instead the Intel _DSM to get the GPIO type is part of the ACPI device for the sensor itself. To deal with this the mapping is done from ipu_bridge_init() instead of from a platform-device probe() function, there is no device to tie the lifetime of the gpiod_get() calls done by the INT3472 code to. Switch from devm_gpiod_get() to plain gpiod_get() + explicit gpiod_put() calls, to prepare for the code being re-used in the atomisp driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250507184737.154747-3-hdegoede@redhat.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08platform/x86: int3472: Move common.h to public includes, symbols to ↵Hans de Goede
INTEL_INT3472 Move the common.h header file to include/linux/platform_data/x86/int3472.h and add a "INTEL_INT3472" kernel-symbol-namespace to the exported symbols. This is a preparation patch for exporting some more symbols for re-use in the atomisp driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20250507184737.154747-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-24platform/x86: int3472: Debug log when remapping pinsHans de Goede
Debug log when remapping a pin/function because of a int3472_gpio_map[] match. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440 Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250417111337.38142-10-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-24platform/x86: int3472: Add handshake pin supportHans de Goede
New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12 pin defined in the INT3472 sensor companion device which describes the sensor's GPIOs. This pin is primarily used on designs with a Lattice FPGA chip which is capable of running the sensor independently of the main CPU for features like presence detection. This pin needs to be driven high to make the FPGA run the power-on sequence of the sensor. After driving the pin high, the FPGA "firmware" needs 25ms to complete the power-on sequence. Add support for this modelling the handshake pin as a GPIO driven "dvdd" regulator with a 25 ms enable time. This model was chosen because: 1. Sensor chips don't have a handshake pin, so we need to abstract this in some way which does not require modification to the sensor drivers, sensor drivers using the bulk-regulator API to get avdd + vddio + dvdd is normal. So this will work to get the right value set to the handshake pin without requiring sensor driver modifications. 2. Sensors typically wait only a small time for the sensor to power-on after de-asserting reset. Not the 25ms the Lattice chip requires. Using the regulator framework's enable_time allows hiding the need for this delay from the sensor drivers. Link: https://lore.kernel.org/platform-driver-x86/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/ Link: https://bugzilla.redhat.com/show_bug.cgi?id=2341731 Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440 Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250417111337.38142-9-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-24platform/x86: int3472: Avoid GPIO regulator spikesHans de Goede
Avoid the GPIO controlling the avdd regulator being driven low or high for a very short time leading to spikes by adding an enable delay of 2 ms and a minimum off to on delay of also 2 ms. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440 Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250417111337.38142-7-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-24platform/x86: int3472: Make regulator supply name configurableHans de Goede
This is a preparation patch for registering multiple regulators, which requires a different supply-name for each regulator. Make supply-name a parameter to skl_int3472_register_regulator() and use con-id to set it so that the existing int3472_gpio_map remapping can be used with it. Since supply-name is a parameter now, drop the fixed skl_int3472_regulator_map_supplies[] array and instead add lower- and upper-case mappings of the passed-in supply-name to the regulator. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440 Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250417111337.38142-6-hdegoede@redhat.com [ij: GPIO_SUPPPLY_NAME_LENGTH -> GPIO_SUPPLY_NAME_LENGTH] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-24platform/x86: int3472: Rework AVDD second sensor quirk handlingHans de Goede
Rework the discrete quirk handling to use a quirks struct which is pointed to by a dmi_system_id table, rather then having a dmi_system_id table per type of quirk. This is a preparation patch for adding support for multiple regulators, where not all regulators might be shared between sensors. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440 Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250417111337.38142-5-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-02-13platform/x86: int3472: Call "func" "con_id" insteadSakari Ailus
"con_id" is an established variable name for the GPIO naming for drivers. Use it instead of "func" in the int3472 driver, too. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250211072841.7713-4-sakari.ailus@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-02-11platform/x86: int3472: Call "reset" GPIO "enable" for INT347ESakari Ailus
The DT bindings for ov7251 specify "enable" GPIO (xshutdown in documentation) but the int3472 indiscriminately provides this as a "reset" GPIO to sensor drivers. Take this into account by assigning it as "enable" with active high polarity for INT347E devices, i.e. ov7251. "reset" with active low polarity remains the default GPIO name for other devices. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250211072841.7713-3-sakari.ailus@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-02-11platform/x86: int3472: Use correct type for "polarity", call it gpio_flagsSakari Ailus
Struct gpiod_lookup flags field's type is unsigned long. Thus use unsigned long for values to be assigned to that field. Similarly, also call the field gpio_flags which it really is. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250211072841.7713-2-sakari.ailus@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-10platform/x86: int3472: Fix skl_int3472_handle_gpio_resources() return valueHans de Goede
The INT3472 code never wants a copy of the ACPI resource to be added to the list-head passed to acpi_dev_get_resources(). Make skl_int3472_handle_gpio_resources() always return -errno or 1. Also update the inaccurate comment about the return value. skl_int3472_handle_gpio_resources() was already returning 1 in the case of not a GPIO resource or invalid _DSM return and not -EINVAL / -ENODEV as the comment claimed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241209220522.25288-3-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-10platform/x86: int3472: Make "pin number mismatch" message a debug messageHans de Goede
It seems that Windows is only using the ACPI GPIO resources and never looks at the part of the _DSM return value which encodes the pin number. For example on a Terra Pad 1262 v2 the following messages are printend: int3472-discrete INT3472:01: reset \_SB.GPI0 pin number mismatch _DSM 103 resource 359 int3472-discrete INT3472:01: powerdown \_SB.GPI0 pin number mismatch _DSM 207 resource 335 int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 101 resource 357 Notice for the 2 reset pins that the _DSM value is off by 256, this is caused by there only being 8 bits reserved in the _DSM return value for the pin-number. As for the powerdown pin, testing has shown that the pin-number 335 from the ACPI GPIO resource is correct and the _DSM value is bogus. Lower the warning about these mismatches to a debug message and only look at the lower 8 bits of the GPIO resource pin numbers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241209220522.25288-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-10platform/x86: int3472: Check for adev == NULLHans de Goede
Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs. Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241209220522.25288-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-10-17platform/x86: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/platform/x86/ to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. While touching these files, make indention of the struct initializer consistent in several files. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20241017073802.53235-2-u.kleine-koenig@baylibre.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-09-04platform/x86: int3472: Use str_high_low()Andy Shevchenko
Use str_high_low() rather than open coding. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240822130722.1261891-5-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-09-04platform/x86: int3472: Use GPIO_LOOKUP() macroAndy Shevchenko
Use GPIO_LOOKUP() macro which provides a compound literal and can be used with dynamic data. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240822130722.1261891-4-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-06platform/x86: int3472: Switch to devm_get_gpiod()Hans de Goede
Switch to devm_get_gpiod() for discrete GPIOs for clks / regulators / LEDs and let devm do the cleanup for us. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-5-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Stop using gpiod_toggle_active_low()Hans de Goede
Use the new skl_int3472_gpiod_get_from_temp_lookup() helper to get a gpio to pass to register_gpio_clock(), skl_int3472_register_regulator() and skl_int3472_register_pled(). This removes all use of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-4-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helperBartosz Golaszewski
Add a new skl_int3472_gpiod_get_from_temp_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. [hdegoede@redhat.com] use the new skl_int3472_fill_gpiod_lookup() helper Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.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/20231004162317.163488-3-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Add new skl_int3472_fill_gpiod_lookup() helperHans de Goede
Add a new skl_int3472_fill_gpiod_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-06-20platform/x86: int3472: discrete: Log a warning if the pin-numbers don't matchHans de Goede
The INT3472 discrete code assumes that the ACPI GPIO resources are in the same order as the pin-info _DSM entries. The returned pin-info includes the pin-number in bits 15-8. Add a check that this matches with the ACPI GPIO resource pin-number in case the assumption is not true with some ACPI tables. Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-7-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Use FIELD_GET() on the GPIO _DSM return valueHans de Goede
Add defines for the various fields encoded in the GPIO _DSM integer return value and then use FIELD_GET() to get field values. Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-6-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Remove sensor_config-sHans de Goede
Currently the only 2 sensor_config-s both specify "avdd" as supply-id. The INT3472 device is going to be the only supplier of a regulator for the sensor device. So there is no chance of collisions with other regulator suppliers and it is undesirable to need to manually add new entries to int3472_sensor_configs[] for each new sensor module which uses a GPIO regulator. Instead just always use "avdd" as supply-id when registering the GPIO regulator. If necessary for specific sensor drivers then other supply-ids can be added as aliases in the future, adding aliases will be safe since INT3472 will be the only regulator supplier for the sensor. Cc: Bingbu Cao <bingbu.cao@intel.com> Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230616172132.37859-3-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Drop GPIO remapping supportHans de Goede
The only sensor driver which needs GPIO remapping support is the ov2680 driver and ACPI enumeration support + other necessary changes to the ov2680 driver were never upstreamed. A new series updating the ov2680 driver is pending upstream now and in this series the ov2680 driver is patched to look for "powerdown" as con-id, instead of relying on GPIO remapping in the int3472 code, so the GPIO remapping is no longer necessary. Tested-by: Hao Yao <hao.yao@intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-2-hdegoede@redhat.com
2023-06-08platform/x86: int3472: Evaluate device's _DSM method to control imaging clockBingbu Cao
On some platforms, the imaging clock should be controlled by evaluating specific clock device's _DSM method instead of setting gpio, so this change register clock if no gpio based clock and then use the _DSM method to enable and disable clock. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Hao Yao <hao.yao@intel.com> Link: https://lore.kernel.org/r/20230524035135.90315-2-bingbu.cao@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230531134429.171337-1-hdegoede@redhat.com
2023-03-07platform/x86: intel: int3472: discrete: Convert to platform remove callback ↵Uwe Kleine-König
returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230302144732.1903781-22-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86: int3472/discrete: Drop unnecessary obj->type == string checkHans de Goede
acpi_evaluate_dsm_typed() already verifies the type is the requested type, so this error check is a no-op, drop it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230204110223.54625-1-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Get the polarity from the _DSM entryHans de Goede
According to: https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.patch Bits 31-24 of the _DSM pin entry integer value codes the active-value, that is the actual physical signal (0 or 1) which needs to be output on the pin to turn the sensor chip on (to make it active). So if bits 31-24 are 0 for a reset pin, then the actual value of the reset pin needs to be 0 to take the chip out of reset. IOW in this case the reset signal is active-high rather then the default active-low. And if bits 31-24 are 0 for a clk-en pin then the actual value of the clk pin needs to be 0 to enable the clk. So in this case the clk-en signal is active-low rather then the default active-high. IOW if bits 31-24 are 0 for a pin, then the default polarity of the pin is inverted. Add a check for this and also propagate this new polarity to the clock registration. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-6-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Move GPIO request to ↵Hans de Goede
skl_int3472_register_clock() Move the requesting of the clk-enable GPIO to skl_int3472_register_clock() (and move the gpiod_put to unregister). This mirrors the GPIO handling in skl_int3472_register_regulator() and allows removing skl_int3472_map_gpio_to_clk() from discrete.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-5-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Create a LED class device for the privacy LEDHans de Goede
On some systems, e.g. the Lenovo ThinkPad X1 Yoga gen 7 and the ThinkPad X1 Nano gen 2 there is no clock-enable pin, triggering the: "No clk GPIO. The privacy LED won't work" warning and causing the privacy LED to not work. Fix this by modeling the privacy LED as a LED class device rather then integrating it with the registered clock. Note this relies on media subsys changes to actually turn the LED on/off when the sensor's v4l2_subdev's s_stream() operand gets called. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-4-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Refactor GPIO to sensor mappingHans de Goede
Add a helper function to map the type returned by the _DSM method to a function name + the default polarity for that function. And fold the INT3472_GPIO_TYPE_RESET and INT3472_GPIO_TYPE_POWERDOWN cases into a single generic case. This is a preparation patch for further GPIO mapping changes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-3-hdegoede@redhat.com
2023-01-12platform/x86: int3472/discrete: Ensure the clk/power enable pins are in ↵Hans de Goede
output mode acpi_get_and_request_gpiod() does not take a gpio_lookup_flags argument specifying that the pins direction should be initialized to a specific value. This means that in some cases the pins might be left in input mode, causing the gpiod_set() calls made to enable the clk / regulator to not work. One example of this problem is the clk-enable GPIO for the ov01a1s sensor on a Dell Latitude 9420 being left in input mode causing the clk to never get enabled. Explicitly set the direction of the pins to output to fix this. Fixes: 5de691bffe57 ("platform/x86: Add intel_skl_int3472 driver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Daniel Scally <djrscally@gmail.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230111201426.947853-1-hdegoede@redhat.com
2022-09-22platform/x86: int3472/discrete: Drop a forward declarationUwe Kleine-König
By swapping the definition of skl_int3472_discrete_remove() and skl_int3472_discrete_probe() the forward declaration of the former can be dropped. This is a good thing as it removes code duplication. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20220920070101.907596-1-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-03platform/x86: Replace acpi_bus_get_device()Rafael J. Wysocki
Replace acpi_bus_get_device() that is going to be dropped with acpi_fetch_acpi_dev(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/2631712.mvXUDI8C0e@kreacher Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-13platform/x86: int3472: Deal with probe ordering issuesHans de Goede
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around this info missing from the ACPI tables on devices where the int3472 driver is used, the int3472 MFD-cell drivers attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI fw-node, so to work around these probe ordering issues the ACPI core / i2c-code does not instantiate the I2C-clients for any ACPI devices which have a _DEP dependency on an INT3472 ACPI device until all _DEP-s are met. This relies on acpi_dev_clear_dependencies() getting called by the driver for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies() call to the discrete.c probe code. In the tps68470 case calling acpi_dev_clear_dependencies() is already done by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell (The GPIO cell is deliberately the last cell created to make sure the clk + regulator cells are already instantiated when this happens). However for proper probe ordering, the clk/regulator cells must not just be instantiated the must be fully ready (the clks + regulators must be registered with their subsystems). Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for the instantiated MFD-cells so that these are loaded before us and so that they bind immediately when the platform-devs are instantiated. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-12-hdegoede@redhat.com
2021-12-13platform/x86: int3472: Add get_sensor_adev_and_name() helperHans de Goede
The discrete.c code is not the only code which needs to lookup the acpi_device and device-name for the sensor for which the INT3472 ACPI-device is a GPIO/clk/regulator provider. The tps68470.c code also needs this functionality, so factor this out into a new get_sensor_adev_and_name() helper. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-9-hdegoede@redhat.com