summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
2024-09-01Merge tag 'pwrseq-fixes-for-v6.11-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fix from Bartosz Golaszewski: "A follow-up fix for the power sequencing subsystem. It turned out the previous fix for this driver was incomplete and broke the WLAN support on some platforms. This addresses the issue. - set the direction of the wlan-enable GPIO to output after requesting it as-is" * tag 'pwrseq-fixes-for-v6.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: qcom-wcn: set the wlan-enable GPIO to output
2024-08-31power: sequencing: qcom-wcn: set the wlan-enable GPIO to outputBartosz Golaszewski
Commit a9aaf1ff88a8 ("power: sequencing: request the WLAN enable GPIO as-is") broke WLAN on boards on which the wlan-enable GPIO enabling the wifi module isn't in output mode by default. We need to set direction to output while retaining the value that was already set to keep the ath module on if it's already started. Fixes: a9aaf1ff88a8 ("power: sequencing: request the WLAN enable GPIO as-is") Link: https://lore.kernel.org/r/20240823115500.37280-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-09-01Merge tag 'arm-fixes-6.11-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "There is a fairly large number of bug fixes for Qualcomm platforms, most of them addressing issues with the devicetree files for the newly added Snapdragon X1 based laptops to make them more reliable. The Qualcomm driver changes address a few build-time issues as well as runtime problems in the tzmem and scm firmware, the USB Type-C driver, and the cmd-db and pmic_glink soc drivers. The NXP i.MX usually gets a bunch of devicetree fixes that is proportional to the number of supported machines. This includes both warning fixes and correctness for the 64-bit i.MX9, i.MX8 and layerscape platforms, as well as a single fix for a 32-bit i.MX6 based board. The other changes are the usual minor changes, including an update to the MAINTAINERS file, an omap3 dts file and a SoC driver for mpfs (risc-v)" * tag 'arm-fixes-6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (50 commits) firmware: microchip: fix incorrect error report of programming:timeout on success soc: qcom: pd-mapper: Fix singleton refcount firmware: qcom: tzmem: disable sdm670 platform soc: qcom: pmic_glink: Actually communicate when remote goes down usb: typec: ucsi: Move unregister out of atomic section soc: qcom: pmic_glink: Fix race during initialization firmware: qcom: qseecom: remove unused functions firmware: qcom: tzmem: fix virtual-to-physical address conversion firmware: qcom: scm: Mark get_wq_ctx() as atomic call arm64: dts: qcom: x1e80100: Fix Adreno SMMU global interrupt arm64: dts: qcom: disable GPU on x1e80100 by default arm64: dts: imx8mm-phygate: fix typo pinctrcl-0 arm64: dts: imx95: correct L3Cache cache-sets arm64: dts: imx95: correct a55 power-domains arm64: dts: freescale: imx93-tqma9352-mba93xxla: fix typo arm64: dts: freescale: imx93-tqma9352: fix CMA alloc-ranges ARM: dts: imx6dl-yapp43: Increase LED current to match the yapp4 HW design arm64: dts: imx93: update default value for snps,clk-csr arm64: dts: freescale: tqma9352: Fix watchdog reset arm64: dts: imx8mp-beacon-kit: Fix Stereo Audio on WM8962 ...
2024-08-28Merge tag 'qcom-drivers-fixes-for-6.11' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm driver fixes for v6.11 This corrects the tzmem virt-to-phys conversion, which caused issues for the uefisecapp implementation of EFI variable access. SDM670 is excluded from tzmem usage due to reported issues. The SCM get wait queue context call is corrected to be marked ATOMIC and some dead code in qseecom, following the tzmem conversion, is removed. The memory backing command DB is remapped writecombined, to avoid XPU violations when Linux runs without the Qualcomm hypervisor. Two compile fixes are added for pd-mapper, and the broken reference count is corrected, to make pd-mapper deal with remoteprocs going away. In pmic_glink a race condition where the client callbacks might be called before we returned the client handle is corrected. The broken conditions for when to signal that the firmware is going down is also corrected. In the pmic_glink UCSI driver, the ucsi_unregister() is moved out of the pdr callback, as this is being invoked in atomic context. Konrad's email address is updated in MAINTAINERS, and related mailmap entries are added. * tag 'qcom-drivers-fixes-for-6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: pd-mapper: Fix singleton refcount firmware: qcom: tzmem: disable sdm670 platform soc: qcom: pmic_glink: Actually communicate when remote goes down usb: typec: ucsi: Move unregister out of atomic section soc: qcom: pmic_glink: Fix race during initialization firmware: qcom: qseecom: remove unused functions firmware: qcom: tzmem: fix virtual-to-physical address conversion firmware: qcom: scm: Mark get_wq_ctx() as atomic call MAINTAINERS: Update Konrad Dybcio's email address mailmap: Add an entry for Konrad Dybcio soc: qcom: pd-mapper: mark qcom_pdm_domains as __maybe_unused soc: qcom: cmd-db: Map shared memory as WC, not WB soc: qcom: pd-mapper: Depend on ARCH_QCOM || COMPILE_TEST Link: https://lore.kernel.org/r/20240826145209.1646159-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-08-23Merge tag 'pwrseq-fixes-for-v6.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fix from Bartosz Golaszewski: - request the wlan-enable GPIO "as-is" to fix an issue with the wifi module being already powered up before linux boots * tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: request the WLAN enable GPIO as-is
2024-08-21soc: qcom: pmic_glink: Fix race during initializationBjorn Andersson
As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized. The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced. Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) <schedule away> pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) <client is NULL BAD> ucsi->client = client // Too late! This code is identical across the altmode, battery manager and usci child drivers. Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations. This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely. Reported-by: Amit Pundir <amit.pundir@linaro.org> Closes: https://lore.kernel.org/all/CAMi1Hd2_a7TjA7J9ShrAbNOd_CoZ3D87twmO5t+nZxC9sX18tA@mail.gmail.com/ Reported-by: Johan Hovold <johan@kernel.org> Closes: https://lore.kernel.org/all/ZqiyLvP0gkBnuekL@hovoldconsulting.com/ Reported-by: Stephen Boyd <swboyd@chromium.org> Closes: https://lore.kernel.org/all/CAE-0n52JgfCBWiFQyQWPji8cq_rCsviBpW-m72YitgNfdaEhQg@mail.gmail.com/ Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Amit Pundir <amit.pundir@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-1-eec53c750a04@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-08-19power: sequencing: request the WLAN enable GPIO as-isBartosz Golaszewski
If the WCN module is powered up before linux boots and the ath11k driver probes at the same time as the power sequencing driver, we may end up driving the wlan-enable GPIO low in the latter, breaking the start-up of the WLAN module. Request the wlan-enable GPIO as-is so that if the WLAN module is already starting/started, we leave it alone. Fixes: 2f1630f437df ("power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets") Reported-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20240813190751.155035-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-08-07Merge tag 'for-v6.11-rc' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fixes from Sebastian Reichel: "rt5033: - fix driver regression causing kernel oops axp288-charger: - fix charge voltage setup qcom-battmgr: - fix thermal zone spamming errors - fix init on Qualcomm X Elite" * tag 'for-v6.11-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: qcom_battmgr: Ignore extra __le32 in info payload power: supply: qcom_battmgr: return EAGAIN when firmware service is not up power: supply: axp288_charger: Round constant_charge_voltage writes down power: supply: axp288_charger: Fix constant_charge_voltage writes power: supply: rt5033: Bring back i2c_set_clientdata
2024-07-27power: supply: qcom_battmgr: Ignore extra __le32 in info payloadStephan Gerhold
Some newer ADSP firmware versions on X1E80100 report an extra __le32 at the end of the battery information request payload, causing qcom_battmgr to fail to initialize. Adjust the check to ignore the extra field in the info payload so we can support both old and newer firmware versions. Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240712-x1e80100-battmgr-v1-1-a253d767f493@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-27power: supply: qcom_battmgr: return EAGAIN when firmware service is not upNeil Armstrong
The driver returns -ENODEV when the firmware battmrg service hasn't started yet, while per-se -ENODEV is fine, we usually use -EAGAIN to tell the user to retry again later. And the power supply core uses -EGAIN when the device isn't initialized, let's use the same return. This notably causes an infinite spam of: thermal thermal_zoneXX: failed to read out thermal zone (-19) because the thermal core doesn't understand -ENODEV, but only considers -EAGAIN as a non-fatal error. While it didn't appear until now, commit [1] fixes thermal core and no more ignores thermal zones returning an error at first temperature update. [1] 5725f40698b9 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid") Link: https://lore.kernel.org/all/2ed4c630-204a-4f80-a37f-f2ca838eb455@linaro.org/ Cc: stable@vger.kernel.org Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20240715-topic-sm8x50-upstream-fix-battmgr-temp-tz-warn-v1-1-16e842ccead7@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-27power: supply: axp288_charger: Round constant_charge_voltage writes downHans de Goede
Round constant_charge_voltage writes down to the first supported lower value, rather then rounding them up to the first supported higher value. This fixes e.g. writing 4250000 resulting in a value of 4350000 which might be dangerous, instead writing 4250000 will now result in a safe 4200000 value. Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240717200333.56669-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-27power: supply: axp288_charger: Fix constant_charge_voltage writesHans de Goede
info->max_cv is in millivolts, divide the microvolt value being written to constant_charge_voltage by 1000 *before* clamping it to info->max_cv. Before this fix the code always tried to set constant_charge_voltage to max_cv / 1000 = 4 millivolt, which ends up in setting it to 4.1V which is the lowest supported value. Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240717200333.56669-1-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-23Merge tag 'for-v6.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Power-supply core: - new charging_orange_full_green RGB LED trigger - simplify and cleanup power-supply LED trigger code - expose power information via hwmon compatibility layer New hardware support: - enable battery support for Qualcomm Snapdragon X Elite - new battery driver for Maxim MAX17201/MAX17205 - new battery driver for Lenovo Yoga C630 laptop (custom EC) Cleanups: - cleanup 'struct i2c_device_id' initializations - misc small battery driver cleanups and fixes" * tag 'for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: sysfs: use power_supply_property_is_writeable() power: supply: qcom_battmgr: Enable battery support on x1e80100 power: supply: add support for MAX1720x standalone fuel gauge dt-bindings: power: supply: add support for MAX17201/MAX17205 fuel gauge power: reset: piix4: add missing MODULE_DESCRIPTION() macro power: supply: samsung-sdi-battery: Constify struct power_supply_maintenance_charge_table power: supply: samsung-sdi-battery: Constify struct power_supply_vbat_ri_table power: supply: lenovo_yoga_c630_battery: add Lenovo C630 driver power: supply: ingenic: Fix some error handling paths in ingenic_battery_get_property() power: supply: ab8500: Clean some error messages power: supply: ab8500: Use iio_read_channel_processed_scale() power: supply: ab8500: Fix error handling when calling iio_read_channel_processed() power: supply: hwmon: Add support for power sensors power: supply: ab8500: remove unused struct 'inst_curr_result_list' power: supply: bd99954: remove unused struct 'battery_data' power: supply: leds: Add activate() callback to triggers power: supply: leds: Share trig pointer for online and charging_full power: supply: leds: Add power_supply_[un]register_led_trigger() power: supply: Drop explicit initialization of struct i2c_device_id::driver_data to 0
2024-07-19Merge tag 'pwrseq-fixes-for-v6.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fixes from Bartosz Golaszewski: "There's one fix for an invalid pointer dereference in error path reported by smatch and two patches that address the noisy config choices you reported earlier this week. Summary: - fix an invalid pointer dereference in error path in pwrseq core - reduce the Kconfig noise from PCI pwrctl choices" * tag 'pwrseq-fixes-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: arm64: qcom: don't select HAVE_PWRCTL when PCI=n Kconfig: reduce the amount of power sequencing noise power: sequencing: fix an invalid pointer dereference in error path
2024-07-17Merge tag 'leds-next-6.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "Core Frameworks: - New trigger for Input Events - New led_mc_set_brightness() call to adapt colour/brightness for mutli-colour LEDs - New lled_mc_trigger_event() call to call the above based on given trigger conditions - New led_get_color_name() call, a wrapper around the existing led_colors[] array - A new flag to avoid automatic renaming of LED devices New Drivers: - Silergy SY7802 Flash LED Controller - Texas Instruments LP5569 LED Controller - ChromeOS EC LED Controller New Device Support: - KTD202{6,7} support for Kinetic KTD2026/7 LEDs Fix-ups: - Replace ACPI/DT firmware helpers with agnostic variants - Make use of resource managed devm_* API calls - Device Tree binding adaptions/conversions/creation - Constify/staticise applicable data structures - Trivial; spelling, whitespace, coding-style adaptions - Drop i2c_device_id::driver_data where the value is unused - Utilise centrally provided helpers and macros to aid simplicity and avoid duplication - Use generic platform device properties instead of OF/ACPI specific ones - Consolidate/de-duplicate various functionality - Remove superfluous/duplicated/unused sections - Make use of the new *_scoped() guard APIs - Improve/simplify error handling Bug Fixes: - Flush pending brightness changes before activating the trigger - Repair incorrect device naming preventing matches - Prevent memory leaks by correctly free resources during error handling routines - Repair locking issue causing circular dependency splats and lock-ups - Unregister sysfs entries before deactivating triggers to prevent use-after issues - Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings - Use correct return codes expected by the callers - Omit set_brightness() error message for a LEDs that support only HW triggers" * tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (65 commits) leds: leds-lp5569: Enable chip after chip configuration leds: leds-lp5569: Better handle enabling clock internal setting leds: leds-lp5569: Fix typo in driver name leds: flash: leds-qcom-flash: Test the correct variable in init leds: leds-lp55xx: Convert mutex lock/unlock to guard API leds: leds-lp5523: Convert to sysfs_emit API leds: leds-lp5569: Convert to sysfs_emit API Revert "leds: led-core: Fix refcount leak in of_led_get()" leds: leds-lp5569: Add support for Texas Instruments LP5569 leds: leds-lp55xx: Drop deprecated defines leds: leds-lp55xx: Support ENGINE program up to 128 bytes leds: leds-lp55xx: Generalize sysfs master_fader leds: leds-lp55xx: Generalize sysfs engine_leds leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode leds: leds-lp55xx: Generalize stop_engine function leds: leds-lp55xx: Generalize turn_off_channels function leds: leds-lp55xx: Generalize set_led_current function leds: leds-lp55xx: Generalize multicolor_brightness function leds: leds-lp55xx: Generalize led_brightness function leds: leds-lp55xx: Generalize firmware_loaded function ...
2024-07-17power: sequencing: fix an invalid pointer dereference in error pathBartosz Golaszewski
We may end up calling pwrseq_target_free() on a partially initialized target object whose unit is either NULL or an ERR_PTR(). Avoid dereferencing invalid memory by adding an appropriate check to pwrseq_target_free(). Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-pm/62a3531e-9927-40f8-b587-254a2dfa47ef@stanley.mountain/ Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20240712194004.241939-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-15Merge tag 'pwrseq-updates-for-v6.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing updates from Bartosz Golaszewski: "This has been in development since last year's Linux Plumbers Conference and was inspired by the need to enable support upstream for Bluetooth/WLAN chips on Qualcomm platforms. The main problem we're fixing is powering up devices which are represented as separate objects in the kernel (binding to different drivers) but which share parts of the power-up sequence and thus need some kind of a mediator who knows the possible interactions and can assure they don't interfere with neither device's bring up. An example of such an inter-driver interaction is the WCN family of BT/WLAN chips from Qualcomm of which some models require the user to observe a certain delay between driving the bt-enable and wlan-enable GPIOs. This is not a new problem but up to this point all attempts at addressing it ended up hitting one wall or another and being dropped. The main obstacle was the fact that most these attempts tried to introduce the concept of a "power sequence" into the device-tree bindings which breaks the main DT rule: describe the hardware, not its behavior. The solution I proposed focuses on making the power sequencer drivers interpret the actual HW description flexibly. More details on that are in the linked cover letter. The second problem fixed here is powering up PCI devices before they are detected on the bus. This is achieved by creating special platform devices for device-tree nodes describing hard-wired PCI devices which bind to the so-called PCI power control drivers which enable required resources and trigger a bus rescan once the controlled device is up then setup the correct devlink hierarchy for power-management. By combining the two new frameworks we implemented the power sequencing PCI power control driver which is capable of powering up the WLAN modules of the QCom WCN family of chipsets. All this has spent a significant amount of time in linux-next and enabled WLAN/BT support on several Qualcomm platforms. To further prove that this is useful and needed: right after this was picked up into next, I was sent a series using the subsystem for a similar use-case on Amlogic platforms. This contains the core power sequencing framework, the first driver, PCI changes using the pwrseq library (blessed by Bjorn Helgaas) and some fixes that came later" * tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: PCI/pwrctl: only call of_platform_populate() if CONFIG_OF is enabled power: sequencing: simplify returning pointer without cleanup PCI/pwrctl: Add a PCI power control driver for power sequenced devices PCI/pwrctl: Add PCI power control core code PCI/pwrctl: Create platform devices for child OF nodes of the port node PCI/pwrctl: Reuse the OF node for power controlled devices PCI: Hold the rescan mutex when scanning for the first time power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets power: sequencing: implement the pwrseq core
2024-07-05power: supply: cros_charge-control: Fix signedness bug in ↵Dan Carpenter
charge_behaviour_store() The C standard is vague about the signedness of enums, but in this case here, they are treated as unsigned so the error handling does not work. Use an int type to fix this. Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/ZoWKEs4mCqeLyTOB@stanley.mountain Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-04power: supply: sysfs: use power_supply_property_is_writeable()Thomas Weißschuh
Instead of open-coding the helper use it directly. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240608-power-supply-extensions-v2-1-2dcd35b012ad@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-04power: supply: qcom_battmgr: Enable battery support on x1e80100Abel Vesa
The x1e80100, being a compute platform, provides functionality for the exact same power supplies as sc8280xp. Add the compatible and assign the sc8280xp match data. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240621-x1e80100-power-supply-qcom-battmgr-v1-1-40cb89a0c144@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-04power: supply: add support for MAX1720x standalone fuel gaugeDimitri Fedrau
The MAX17201 monitors a single cell pack. The MAX17205 monitors and balances a 2S or 3S pack or monitors a multiple-series cell pack. Both devices use a I2C interface. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20240702090308.8848-3-dima.fedrau@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-07-03power: sequencing: simplify returning pointer without cleanupKrzysztof Kozlowski
Use 'return_ptr' helper for returning a pointer without cleanup for shorter code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240703083038.95777-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-03power: supply: cros_charge-control: Avoid accessing attributes out of boundsNathan Chancellor
Clang warns (or errors with CONFIG_WERROR=y): drivers/power/supply/cros_charge-control.c:319:2: error: array index 3 is past the end of the array (that has type 'struct attribute *[3]') [-Werror,-Warray-bounds] 319 | priv->attributes[_CROS_CHCTL_ATTR_COUNT] = NULL; | ^ ~~~~~~~~~~~~~~~~~~~~~~ drivers/power/supply/cros_charge-control.c:49:2: note: array 'attributes' declared here 49 | struct attribute *attributes[_CROS_CHCTL_ATTR_COUNT]; | ^ 1 error generated. In earlier revisions of the driver, the attributes array in cros_chctl_priv had four elements with four distinct assignments but during review, the number of elements was changed to three through use of an enum and the assignments became a for loop, except for this one, which is now out of bounds. This assignment is no longer necessary because the size of the attributes array no longer accounts for it, so just remove it to clear up the warning. Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240702-cros_charge-control-fix-clang-array-bounds-warning-v1-1-ae04d995cd1d@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01power: supply: cros_charge-control: don't load if Framework control is presentThomas Weißschuh
Framework laptops implement a custom charge control EC command. The upstream CrOS EC command is also present and functional but can get overridden by the custom one. Until Framework make both commands compatible or remove their custom one, don't load the driver on those machines. If the user knows they are not going to use the custom command they can use a module parameter to load cros_charge-control anyways. Note that the UEFI setup configuration for battery control also uses their custom command. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-5-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01power: supply: add ChromeOS EC based charge control driverThomas Weißschuh
The ChromeOS Embedded Controller implements a command to control charge thresholds and behaviour. Use it to implement the standard Linux charge_control_start_threshold, charge_control_end_threshold and charge_behaviour sysfs UAPIs. The driver is designed to be probed via the cros_ec mfd device. Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-4-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-06-26power: reset: piix4: add missing MODULE_DESCRIPTION() macroJeff Johnson
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/power/reset/piix4-poweroff.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240608-md-drivers-power-reset-v1-1-08dbc1a546a2@quicinc.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: samsung-sdi-battery: Constify struct ↵Christophe JAILLET
power_supply_maintenance_charge_table 'struct power_supply_maintenance_charge_table' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, some code also needs to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o After: ===== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4087 4552 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/6caafd0ac2556a40405273b1a4badc508ea8e9b0.1719125040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: samsung-sdi-battery: Constify struct power_supply_vbat_ri_tableChristophe JAILLET
'struct power_supply_vbat_ri_table' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increase overall security. In order to do it, some code also needs to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 955 7664 0 8619 21ab drivers/power/supply/samsung-sdi-battery.o After: ===== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/d01818abd880bf435d1106a9a6cc11a7a8a3e661.1719125040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: lenovo_yoga_c630_battery: add Lenovo C630 driverDmitry Baryshkov
On the Lenovo Yoga C630 WOS laptop the EC provides access to the adapter and battery status. Add the driver to read power supply status on the laptop. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240621-yoga-ec-driver-v8-1-daae67d0233d@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: ingenic: Fix some error handling paths in ↵Christophe JAILLET
ingenic_battery_get_property() If iio_read_channel_processed() fails, 'val->intval' is not updated, but it is still *1000 just after. So, in case of error, the *1000 accumulate and 'val->intval' becomes erroneous. So instead of rescaling the value after the fact, use the dedicated scaling API. This way the result is updated only when needed. In case of error, the previous value is kept, unmodified. This should also reduce any inaccuracies resulting from the scaling. Finally, this is also slightly more efficient as it saves a function call and a multiplication. Fixes: fb24ccfbe1e0 ("power: supply: add Ingenic JZ47xx battery driver.") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Artur Rojek <contact@artur-rojek.eu> Link: https://lore.kernel.org/r/51e49c18574003db1e20c9299061a5ecd1661a3c.1719121781.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: ab8500: Clean some error messagesChristophe JAILLET
There is an useless extra comma at the end of some error messages, remove them. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/e7ac0fa83c6100cbe4e0efa90cf99291c2423b10.1719037737.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: ab8500: Use iio_read_channel_processed_scale()Christophe JAILLET
Instead of rescaling current or voltage channels after the fact, use the dedicated scaling API. This should reduce any inaccuracies resulting from the scaling. This is also slightly more efficient as it saves a function call and a multiplication. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/5668d73b92eb6318c7f094a9a8fa914c909485ca.1719037737.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: ab8500: Fix error handling when calling ↵Christophe JAILLET
iio_read_channel_processed() The ab8500_charger_get_[ac|vbus]_[current|voltage]() functions should return an error code on error. Up to now, an un-initialized value is returned. This makes the error handling of the callers un-reliable. Return the error code instead, to fix the issue. Fixes: 97ab78bac5d0 ("power: supply: ab8500_charger: Convert to IIO ADC") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/f9f65642331c9e40aaebb888589db043db80b7eb.1719037737.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-12power: pwrseq: add a driver for the PMU module on the QCom WCN chipsetsBartosz Golaszewski
This adds the power sequencing driver for the PMU modules present on the Qualcomm WCN Bluetooth and Wifi chipsets. It uses the pwrseq subsystem and knows how to match the sequencer to the consumer device by verifying the relevant properties and DT layout. Using this driver will allow the BT and WLAN drivers to respect the required delays between enabling the two modules. Tested-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240605123850.24857-3-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-06-12power: sequencing: implement the pwrseq coreBartosz Golaszewski
Implement the power sequencing subsystem allowing devices to share complex powering-up and down procedures. It's split into the consumer and provider parts but does not implement any new DT bindings so that the actual power sequencing is never revealed in the DT representation. Tested-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240605123850.24857-2-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-06-05power: supply: rt5033: Bring back i2c_set_clientdataNikita Travkin
Commit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper") reworked the driver to use devm. While at it, the i2c_set_clientdata was dropped along with the remove callback. Unfortunately other parts of the driver also rely on i2c clientdata so this causes kernel oops. Bring the call back to fix the driver. Fixes: 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper") Tested-by: Raymond Hackley <raymondhackley@protonmail.com> Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20240605-rt5033-null-clientdata-v1-1-558d710eeb4d@trvn.ru Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: hwmon: Add support for power sensorsArmin Wolf
Currently, more than seven power supply drivers are supporting POWER_SUPPLY_PROP_POWER_NOW, but their power readings are not being reported through the hwmon subsystem. Fix this by adding support for power sensors to the power supply hwmon integration. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240528222115.791511-1-W_Armin@gmx.de Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: ab8500: remove unused struct 'inst_curr_result_list'Dr. David Alan Gilbert
'inst_curr_result_list' is unused since the original commit 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver"). Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240528000634.196707-3-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: bd99954: remove unused struct 'battery_data'Dr. David Alan Gilbert
'battery_data' is unused since the original commit 0902f8366491 ("power: supply: Support ROHM bd99954 charger"). Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/20240528000634.196707-2-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: leds: Add activate() callback to triggersHans de Goede
Add an activate() callback to the power-supply LED triggers so that the LED being activated will properly reflect the current power-supply state for power-supply devices which are already fully registered when the trigger gets activated. This fixes e.g. wrong LED state (1) when the LED gets registered after the power-supply device. 1) Until the psy driver has a reason to call power_supply_changed() which may take quite a while Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531134702.166145-4-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: leds: Share trig pointer for online and charging_fullHans de Goede
Either 5 different LED triggers are registered for battery power-supply devices or a single online LED trigger is used for non battery power-supply devices. These 5 / 1 LED trigger(s) are never used at the same time. So there is no need for a separate LED trigger pointer for the online trigger. Rename the first battery trigger from charging_full_trig to just trig and use this for the online trigger too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531134702.166145-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: leds: Add power_supply_[un]register_led_trigger()Hans de Goede
Add power_supply_[un]register_led_trigger() helper functions. The primary goal of this is as a preparation patch for adding an activate callback to the power-supply LED triggers to ensure that power-supply LEDs get the correct initial value when the LED gets registered after the power_supply has been registered (this will use the psy back pointer). There also is quite a lot of code duplication in the existing LED trigger registration in the form of the kasprintf() for the name-template for each trigger + related error handling. This duplication is removed by these new helpers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531134702.166145-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03Merge tag 'ib-leds-platform-power-v6.11'Sebastian Reichel
Immutable branch between LEDs, Power and RGB due for the v6.11 merge window. Merge it to provide functionality required by power-supply specific LED handler cleanups depending on the newly added (multi-colour) LED features. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-05-31power: supply: power-supply-leds: Add charging_orange_full_green trigger for ↵Kate Hsuan
RGB LED Add a charging_orange_full_green LED trigger and the trigger is based on led_mc_trigger_event() which can set an RGB LED when the trigger is triggered. The LED will show orange when the battery status is charging. The LED will show green when the battery status is full. Link: https://lore.kernel.org/linux-leds/f40a0b1a-ceac-e269-c2dd-0158c5b4a1ad@gmail.com/ Signed-off-by: Kate Hsuan <hpa@redhat.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> [hdegoede@redhat.com change color order to RGB] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-7-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-27power: supply: Drop explicit initialization of struct ↵Uwe Kleine-König
i2c_device_id::driver_data to 0 These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240522164830.61646-2-u.kleine-koenig@pengutronix.de Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-05-20Merge tag 'i2c-for-6.10-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "i2c core removes an argument from the i2c_mux_add_adapter() call to further deprecate class based I2C device instantiation. All users are converted, too. Other that that, Andi collected a number if I2C host driver patches. Those merges have their own description" * tag 'i2c-for-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (72 commits) power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter() i2c: mux: Remove class argument from i2c_mux_add_adapter() i2c: synquacer: Fix an error handling path in synquacer_i2c_probe() i2c: acpi: Unbind mux adapters before delete i2c: designware: Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE() i2c: pxa: use 'time_left' variable with wait_event_timeout() i2c: s3c2410: use 'time_left' variable with wait_event_timeout() i2c: rk3x: use 'time_left' variable with wait_event_timeout() i2c: qcom-geni: use 'time_left' variable with wait_for_completion_timeout() i2c: jz4780: use 'time_left' variable with wait_for_completion_timeout() i2c: synquacer: use 'time_left' variable with wait_for_completion_timeout() i2c: stm32f7: use 'time_left' variable with wait_for_completion_timeout() i2c: stm32f4: use 'time_left' variable with wait_for_completion_timeout() i2c: st: use 'time_left' variable with wait_for_completion_timeout() i2c: omap: use 'time_left' variable with wait_for_completion_timeout() i2c: imx-lpi2c: use 'time_left' variable with wait_for_completion_timeout() i2c: hix5hd2: use 'time_left' variable with wait_for_completion_timeout() i2c: exynos5: use 'time_left' variable with wait_for_completion_timeout() i2c: digicolor: use 'time_left' variable with wait_for_completion_timeout() i2c: amd-mp2-plat: use 'time_left' variable with wait_for_completion_timeout() ...
2024-05-18Merge tag 'for-v6.10' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: - core: simplify POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR handling - test-power: add POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR support - chrome EC drivers: add ID based probing - bq27xxx: simplify update loop to reduce I2C traffic - max8903 binding: fix GPIO polarity description * tag 'for-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: dt-bindings: power: supply: max8903: specify flt-gpios as input power: supply: bq27xxx: Move health reading out of update loop power: supply: bq27xxx: Move cycle count reading out of update loop power: supply: bq27xxx: Move energy reading out of update loop power: supply: bq27xxx: Move charge reading out of update loop power: supply: bq27xxx: Move time reading out of update loop power: supply: bq27xxx: Move temperature reading out of update loop power: supply: cros_pchg: provide ID table for avoiding fallback match power: supply: cros_usbpd: provide ID table for avoiding fallback match power: supply: core: simplify charge_behaviour formatting power: supply: test-power: implement charge_behaviour property
2024-05-14power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter()Wolfram Sang
Commit 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device instantiation") removed the last call to i2c_mux_add_adapter() with a non-null class argument. Therefore the class argument can be removed. Note: Class-based device instantiation is a legacy mechanism which shouldn't be used in new code, so we can rule out that this argument may be needed again in the future. This driver was forgotten by the patch in the Fixes tag. Fixes: fec1982d7072 ("i2c: mux: Remove class argument from i2c_mux_add_adapter()") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-04-15power: supply: mt6360_charger: Fix of_match for usb-otg-vbus regulatorAngeloGioacchino Del Regno
The of_match shall correspond to the name of the regulator subnode, or the deprecated `regulator-compatible` property must be used: failing to do so, the regulator won't probe (and the driver will as well not probe). Since the devicetree binding for this driver is actually correct and wants DTs to use the "usb-otg-vbus-regulator" subnode name, fix this driver by aligning the `of_match` string to what the DT binding wants. Fixes: 0402e8ebb8b8 ("power: supply: mt6360_charger: add MT6360 charger support") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20240410084405.1389378-1-angelogioacchino.delregno@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-04-10power: rt9455: hide unused rt9455_boost_voltage_valuesArnd Bergmann
The rt9455_boost_voltage_values[] array is only used when USB PHY support is enabled, causing a W=1 warning otherwise: drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=] Enclose the definition in the same #ifdef as the references to it. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240403080702.3509288-10-arnd@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>