summaryrefslogtreecommitdiff
path: root/drivers/platform/x86/intel/int3472
AgeCommit message (Collapse)AuthorFilesLines
2023-10-06platform/x86: int3472: Switch to devm_get_gpiod()Hans de Goede3-26/+6
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 Goede4-59/+41
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 Golaszewski1-0/+26
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 Goede1-10/+22
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-07-10platform/x86: int3472/discrete: set variable ↵Tom Rix1-1/+1
skl_int3472_regulator_second_sensor storage-class-specifier to static smatch reports drivers/platform/x86/intel/int3472/clk_and_regulator.c:263:28: warning: symbol 'skl_int3472_regulator_second_sensor' was not declared. Should it be static? This variable is only used in its defining file, so it should be static. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20230702134419.3438361-1-trix@redhat.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-07-01Merge tag 'platform-drivers-x86-v6.5-1' of ↵Linus Torvalds4-119/+181
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: "AMD PMC and PMF drivers: - Various bugfixes - Improved debugging support Intel PMC: - Refactor to support hw with multiple PMCs - Various other improvements / new hw support Intel Speed Select Technology (ISST): - TPMI Uncore Frequency + Cluster Level Power Controls - Various bugfixes - tools/intel-speed-select: Misc improvements Dell-DDV: Add documentation INT3472 ACPI camera sensor glue code: - Evaluate device's _DSM method to control imaging clock - Drop the need to have a table with per sensor-model info Lenovo Yogabook: - Refactor / rework to also support Android models Think-LMI: - Multiple improvements and fixes WMI: - Add proper API documentation for the WMI bus x86-android-tablets: - Misc new hw support Miscellaneous other cleanups / fixes" * tag 'platform-drivers-x86-v6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (91 commits) platform/x86:intel/pmc: Add Meteor Lake IOE-M PMC related maps platform/x86:intel/pmc: Add Meteor Lake IOE-P PMC related maps platform/x86:intel/pmc: Use SSRAM to discover pwrm base address of primary PMC platform/x86:intel/pmc: Discover PMC devices platform/x86:intel/pmc: Enable debugfs multiple PMC support platform/x86:intel/pmc: Add support to handle multiple PMCs platform/x86:intel/pmc: Combine core_init() and core_configure() platform/x86:intel/pmc: Update maps for Meteor Lake P/M platforms platform/x86/intel: tpmi: Remove hardcoded unit and offset platform/x86: int3472: discrete: Log a warning if the pin-numbers don't match platform/x86: int3472: discrete: Use FIELD_GET() on the GPIO _DSM return value platform/x86: int3472: discrete: Add alternative "AVDD" regulator supply name platform/x86: int3472: discrete: Add support for 1 GPIO regulator shared between 2 sensors platform/x86: int3472: discrete: Remove sensor_config-s platform/x86: int3472: discrete: Drop GPIO remapping support platform/x86: apple-gmux: don't use be32_to_cpu and cpu_to_be32 platform/x86/dell/dell-rbtn: Fix resources leaking on error path platform/x86: ISST: Fix usage counter platform/x86: ISST: Reset default callback on unregister platform/x86: int3472: Switch back to use struct i2c_driver's .probe() ...
2023-06-20platform/x86: int3472: discrete: Log a warning if the pin-numbers don't matchHans de Goede1-1/+7
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 Goede1-3/+7
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: Add alternative "AVDD" regulator supply nameHans de Goede2-1/+2
Add an "AVDD" regulator supply name alias to the supply-map which gets registered for the INT3472 GPIO regulator. This is necessary for the ov2680 driver which expects "AVDD" rather then "avdd". Updating the ov2680 driver to use "avdd" is not possible because that will break compatibility with existing DT / DTB files. 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-5-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Add support for 1 GPIO regulator shared ↵Hans de Goede2-7/+41
between 2 sensors On the Lenovo Miix 510-12IKB there is 1 GPIO regulator, with its GPIO listed in the INT3472 device belonging to the OV5648 back sensor. But this regulator also needs to be enabled for the OV2680 front sensor to work. Add support to skl_int3472_register_regulator() to add supply map entries pointing to both sensors based on a DMI quirk table which gives the dev_name part of the supply map for the second sensor (the sensor without the GPIO listed in its matching INT3472 ACPI device). Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-4-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Remove sensor_config-sHans de Goede3-61/+31
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 Goede2-40/+3
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-13platform/x86: int3472: Switch back to use struct i2c_driver's .probe()Uwe Kleine-König1-1/+1
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230612073902.840435-4-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-08platform/x86: int3472: Evaluate device's _DSM method to control imaging clockBingbu Cao3-15/+99
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-05-30platform/x86: int3472: Avoid crash in unregistering regulator gpioHao Yao1-5/+8
When int3472 is loaded before GPIO driver, acpi_get_and_request_gpiod() failed but the returned gpio descriptor is not NULL, it will cause panic in later gpiod_put(), so set the gpio_desc to NULL in register error handling to avoid such crash. Signed-off-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Link: https://lore.kernel.org/r/20230524035135.90315-1-bingbu.cao@intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-03-07platform/x86: intel: int3472: discrete: Convert to platform remove callback ↵Uwe Kleine-König1-4/+2
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-03-07platform/x86: int3472: Add GPIOs to Surface Go 3 Board dataDaniel Scally1-2/+3
Add the INT347E GPIO lookup table to the board data for the Surface Go 3. This is necessary to allow the ov7251 IR camera to probe properly on that platform. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230302102611.314341-1-dan.scally@ideasonboard.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86: int3472/discrete: add LEDS_CLASS dependencyArnd Bergmann1-0/+1
int3472 now fails to link when the LED support is disabled: x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_register_pled': led.c:(.text+0xf4): undefined reference to `led_classdev_register_ext' x86_64-linux-ld: led.c:(.text+0x131): undefined reference to `led_add_lookup' x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_unregister_pled': led.c:(.text+0x16b): undefined reference to `led_remove_lookup' x86_64-linux-ld: led.c:(.text+0x177): undefined reference to `led_classdev_unregister' Add an explicit Kconfig dependency. Fixes: 5ae20a8050d0 ("platform/x86: int3472/discrete: Create a LED class device for the privacy LED") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230208163658.2129009-1-arnd@kernel.org 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 Goede1-8/+0
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 Goede3-4/+16
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 Goede3-31/+30
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 Goede5-47/+106
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 Goede1-9/+36
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 Goede2-0/+7
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-12-08regulator: core: Use different devices for resource allocation and DT lookupChiYuan Huang1-1/+2
Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/ From the analysis of Yingliang CPU A |CPU B mt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data() i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register() It's common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device. To fix it, this patch expand 'regulator_register' API to use the different devices for init data allocation and DT lookup. Reported-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-10Merge tag 'acpi-6.1-rc1-2' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI updates from Rafael Wysocki: "These fix two issues, in APEI and in the int3472 driver, clean up the ACPI thermal driver, add ACPI support for non-GPE system wakeup events and make the system reboot code use the S5 (system off) state by default. Specifics: - Fix ACPI device object reference counting in (recently updated) skl_int3472_fill_clk_pdata() (Andy Shevchenko). - Fix a memory leak in APEI by avoiding to add a task_work to kernel threads running when an asynchronous error is detected (Shuai Xue). - Add ACPI support for handling system wakeups via GPIO wake capable IRQs in addition to GPEs (Raul E Rangel). - Make the system reboot code put ACPI-enabled systems into the S5 (system off) state which is necessary for some platforms to work as expected (Kai-Heng Feng). - Make the white space usage in the ACPI thermal driver more consistent and drop redundant code from it (Rafael Wysocki)" * tag 'acpi-6.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: thermal: Drop some redundant code ACPI: thermal: Drop redundant parens from expressions ACPI: thermal: Use white space more consistently platform/x86: int3472: Don't leak reference on error ACPI: APEI: do not add task_work to kernel thread to avoid memory leak PM: ACPI: reboot: Reinstate S5 for reboot kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle i2c: acpi: Use ACPI wake capability bit to set wake_irq ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get
2022-10-05Merge tag 'platform-drivers-x86-v6.1-1' of ↵Linus Torvalds1-18/+16
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: - AMD Platform Management Framework (PMF) driver with AMT and QnQF support - AMD PMC: Improved logging for debugging s2idle issues - Big refactor of the ACPI/x86 backlight handling, ensuring that we only register 1 /sys/class/backlight device per LCD panel - Microsoft Surface: - Surface Laptop Go 2 support - Surface Pro 8 HID sensor support - Asus WMI: - Lots of cleanups - Support for TUF RGB keyboard backlight control - Add support for ROG X13 tablet mode - Siemens Simatic: IPC227G and IPC427G support - Toshiba ACPI laptop driver: Fan hwmon and battery ECO mode support - tools/power/x86/intel-speed-select: Various improvements - Various cleanups - Various small bugfixes * tag 'platform-drivers-x86-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (153 commits) platform/x86: use PLATFORM_DEVID_NONE instead of -1 platform/x86/amd: pmc: Dump idle mask during "check" stage instead platform/x86/intel/wmi: thunderbolt: Use dev_groups callback platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks platform/surface: Split memcpy() of struct ssam_event flexible array platform/x86: compal-laptop: Get rid of a few forward declarations platform/x86: intel-uncore-freq: Use sysfs_emit() to instead of scnprintf() platform/x86: dell-smbios-base: Use sysfs_emit() platform/x86/amd/pmf: Remove unused power_delta instances platform/x86/amd/pmf: install notify handler after acpi init Documentation/ABI/testing/sysfs-amd-pmf: Add ABI doc for AMD PMF platform/x86/amd/pmf: Add sysfs to toggle CnQF platform/x86/amd/pmf: Add support for CnQF platform/x86/amd: pmc: Fix build without debugfs platform/x86: hp-wmi: Support touchpad on/off platform/x86: int3472/discrete: Drop a forward declaration platform/x86: toshiba_acpi: change turn_on_panel_on_resume to static platform/x86: wmi: Drop forward declaration of static functions platform/x86: toshiba_acpi: Remove duplicate include platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading ...
2022-10-05Merge tag 'i2c-for-6.1-rc1' of ↵Linus Torvalds1-3/+1
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - 'remove' callback converted to return void. Big change with trivial fixes all over the tree. Other subsystems depending on this change have been asked to pull an immutable topic branch for this. - new driver for Microchip PCI1xxxx switch - heavy refactoring of the Mellanox BlueField driver - we prefer async probe in the i801 driver now - the rest is usual driver updates (support for more SoCs, some refactoring, some feature additions) * tag 'i2c-for-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (37 commits) i2c: pci1xxxx: prevent signed integer overflow i2c: acpi: Replace zero-length array with DECLARE_FLEX_ARRAY() helper i2c: i801: Prefer async probe i2c: designware-pci: Use standard pattern for memory allocation i2c: designware-pci: Group AMD NAVI quirk parts together i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch docs: i2c: slave-interface: return errno when handle I2C_SLAVE_WRITE_REQUESTED i2c: mlxbf: remove device tree support i2c: mlxbf: support BlueField-3 SoC i2c: cadence: Add standard bus recovery support i2c: mlxbf: add multi slave functionality i2c: mlxbf: support lock mechanism macintosh/ams: Adapt declaration of ams_i2c_remove() to earlier change i2c: riic: Use devm_platform_ioremap_resource() i2c: mlxbf: remove IRQF_ONESHOT dt-bindings: i2c: rockchip: add rockchip,rk3128-i2c dt-bindings: i2c: renesas,rcar-i2c: Add r8a779g0 support i2c: tegra: Add GPCDMA support i2c: scmi: Convert to be a platform driver i2c: rk3x: Add rv1126 support ...
2022-10-04platform/x86: int3472: Don't leak reference on errorAndy Shevchenko1-3/+3
The for_each_acpi_consumer_dev() takes a reference to the iterator and if we break a loop we must drop that reference. This usually happens when error handling is involved. However it's not the case for skl_int3472_fill_clk_pdata(). Don't leak reference on error by dropping it properly. Fixes: 43cf36974d76 ("platform/x86: int3472: Support multiple clock consumers") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24platform/x86: int3472: Add board data for Surface Go2 IR cameraDaniel Scally1-0/+33
Add the board data describing the regulators for the Microsoft Surface Go line's IR camera. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24platform/x86: int3472: Support multiple gpio lookups in board dataDaniel Scally3-9/+32
Currently, we only support passing a single gpiod_lookup_table as part of the board data for the tps68470 driver. This carries the implicit assumption that each TPS68470 device will only support a single sensor, which does not hold true. Extend the code to support the possibility of multiple sensors each having a gpiod_lookup_table, and opportunistically add the lookup table for the Surface Go line's IR camera. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24platform/x86: int3472: Support multiple clock consumersDaniel Scally1-7/+52
At present, the tps68470.c only supports a single clock consumer when passing platform data to the clock driver. In some devices multiple sensors depend on the clock provided by a single TPS68470 and so all need to be able to acquire the clock. Support passing multiple consumers as platform data. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24ACPI: scan: Add acpi_dev_get_next_consumer_dev()Daniel Scally1-1/+1
In commit b83e2b306736 ("ACPI: scan: Add function to fetch dependent of ACPI device") we added a means of fetching the first device to declare itself dependent on another ACPI device in the _DEP method. One assumption in that patch was that there would only be a single consuming device, but this has not held. Replace that function with a new function that fetches the next consumer of a supplier device. Where no "previous" consumer is passed in, it behaves identically to the original function. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-22platform/x86: int3472/discrete: Drop a forward declarationUwe Kleine-König1-18/+16
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-08-16i2c: Make remove callback return voidUwe Kleine-König1-3/+1
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-02-21platform/x86: int3472: Add terminator to gpiod_lookup_tableDaniel Scally1-1/+2
Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Fixes: 19d8d6e36b4b ("platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell") Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20220216225304.53911-5-djrscally@gmail.com 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. Wysocki1-3/+2
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>
2022-01-08platform/x86: int3472: Add board data for Surface Go 3Daniel Scally1-0/+13
The Surface Go 3 needs some board data in order to configure the TPS68470 PMIC - add entries to the tables in tps68470_board_data.c that define the configuration that's needed. Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20220106232045.41291-1-djrscally@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-13platform/x86: int3472: Deal with probe ordering issuesHans de Goede2-0/+7
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: Pass tps68470_regulator_platform_data to the ↵Hans de Goede4-1/+199
tps68470-regulator MFD-cell Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell, specifying the voltages of the various regulators and tying the regulators to the sensor supplies so that sensors which use the TPS68470 can find their regulators. Since the voltages and supply connections are board-specific, this introduces a DMI matches int3472_tps68470_board_data struct which contains the necessary per-board info. This per-board info also includes GPIO lookup information for the sensor IO lines which may be connected to the tps68470 GPIOs. 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-11-hdegoede@redhat.com
2021-12-13platform/x86: int3472: Pass tps68470_clk_platform_data to the ↵Hans de Goede1-7/+28
tps68470-regulator MFD-cell Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. 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-10-hdegoede@redhat.com
2021-12-13platform/x86: int3472: Add get_sensor_adev_and_name() helperHans de Goede3-18/+35
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
2021-12-13platform/x86: int3472: Split into 2 driversHans de Goede7-120/+105
The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver. These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared. Split the module into 2 drivers, linking the little shared code directly into both. This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver. While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix. 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-8-hdegoede@redhat.com
2021-10-11platform/x86: intel_skl_int3472: Correct null checkDaniel Scally1-1/+1
The int3472-discrete driver can enter an error path after initialising int3472->clock.ena_gpio, but before it has registered the clock. This will cause a NULL pointer dereference, because clkdev_drop() is not null aware. Instead of guarding the call to skl_int3472_unregister_clock() by checking for .ena_gpio, check specifically for the presence of the clk_lookup, which will guarantee clkdev_create() has already been called. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453 Fixes: 7540599a5ef1 ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()") Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-12platform/x86/intel: int3472: Use y instead of objs in MakefileAndy Shevchenko1-1/+1
The 'objs' is for user space tools, for the kernel modules we should use 'y'. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20210806154951.4564-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-28platform/x86: intel_skl_int3472: Uninitialized variable in ↵Dan Carpenter1-2/+2
skl_int3472_handle_gpio_resources() This function returns negative error codes, zero (to indicate that everything has been completed successfully) and one (to indicate that more resources need to be handled still). This code prints an uninitialized error message when the function returns one which potentially leads to an Oops. Fixes: 5de691bffe57 ("platform/x86: Add intel_skl_int3472 driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/YNXTkLNtiTDlFlZa@mwanda Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-22platform/x86: intel_skl_int3472: Move to intel/ subfolderAndy Shevchenko7-0/+1020
Start collecting Intel x86 related drivers in its own subfolder. Move intel_skl_int3472 first. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210618125516.53510-7-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>