summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
2024-08-27power: reset: brcmstb: Use syscon_regmap_lookup_by_phandle_args() helperAndrew Davis
Simplify probe by fetching the regmap and its arguments in one call. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240610142836.168603-3-afd@ti.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: reset: brcmstb: Use device_get_match_data() for matchingAndrew Davis
Use device_get_match_data() for finding the matching node and fetching the match data all in one. Signed-off-by: Andrew Davis <afd@ti.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240610142836.168603-2-afd@ti.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: reset: brcmstb: Use normal driver register functionAndrew Davis
The platform_driver_probe() helper is useful when the probe function is in the _init section, that is not the case here. Use the normal platform_driver_register() function. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240610142836.168603-1-afd@ti.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: reset: pwr-mlxbf: support graceful shutdownAsmaa Mnebhi
The OCP board used a BlueField's GPIO pin for entering low power mode. That board was not commercialized and has been dropped from production so all its code is unused. The new hardware requirement is to trigger a graceful shutdown when that GPIO pin is toggled. So replace the unused low power mode with a graceful shutdown. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20240611134327.30975-1-asmaa@nvidia.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: cpcap-charger: Convert comma to semicolonChen Ni
Replace a comma between expression statements by a semicolon. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://lore.kernel.org/r/20240710032023.2003742-1-nichen@iscas.ac.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: max77693: Expose input current limit and CC current propertiesArtur Weber
There are two charger current limit registers: - Fast charge current limit (which controls current going from the charger to the battery); - CHGIN input current limit (which controls current going into the charger through the cable). Add the necessary functions to retrieve the CHGIN input limit (from CHARGER regulator) and maximum fast charge current values, and expose them as power supply properties. Tested-by: Henrik Grimler <henrik@grimler.se> Signed-off-by: Artur Weber <aweber.kernel@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240816-max77693-charger-extcon-v4-3-050a0a9bfea0@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: max17042_battery: Fix SOC threshold calc w/ no current senseArtur Weber
Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for capacity when no rsns") made it so that capacity on systems without current sensing would be read from VFSOC instead of RepSOC. However, the SOC threshold calculation still read RepSOC to get the SOC regardless of the current sensing option state. Fix this by applying the same conditional to determine which register should be read. This also seems to be the intended behavior as per the datasheet - SOC alert config value in MiscCFG on setups without current sensing is set to a value of 0b11, indicating SOC alerts being generated based on VFSOC, instead of 0b00 which indicates SOC alerts being generated based on RepSOC. This fixes an issue on the Galaxy S3/Midas boards, where the alert interrupt would be constantly retriggered, causing high CPU usage on idle (around ~12%-15%). Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC") Signed-off-by: Artur Weber <aweber.kernel@gmail.com> Reviewed-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: axp20x_usb_power: add input-current-limit-microampChris Morgan
Allow users to specify a maximum input current for the device. Some devices allow up to 3.25A of input current (such as the AXP717), which may be too much for some implementations. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240821215456.962564-7-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: axp20x_usb_power: Make VBUS and IIO config per deviceChris Morgan
Make reading of the vbus value and configuring of the iio channels device specific, to allow additional devices (such as the AXP717) to be supported by this driver. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240821215456.962564-5-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: axp20x_battery: Make iio and battery config per deviceChris Morgan
Move the configuration of battery specific information and available iio channels from the probe function to a device specific routine, allowing us to use this driver for devices with slightly different configurations (such as the AXP717). Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240821215456.962564-4-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: axp20x_battery: Remove design from min and max voltageChris Morgan
The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable properties of the battery, but for this driver they are writable values and used as the minimum and maximum values for charging. Remove the DESIGN designation from these values. Fixes: 46c202b5f25f ("power: supply: add battery driver for AXP20X and AXP22X PMICs") Suggested-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240821215456.962564-3-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: twl4030_charger: correct comparision with old currentKrzysztof Kozlowski
Driver reads existing current value from two 8-bit registers, but then compares only one of them with the new 16-bit value. clang W=1 is also not happy: twl4030_charger.c:243:16: error: variable 'cur_reg' set but not used [-Werror,-Wunused-but-set-variable] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240705113113.42851-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: core: simplify with cleanup.hKrzysztof Kozlowski
Allocate the memory with scoped/cleanup.h to reduce error handling and make the code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240705113113.42851-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-08-27power: supply: max8998_charger: Fix module autoloadingJinjie Ruan
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from platform_device_id table. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20240819040831.2801543-1-ruanjinjie@huawei.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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: qcom-wcn: add support for the WCN6855 PMUKonrad Dybcio
Enable support for controlling the power-up sequence of the PMU inside the WCN6855 model. Signed-off-by: Konrad Dybcio <konradybcio@kernel.org> [Bartosz: split Konrad's bigger patch, write the commit message] Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240813190841.155067-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.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>
generated by cgit (git 2.34.1) at 2025-07-31 18:33:44 +0000