summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/pmic
Commit message (Collapse)AuthorAgeFilesLines
* ACPI: PMIC: Add comments with DSDT power opregion field namesHans de Goede2023-01-301-13/+13
| | | | | | | | | | | | | | | | | The DSDTs of CHT devices using the Dollar Cove TI PMIC, all use LDO1 - LDO14 names for the DSDT power opregion field names. Add comments with these fields to make it easier to see which PMIC registers are being set by ACPI code using these. Note that LDO4 is missing and the mapped registers jump from 0x43 to 0x45 to match. This matches with how the fields are declared in the DSDT where LDO4 is skipped too. Note there is no hole in the field addresses, LDO4 is simply just not defined on either side. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: PMIC: Add pmic_i2c_address to BYT Crystal Cove supportHans de Goede2022-12-301-0/+1
| | | | | | | | | | Add a pmic_i2c_address entry to intel_pmic_bytcrc.c, so that intel_soc_pmic_exec_mipi_pmic_seq_element() can be used on devices with a Bay Trail Crystal Cove PMIC OpRegion driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: PMIC: xpower: Fix _TMP ACPI errorsHans de Goede2021-12-081-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | On some devices with a X-Powers AXP288 PMIC the LPAT tables in the ACPI node for the AXP288 PMIC for some reason only describe a small temperature range, e.g. 27° - 37° Celcius (assuming the entries are in millidegrees). When the tablet is idle in a room at 21° degrees this is causing values outside the LPAT table to be read, causing e.g. the following 2 errors to get spammed to the logs every 4 seconds! : [ 7512.791316] ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20210930/evregion-281) [ 7512.791611] ACPI Error: Aborting method \_SB.SXP1._TMP due to previous error (AE_ERROR) (20210930/psparse-529) Fix this by clamping the raw value to the LPAT table range before passing it to acpi_lpat_raw_to_temp(). Note clamping has been chosen rather then extrapolating because it is unknown how other parts of the ACPI tables will respond to temperature values outside of the LPAT range. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: PMIC: allow drivers to provide a custom lpat_raw_to_temp() functionHans de Goede2021-12-088-1/+11
| | | | | | | | | | | | The LPAT tables used in the DSDT for some PMICs require special handling, allow the PMIC OpRegion drivers to provide an alternative implementation by adding a lpat_raw_to_temp function pointer to struct pmic_table; and initialize this to the default acpi_lpat_raw_to_temp function for all PMICs. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: PMIC: constify all struct intel_pmic_opregion_data declarationsHans de Goede2021-12-088-13/+15
| | | | | | | | | The struct intel_pmic_opregion_data declarations never change, constify them all. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: PMIC: Fix intel_pmic_regs_handler() read accessesHans de Goede2021-11-031-23/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The handling of PMIC register reads through writing 0 to address 4 of the OpRegion is wrong. Instead of returning the read value through the value64, which is a no-op for function == ACPI_WRITE calls, store the value and then on a subsequent function == ACPI_READ with address == 3 (the address for the value field of the OpRegion) return the stored value. This has been tested on a Xiaomi Mi Pad 2 and makes the ACPI battery dev there mostly functional (unfortunately there are still other issues). Here are the SET() / GET() functions of the PMIC ACPI device, which use this OpRegion, which clearly show the new behavior to be correct: OperationRegion (REGS, 0x8F, Zero, 0x50) Field (REGS, ByteAcc, NoLock, Preserve) { CLNT, 8, SA, 8, OFF, 8, VAL, 8, RWM, 8 } Method (GET, 3, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 RWM = Zero If ((AVBG == One)) { GPRW = Zero } } Return (VAL) /* \_SB_.PCI0.I2C7.PMI5.VAL_ */ } Method (SET, 4, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 VAL = Arg3 RWM = One If ((AVBG == One)) { GPRW = One } } } Fixes: 0afa877a5650 ("ACPI / PMIC: intel: add REGS operation region support") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: XPower: optimize MIPI PMIQ sequence I2C-bus accessesHans de Goede2021-07-161-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. The default exec_mipi_pmic_seq_element implementation from drivers/acpi/pmic/intel_pmic.c does a regmap_update_bits() call and the involved registers are typically marked as volatile in the regmap, so this leads to 2 I2C-bus accesses. Add a XPower AXP288 specific implementation of exec_mipi_pmic_seq_element which calls iosf_mbi_block_punit_i2c_access() calls before the regmap_update_bits() call to avoid having to do the whole expensive acquire P-Unit semaphore dance twice. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: XPower: optimize I2C-bus accessesHans de Goede2021-07-161-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. Add iosf_mbi_block_punit_i2c_access() calls around groups of register accesses, so that the P-Unit semaphore only needs to be taken once for each group of register accesses. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* mfd: tps68470: Remove tps68470 MFD driverDaniel Scally2021-06-171-1/+1
| | | | | | | | | | | | | This driver only covered one scenario in which ACPI devices with _HID INT3472 are found, and its functionality has been taken over by the intel-skl-int3472 module, so remove it. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20210603224007.120560-7-djrscally@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* ACPI: scan: Extend acpi_walk_dep_device_list()Daniel Scally2021-06-071-1/+1
| | | | | | | | | | | | | | | | | | The acpi_walk_dep_device_list() function is not as generic as its name implies, serving only to decrement the dependency count for each dependent device of the input. Extend it to accept a callback which can be applied to all the dependencies in acpi_dep_list. Replace all existing calls to the function with calls to a wrapper, passing a callback that applies the same dependency reduction. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface parts Signed-off-by: Daniel Scally <djrscally@gmail.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: fix various typos in commentsTom Saeger2021-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Fix trivial ACPI driver comment typos. s/notifcations/notifications/ s/Ajust/Adjust/ s/preform/perform/ s/atrributes/attributes/ s/Souce/Source/ s/Evalutes/Evaluates/ s/Evalutes/Evaluates/ s/specifiy/specify/ s/promixity/proximity/ s/presuambly/presumably/ s/Evalute/Evaluate/ s/specificed/specified/ s/rountine/routine/ s/previosuly/previously/ Change comment referencing pcc_send_cmd to send_pcc_cmd. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Move TPS68470 OpRegion driver to drivers/acpi/pmic/Andy Shevchenko2020-09-152-0/+17
| | | | | | | | | | It is revealed now that TPS68470 OpRegion driver has been added in slightly different scope. Let's move it to the drivers/acpi/pmic/ folder for sake of the unification. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Split out Kconfig and Makefile specific for ACPI PMICAndy Shevchenko2020-09-152-0/+60
| | | | | | | | | | It's a bit better to maintain and allows to avoid mistakes in the future with PMIC OpRegion drivers, if we split out Kconfig and Makefile for ACPI PMIC to its own folder. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Add i2c address for thermal controlMauro Carvalho Chehab2020-05-181-0/+1
| | | | | | | | | | | | | | | | | On Asus T101HA, we keep receiving those error messages: i915 0000:00:02.0: [drm] *ERROR* mipi_exec_pmic failed, error: -95 intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x5e reg-addr 0x4b value 0x59 mask 0xff Because the opregion is missing the I2C address. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Add Cherry Trail Crystal Cove PMIC OpRegion driverHans de Goede2019-10-251-0/+44
| | | | | | | | | | | | | | | | | | | | | | We have no docs for the CHT Crystal Cove PMIC. The Asus Zenfone-2 kernel code has 2 Crystal Cove regulator drivers, one calls the PMIC a "Crystal Cove Plus" PMIC and talks about Cherry Trail, so presuambly that one could be used to get register info for the regulators if we need to implement regulator support in the future. For now the sole purpose of this driver is to make intel_soc_pmic_exec_mipi_pmic_seq_element work on devices with a CHT Crystal Cove PMIC. Specifically this fixes the following MIPI PMIC sequence related errors on e.g. an Asus T100HA: [ 178.211801] intel_soc_pmic_exec_mipi_pmic_seq_element: No PMIC registered [ 178.211897] [drm:intel_dsi_dcs_init_backlight_funcs [i915]] *ERROR* mipi_exec_pmic failed, error: -6 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Add byt prefix to Crystal Cove PMIC OpRegion driverHans de Goede2019-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Our current Crystal Cove OpRegion driver is only valid for the Crystal Cove PMIC variant found on Bay Trail (BYT) boards, Cherry Trail (CHT) based boards use another variant. At least the regulator registers are different on CHT and these registers are one of the things controlled by the custom PMIC OpRegion. Commit 4d9ed62ab142 ("mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT") has disabled the intel_pmic_crc.c code for CHT devices by removing the "crystal_cove_pmic" MFD cell on CHT devices. This commit renames the intel_pmic_crc.c driver and the cell to be prefixed with "byt" to indicate that this code is for BYT devices only. This is a preparation patch for adding a separate PMIC OpRegion driver for the CHT variant of the Crystal Cove PMIC (sometimes called Crystal Cove Plus in Android kernel sources). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Do not register handlers for unhandled OpRegionsHans de Goede2019-10-251-7/+13
| | | | | | | | | | | | | | For some model PMIC's used on Intel boards we do not know how to handle the power or thermal opregions because we have no documentation. For example in the intel_pmic_chtwc.c driver thermal_table_count is 0, which means that our PMIC_THERMAL_OPREGION_ID handler will always fail with AE_BAD_PARAMETER, in this case it is better to simply not register the handler at all. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: intel: Drop double removal of address space handlerAndy Shevchenko2019-07-031-2/+0
| | | | | | | | There is no need to remove address space handler twice, because removal is idempotent. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner2019-05-301-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge v5.0-rc7 into drm-nextDave Airlie2019-02-181-8/+33
|\ | | | | | | | | | | Backmerging for nouveau and imx that needed some fixes for next pulls. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * ACPI / PMIC: xpower: Fix TS-pin current-source handlingHans de Goede2019-01-071-8/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current-source used for the battery temp-sensor (TS) is shared with the GPADC. For proper fuel-gauge and charger operation the TS current-source needs to be permanently on. But to read the GPADC we need to temporary switch the TS current-source to ondemand, so that the GPADC can use it, otherwise we will always read an all 0 value. The switching from on to on-ondemand is not necessary when the TS current-source is off (this happens on devices which do not have a TS). Prior to this commit there were 2 issues with our handling of the TS current-source switching: 1) We were writing hardcoded values to the ADC TS pin-ctrl register, overwriting various other unrelated bits. Specifically we were overwriting the current-source setting for the TS and GPIO0 pins, forcing it to 80ųA independent of its original setting. On a Chuwi Vi10 tablet this was causing us to get a too high adc value (due to a too high current-source) resulting in acpi_lpat_raw_to_temp() returning -ENOENT, resulting in: ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR This commit fixes this by using regmap_update_bits to change only the relevant bits. 2) At the end of intel_xpower_pmic_get_raw_temp() we were unconditionally enabling the TS current-source even on devices where the TS-pin is not used and the current-source thus was off on entry of the function. This commit fixes this by checking if the TS current-source is off when entering intel_xpower_pmic_get_raw_temp() and if so it is left as is. Fixes: 58eefe2f3f53 (ACPI / PMIC: xpower: Do pinswitch ... reading GPADC) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handlingHans de Goede2019-01-093-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most PMIC-s use only a single i2c-address, so after verifying the i2c-address matches, we can simply pass the call to regmap_update_bits. This commit adds support for this and hooks this up for the xpower AXP288 PMIC by setting the new pmic_i2c_address field. This fixes the following errors on display on / off on a Jumper Ezpad mini 3 and an Onda V80 plus tablet, both of which use the AXP288: intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ... [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95 Instead of these errors on both devices we now correctly turn on / off DLDO3 (through direct register manipulation). On the Onda V80 plus this fixes an issue with the backlight being brighter around the borders after an off / on cycle. This should also help to save some power when the display is off. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-4-hdegoede@redhat.com
* | ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMICHans de Goede2019-01-091-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove PMIC. On some CHT devices this fixes the LCD panel not lighting up when it was not initialized by the GOP, because an external monitor was plugged in and the GOP initialized only the external monitor. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-3-hdegoede@redhat.com
* | ACPI / PMIC: Add support for executing PMIC MIPI sequence elementsHans de Goede2019-01-092-0/+54
|/ | | | | | | | | | | | | | | | | | | | | | DSI LCD panels describe an initialization sequence in the Video BIOS Tables using so called MIPI sequences. One possible element in these sequences is a PMIC specific element of 15 bytes. Although this is not really an ACPI opregion, the ACPI opregion code is the closest thing we have. We need to have support for these PMIC specific MIPI sequence elements somwhere. Since we already instantiate a special platform device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to, with PMIC specific implementations of the OpRegion, the handling of MIPI sequence PMIC elements fits very well in the ACPI PMIC OpRegion code. This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element() function, which is to be backed by a PMIC specific exec_mipi_pmic_seq_element callback. This function will be called by the i915 code to execture MIPI sequence PMIC elements. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107111556.4510-2-hdegoede@redhat.com
* ACPI / PMIC: xpower: Block P-Unit I2C access during read-modify-writeHans de Goede2018-10-251-6/+15
| | | | | | | | | | | | | | | intel_xpower_pmic_update_power() does a read-modify-write of the output control register. The i2c-designware code blocks the P-Unit I2C access during the read and write by taking the P-Unit's PMIC bus semaphore. But between the read and the write that semaphore is released and the P-Unit could make changes to the register which we then end up overwriting. This commit makes intel_xpower_pmic_update_power() take the semaphore itself so that it is held over the entire read-modify-write, avoiding this race. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Convert drivers to use SPDX identifierAndy Shevchenko2018-09-105-39/+8
| | | | | | | | | | Reduce size of duplicated comments by switching to use SPDX identifier. No functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Sort headers alphabeticallyAndy Shevchenko2018-09-103-5/+5
| | | | | | | | | | Sort headers alphabetically for better maintenance. No functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: CrystalCove: Extend PMOP support to support all possible fieldsHans de Goede2018-08-141-2/+107
| | | | | | | | | | | | | | | | | | | Prior to this commit the CRC PMOP handler only supported the X285 and V18X PMOP fields. Leading to errors like these on device using the VBUS field: [ 765.766489] ACPI Error: AE_BAD_PARAMETER, Returned by Handler for [UserDefinedRegion] (20180531/evregion-266) [ 765.766526] ACPI Error: Method parse/execution failed \_SB.I2C1.BATC._BST, AE_BAD_PARAMETER (20180531/psparse-516) [ 765.766586] ACPI Error: AE_BAD_PARAMETER, Evaluating _BST (20180531/battery-577) This commit adds support for all known fields to the CRC PMOP OpRegion handler, the name and register info in this commit comes from: https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/0002-ACPI-Adding-support-for-WC-and-CRC-opregion.patch Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Replace license boilerplate with SPDX license identifierrajmohan.mani@intel.com2018-02-221-9/+1
| | | | | | | | Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Convert to use builtin_platform_driver() macroAndy Shevchenko2018-01-115-28/+5
| | | | | | | | | | | | All of PMIC OpRegion drivers can't be modules, thus, convert them to use builtin_platform_driver() macro and remove redundant MODULE_*() macros. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: constify platform_device_idArvind Yadav2017-12-132-2/+2
| | | | | | | | | | | platform_device_id are not supposed to change at runtime. All functions working with platform_device_id provided by <linux/platform_device.h> work with const platform_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'mfd-next-4.15' of ↵Linus Torvalds2017-11-161-0/+137
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New drivers: - Add support for Cherry Trail Dollar Cove TI PMIC - Add support for Add Spreadtrum SC27xx series PMICs New device support: - Add support Regulator to axp20x New functionality: - Add DT support; aspeed-scu sc27xx-pmic - Add power saving support; rts5249 Fix-ups: - DT clean-up/rework; tps65217, max77693, iproc-cdru, iproc-mhb, tps65218 - Staticise/constify; stw481x - Use new succinct IRQ API; fsl-imx25-tsadc - Kconfig fix-ups; MFD_TPS65218 - Identify SPI method; lpc_ich - Use managed resources (devm_*) calls; ssbi - Remove unused/obsolete code/documentation; mc13xxx Bug fixes: - Fix typo in MAINTAINERS - Fix error handling; mxs-lradc - Clean-up IRQs on .remove; fsl-imx25-tsadc" * tag 'mfd-next-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (21 commits) dt-bindings: mfd: mc13xxx: Remove obsolete property mfd: axp20x: Add axp20x-regulator cell for AXP813 mfd: Add Spreadtrum SC27xx series PMICs driver dt-bindings: mfd: Add Spreadtrum SC27xx PMIC documentation mfd: ssbi: Use devm_of_platform_populate() mfd: fsl-imx25: Clean up irq settings during removal mfd: mxs-lradc: Fix error handling in mxs_lradc_probe() mfd: lpc_ich: Avoton/Rangeley uses SPI_BYT method mfd: tps65218: Introduce dependency on CONFIG_OF mfd: tps65218: Correct the config description MAINTAINERS: Fix Dialog search term for watchdog binding file mfd: fsl-imx25: Set irq handler and data in one go mfd: rts5249: Add support for RTS5250S power saving ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC mfd: Add support for Cherry Trail Dollar Cove TI PMIC syscon: dt-bindings: Add binding document for iProc MHB block syscon: dt-bindings: Add binding doc for Broadcom iProc CDRU mfd: max77693: Add muic of_compatible in mfd_cell mfd: stw481x: Make three arrays static const, reduces object code size mfd: tps65217: Introduce dependency on CONFIG_OF ...
| * ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMICTakashi Iwai2017-10-131-0/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to follow other PMIC opregion drivers convention. The re-enumeration of devices at probe is required for fixing the issues on HP x2 210 G2. See bug#195689. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| |
| \
*-. | Merge branches 'acpi-pmic', 'acpi-apei' and 'acpi-x86'Rafael J. Wysocki2017-11-131-0/+455
|\ \| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-pmic: ACPI / PMIC: Add TI PMIC TPS68470 operation region driver * acpi-apei: APEI / ERST: use 64-bit timestamps ACPI / APEI: Remove arch_apei_flush_tlb_one() arm64: mm: Remove arch_apei_flush_tlb_one() ACPI / APEI: Remove ghes_ioremap_area ACPI / APEI: Replace ioremap_page_range() with fixmap ACPI / APEI: remove the unused dead-code for SEA/NMI notification type ACPI / APEI: adjust a local variable type in ghes_ioremap_pfn_irq() * acpi-x86: ACPI / x86: Extend KIOX000A quirk to cover all affected BIOS versions
| * | ACPI / PMIC: Add TI PMIC TPS68470 operation region driverRajmohan Mani2017-10-031-0/+455
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kabylake platform coreboot (Chrome OS equivalent of BIOS) has defined 4 operation regions for the TI TPS68470 PMIC. These operation regions are to enable/disable voltage regulators, configure voltage regulators, enable/disable clocks and to configure clocks. This config adds ACPI operation region support for TI TPS68470 PMIC. TPS68470 device is an advanced power management unit that powers a Compact Camera Module (CCM), generates clocks for image sensors, drives a dual LED for flash and incorporates two LED drivers for general purpose indicators. This driver enables ACPI operation region support to control voltage regulators and clocks for the TPS68470 PMIC. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* / License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2017-11-021-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / PMIC: xpower: Do pinswitch magic when reading GPADCHans de Goede2017-07-241-3/+18
| | | | | | | | | | | | | | | | Testing has shown that the TS-pin's bias-current needs to be disabled when reading the GPIO0 pin in GPADC mode. It seems that there is only 1 bias current source and to be able to use it for the GPIO0 pin in GPADC mode it must be temporarily turned off for the TS pin, but the datasheet does not mention this. This commit adds the necessary writes to turn the TS pin BIAS current off before and back on after reading the GPADC. This fixes the GPADC always returning a reading of 0. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: xpower: Add support for the GPI1 regulator to the OpRegion handlerHans de Goede2017-06-221-1/+20
| | | | | | | | | | | | Some Bay Trail devices use a GPI1 regulator field (address 0x4c) in their 0x8d power OpRegion, add support for this. This fixes AE_BAD_PARAMETER errors getting thrown on these devices and fixes these errors causing these devices to not suspend. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: xpower: Fix power_table addressesHans de Goede2017-04-281-25/+25
| | | | | | | | | | | | | | | | | | | | | The power table addresses should be contiguous, but there was a hole where 0x34 was missing. On most devices this is not a problem as addresses above 0x34 are used for the BUC# convertors which are not used in the DSDTs I've access to but after the BUC# convertors there is a field named GPI1 in the DSTDs, which does get used in some cases and ended up turning BUC6 on and off due to the wrong addresses, resulting in turning the entire device off (or causing it to reboot). Removing the hole in the addresses fixes this, fixing one of my Bay Trail tablets turning off while booting the mainline kernel. While at it add comments with the field names used in the DSDTs to make it easier to compare the register and bits used at each address with the datasheet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Stop xpower OPRegion handler relying on IIOHans de Goede2017-04-201-17/+4
| | | | | | | | | | | | | | | | | | | | The intel_pmic_xpower code provides an OPRegion handler, which must be available before other drivers using it are loaded, which can only be ensured if both the mfd and opregion drivers are built in, which is why the Kconfig option for intel_pmic_xpower is a bool. The use of IIO is causing trouble for generic distro configs here as distros will typically want to build IIO drivers as modules and there really is no reason to use IIO here. The reading of the ADC value is a single regmap_bulk_read, which is already protected against races by the regmap-lock. This commit removes the use of IIO, allowing distros to enable the driver without needing to built IIO in and also actually simplifies the code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Add opregion driver for Intel CHT Whiskey Cove PMICHans de Goede2017-04-201-0/+280
| | | | | | | | | | Add opregion driver for Intel CHT Whiskey Cove PMIC, based on various non upstreamed CHT Whiskey Cove PMIC patches. This does not include support for the Thermal opregion (DPTF) due to lacking documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: remove modular references from non-modular codePaul Gortmaker2016-07-163-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of these files are: drivers/acpi/Kconfig:menuconfig PMIC_OPREGION drivers/acpi/Kconfig: bool "PMIC (Power Management Integrated Circuit) operation region support" drivers/acpi/Kconfig:config BXT_WC_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for BXT WhiskeyCove PMIC" drivers/acpi/Kconfig:config XPOWER_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for XPower AXP288 PMIC" ...meaning they currently are not being built as a module by anyone. Lets remove the couple traces of modular infrastructure use, so that when reading the code there is no doubt it is builtin-only. We delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. One file was using module_init. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. In one case we replace the module.h with export.h since that file is exporting some symbols, but does not use __init. The other two are using __init and so module.h gets replaced with init.h there. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: intel: initialize result to 0Felipe Balbi2016-06-271-1/+1
| | | | | | | | Fixes compiler warning. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: intel: add REGS operation region supportFelipe Balbi2016-06-271-1/+66
| | | | | | | | | At least some of the Broxtons have a third custom OpRegion named REGS. This adds handling for it. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMICBin Gao2016-06-241-0/+424
| | | | | | | | | | This patch adds operation region driver for Intel BXT WhiskeyCove PMIC. The register mapping is done as per the BXT WC data sheet. Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: modify the pen function signature to take bit fieldBin Gao2016-06-243-10/+12
| | | | | | | | | | | | | | | | Issue description: On some pmics, the policy enable for thermal alerts refers to different bit fields of the same registers, whereas on other pmics, the policy enable refers to the same bit field on different registers. Previous implementation did not provide the flexibility for supporting the first approach. Solution: Modified the policy enable function to take bit field as well. The use of bit field is left to the pmic specific opregion driver. Signed-off-by: Yegnesh Iyer <yegnesh.s.iyer@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* drivers/acpi: make pmic/intel_pmic_crc.c explicitly non-modularPaul Gortmaker2016-03-091-5/+2
| | | | | | | | | | | | | | | | | | | | | | The Kconfig currently controlling compilation of this code is: drivers/acpi/Kconfig:config CRC_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for CrystalCove PMIC" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple modular references, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI/PMIC: Fix typo in MODULE_DESCRIPTION in intel_pmic_crc.cMasanari Iida2015-03-261-1/+1
| | | | | | | This patch fix a spelling typo in MODULE_DESCRIPTION within intel_pmic_crc.c Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PMIC: Use common LPAT table handling functionsSrinivas Pandruvada2015-01-291-115/+18
| | | | | | | | | The LPAT table processing functions from this modules are moved to a standalone module with exported interface functions. Using new interface functions in this module. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
* ACPI / PMIC: AXP288: support virtual GPIO in ACPI tableAaron Lu2014-11-261-4/+26
| | | | | | | | | | | | | | The same virtual GPIO strategy is also used for the AXP288 PMIC in that various control methods that are used to do power rail handling and sensor reading/setting will touch GPIO fields defined under the PMIC device. The GPIO fileds are only defined by the ACPI code while the actual hardware doesn't really have a GPIO controller, but to make those control method execution succeed, we have to install a GPIO handler for the PMIC device handle. Since we do not need the virtual GPIO strategy, we can simply do nothing in that handler. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 19:26:29 +0000