summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
2024-12-19power: reset: as3722-poweroff: Remove unnecessary return in ↵Nobuhiro Iwamatsu
as3722_poweroff_probe The return is executed on the devm_register_sys_off_handler() line in as3722_poweroff_probe, so the last return line is unnecessary. Remove it. Fixes: 348fde771ce7 ("power: reset: as3722-poweroff: Use devm_register_sys_off_handler(POWER_OFF)") Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241117053443.1148902-1-iwamatsu@nigauri.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq24190: Fix BQ24296 Vbus regulator supportHans de Goede
There are 2 issues with bq24296_set_otg_vbus(): 1. When writing the OTG_CONFIG bit it uses POC_CHG_CONFIG_SHIFT which should be POC_OTG_CONFIG_SHIFT. 2. When turning the regulator off it never turns charging back on. Note this must be done through bq24190_charger_set_charge_type(), to ensure that the charge_type property value of none/trickle/fast is honored. Resolve both issues to fix BQ24296 Vbus regulator support not working. Fixes: b150a703b56f ("power: supply: bq24190_charger: Add support for BQ24296") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241116203648.169100-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq24190: Add BQ24297 supportHans de Goede
The BQ24297 is identical to the BQ24296 except that it uses USB D+ / D- data-lines for charger-type (max. input-current) detection instead of a PSEL input pin. This is the same difference as between the already supported BQ24190 (D+ / D-) and the BQ24192 (PSEL). Note just like with the BQ24190 vs BQ24192 there is no difference how the charger-IC works at the register-level. The only difference is in the external hardware interface. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241116203648.169100-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: core: add UAPI to discover currently used extensionsThomas Weißschuh
Userspace wants to now about the used power supply extensions, for example to handle a device extended by a certain extension differently or to discover information about the extending device. Add a sysfs directory to the power supply device. This directory contains links which are named after the used extension and point to the device implementing that extension. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-4-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: cros_charge-control: implement a power supply extensionThomas Weißschuh
Power supply extensions provide an easier mechanism to implement additional properties for existing power supplies. Use that instead of reimplementing the sysfs attributes manually. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-3-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: Merge fixes branch into for-nextSebastian Reichel
Merge the fixes branch into the development branch, since the it contains multiple changes to the cros_charge-control driver needed to convert it to the new power-supply extension framework. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: test-power: implement a power supply extensionThomas Weißschuh
Allow easy testing of the new power supply extension functionality. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-2-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: core: implement extension APIThomas Weißschuh
Various drivers, mostly in platform/x86 extend the ACPI battery driver with additional sysfs attributes to implement more UAPIs than are exposed through ACPI by using various side-channels, like WMI, nonstandard ACPI or EC communication. While the created sysfs attributes look similar to the attributes provided by the powersupply core, there are various deficiencies: * They don't show up in uevent payload. * They can't be queried with the standard in-kernel APIs. * They don't work with triggers. * The extending driver has to reimplement all of the parsing, formatting and sysfs display logic. * Writing a extension driver is completely different from writing a normal power supply driver. This extension API avoids all of these issues. An extension is just a "struct power_supply_ext" with the same kind of callbacks as in a normal "struct power_supply_desc". The API is meant to be used via battery_hook_register(), the same way as the current extensions. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-1-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: ltc4162-l-charger: Add support for ltc4162-f/s and ltc4015Kim Seer Paller
LTC4162-L 35V/3.2A Multi-Cell Lithium-Ion Step-Down Battery Charger LTC4162-F 35V/3.2A Multi-Cell LiFePO4 Step-Down Battery Charger LTC4162-S 35V/3.2A Lead-Acid Step-Down Battery Charger LTC4015 35V/3.2A Multichemistry Buck Battery Charger Controller The LTC4162-L/F/S variants and LTC4015 share a common set of registers. The difference lies in the resolution value of the scaling factor for battery voltage and battery current measurement, input voltage, and input current for different battery chemistries. The difference also includes the calculation of setting and getting the actual voltage setting applied to the charge voltage, as well as getting the die temperature. Adding chip info structure to encapsulates these differences by defining function pointers and parameters specific to each device. This structure includes: - function pointers for getting and setting various parameters such as battery voltage, charge voltage, and die temperature - resolution parameters for battery current and input voltage - telemetry mask to specify which bits in the register are used for telemetry features Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com> Link: https://lore.kernel.org/r/20241213023746.34168-3-kimseer.paller@analog.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: bq24190_charger: Add support for "charge_types" propertyHans de Goede
The bq24190 power_supply class device has a writeable "charge_type" property, add support for the new "charge_types" property. Reading this returns a list of supported charge-types with the currently active type surrounded by square brackets, allowing userspace to find out which enum power_supply_charge_type values are supported. This has been tested on a GPD win gaming-handheld. Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241211174451.355421-4-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: core: Add new "charge_types" propertyHans de Goede
Add a new "charge_types" property, this is identical to "charge_type" but reading returns a list of supported charge-types with the currently active type surrounded by square brackets, e.g.: Fast [Standard] "Long_Life" This has the advantage over the existing "charge_type" property that this allows userspace to find out which charge-types are supported for writable charge_type properties. Drivers which already support "charge_type" can easily add support for this by setting power_supply_desc.charge_types to a bitmask representing valid charge_type values. The existing "charge_type" get_property() and set_property() code paths can be re-used for "charge_types". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211174451.355421-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-reset: add sdhwc support for sam9x7 SoCVarshini Rajendran
Add shutdown controller support for SAM9X7 SoC. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120414.92993-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-reset: add reset support for sam9x7 SoCVarshini Rajendran
Add power reset support for SAM9X7 SoC. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120410.92942-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-poweroff: lookup for proper pmc dt node for sam9x7Varshini Rajendran
Use sam9x7 pmc's compatible to lookup for in the SHDWC driver. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120404.92893-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-12power: reset: gpio-poweroff: Clarify the warning messageFabio Estevam
When gpio-poweroff fails, a WARN_ON() is triggered without an explanation to the user about the failure. Add some comments explaining that the attempt to poweroff the system via gpio-poweroff failed and convert it to a WARN() message with a bit of context to provide some hint to the user. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20241212130456.580197-1-festevam@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: power_supply_show_enum_with_available(): Replace spaces with '_'Hans de Goede
Some enum style power-supply properties have text-values / labels for some of the enum values containing a space, e.g. "Long Life" for POWER_SUPPLY_CHARGE_TYPE_LONGLIFE. Make power_supply_show_enum_with_available() replace these spaces with '_' when showing the available text-values. After this the output for a battery which supports "Long Life" will be e.g.: Fast [Standard] Long_Life or: Fast Standard [Long_Life] Modify power_supply_store_property() to accept both the original text-value with space and the alternative value with the spaces replaced by '_'. This allows users to write the value with '_' after seeing this on reading the property. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241209204051.8786-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: bq24257_charger: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-14-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: bq24190_charger: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-13-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: bq2415x_charger: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-12-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: surface_battery: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-11-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: ab8500: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-10-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: sysfs: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-9-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: core: use dev_to_psy()Thomas Weißschuh
Use the new, explicit accessor to go from a 'struct device' to its 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-8-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: core: remove power_supply_for_each_device()Thomas Weißschuh
There are no users anymore. All potential future users are expected to use power_supply_for_each_psy(). Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-6-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: apm_power: use power_supply_for_each_psy()Thomas Weißschuh
Simplify the callbacks by removing the need to convert a 'struct device' into a 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-5-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: ab8500: use power_supply_for_each_psy()Thomas Weißschuh
Simplify the callbacks by removing the need to convert a 'struct device' into a 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-4-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: core: use power_supply_for_each_psy()Thomas Weißschuh
Simplify the callbacks by removing the need to convert a 'struct device' into a 'struct power_supply'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-3-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: core: introduce power_supply_for_each_psy()Thomas Weißschuh
All existing callers of power_supply_for_each_device() want to iterate over 'struct power_supply', not 'struct device'. The power_supply_for_each_device() forces each caller to duplicate the logic to go from one to the other. Introduce power_supply_for_each_psy() to simplify the callers. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-2-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-11power: supply: mm8013: use accessor for driver dataThomas Weißschuh
Instead of directly accessing the structure member, use the accessor. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-1-9d8c9d24cfe4@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-10power: sequencing: qcom-wcn: add support for the WCN6750 PMUJanaki Ramaiah Thota
Enable support for controlling the power-up sequence of the PMU inside the WCN6750 model. Signed-off-by: Janaki Ramaiah Thota <quic_janathot@quicinc.com> Link: https://lore.kernel.org/r/20241209103455.9675-5-quic_janathot@quicinc.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-12-10power: supply: cros_charge-control: hide start threshold on v2 cmdThomas Weißschuh
ECs implementing the v2 command will not stop charging when the end threshold is reached. Instead they will begin discharging until the start threshold is reached, leading to permanent charge and discharge cycles. This defeats the point of the charge control mechanism. Avoid the issue by hiding the start threshold on v2 systems. Instead on those systems program the EC with start == end which forces the EC to reach and stay at that level. v1 does not support thresholds and v3 works correctly, at least judging from the code. Reported-by: Thomas Koch <linrunner@gmx.net> Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-3-8d168d0f08a3@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-10power: supply: cros_charge-control: allow start_threshold == end_thresholdThomas Weißschuh
Allow setting the start and stop thresholds to the same value. There is no reason to disallow it. Suggested-by: Thomas Koch <linrunner@gmx.net> Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-2-8d168d0f08a3@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-10power: supply: cros_charge-control: add mutex for driver dataThomas Weißschuh
Concurrent accesses through sysfs may lead to inconsistent state in the priv data. Introduce a mutex to avoid this. Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-1-8d168d0f08a3@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-10power: supply: gpio-charger: Fix set charge current limitsDimitri Fedrau
Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature") Cc: stable@vger.kernel.org Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-10power: ip5xxx_power: Fix uninitialized variable readBence Csókás
The check for whether a charger supports the requested battery voltage was incorrectly added to the `ip5xxx_battery_get_voltage_max()` function, instead of `set_voltage_max()`. This commit fixes it. Reported-by: Kees Bakker <kees@ijzerbout.nl> Closes: https://lore.kernel.org/linux-kernel/b547c228-df70-4137-9e96-175923f62404@ijzerbout.nl/ Fixes: 8584bc5df539 ("power: ip5xxx_power: Allow for more parameters to be configured") Signed-off-by: Bence Csókás <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241208131532.1028581-1-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-06power: supply: bq24190_charger: Fix typo 'jeta' -> 'jeita'Sho Tanimoto
The sysfs file 'jeta_iset' was probably intended for 'jeita_iset' Signed-off-by: Sho Tanimoto <mojyack@gmail.com> Link: https://lore.kernel.org/r/20241205084601.2720462-1-mojyack@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Add support for IP5306Csókás, Bence
Add ip5xxx_regfield_config for IP5306 Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-8-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Fall back to Charge End bit if status register is absentCsókás, Bence
On parts where there is no status register, check the Charge End bit to set charging/not charging status. Fullness, trickle charge status, discharging etc. cannot be determined from just this bit. Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-6-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Check for optional bitsCsókás, Bence
Some parts may not have certain control bits. These bits however may be non-essential to the system's operation, as the default behaviour is the one we would set anyways, or the bits are not applicable for said part (e. g. enabling NTC on a part without an NTC pin, or one where it cannot be disabled via registers anyways). Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-5-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Add battery type for 4.4VCsókás, Bence
IP53xx series supports 4.4V batteries. Add support for it to compatible parts (that have `vbat_max` set to >= 4.4 V). Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-4-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Allow for more parameters to be configuredCsókás, Bence
Other parts such as IP5306 may support other battery voltages and have different constants for input voltage regulation. Allow these to be passed from `struct ip5xxx_regfield_config`. Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-3-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Use regmap_field APICsókás, Bence
The IP53xx series [1] has a much different register layout than the 51xx/52xx [2] currently supported by this driver. To accommodate supporting the former, refactor the code to use the flexible regmap_field API. [1] https://sharvielectronics.com/wp-content/uploads/2021/07/IP5306-I2C-registers.pdf [2] https://www.windworkshop.cn/wp-content/uploads/2022/04/IP5209-IP5109-IP5207-IP5108-I2C-registers.pdf Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-1-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: ip5xxx_power: Fix return value on ADC read errorsCsókás, Bence
If ADC read returns an error, the return value was silently ignored, execution continued and an uninitialized value and a return code of 0 was passed back to userspace. The only exception was POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT, which bailed out correctly. Fix returns for the other cases as well. Fixes: 75853406fa27 ("power: supply: Add a driver for Injoinic power bank ICs") Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20241119180741.2237692-2-csokas.bence@prolan.hu Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: sysfs: rework uevent property loopThomas Weißschuh
Instead of looping through all properties known to be supported by the psy, loop over all known properties and decide based on the return value of power_supply_get_property() whether the property existed. This makes the code shorter now and even more so when power supply extensions are added. It also simplifies the locking, as it can all happen inside power_supply_get_property(). Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-6-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: sysfs: prepare for power supply extensionsThomas Weißschuh
The upcoming extension API will add properties which are not part of the the power_supply_desc. Use power_supply_has_property() so the properties from extensions are also checked. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-5-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: hwmon: prepare for power supply extensionsThomas Weißschuh
The upcoming extension API will add properties which are not part of the the power_supply_desc. Use power_supply_has_property() so the properties from extensions are also checked. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-4-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: core: introduce power_supply_has_property()Thomas Weißschuh
Introduce a helper to check if a power supply implements a certain property. It will be used by the sysfs and hwmon code to remove similar open-coded checks. It also paves the way for the extension API to hook into. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-3-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: core: rename psy_has_property() to psy_desc_has_property()Thomas Weißschuh
The function only takes a desc as parameter, align the naming. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-2-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-05power: supply: sysfs: print single value in uevent for ↵Thomas Weißschuh
POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR Currently an uevent contains the same string representation of a property as sysfs. However for POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR this is specially formatted to indicate all possible values. This doesn't make sense for uevents and complicates parsing. Instead only include the currently active value in uevents. As currently no in-tree driver uses POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR this change is not a problem. Soon the property will actually be used so fix the formatting before that happens. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-1-7240144daa8e@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-04power: supply: max1720x: add charge full propertyDimitri Fedrau
Charge full holds the calculated full capacity of the cell based on all inputs from the ModelGauge m5 algorithm including empty compensation. A new full-capacity value is calculated continuously as application conditions change. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20241203-max1720x-charge-full-prop-v1-1-b02776b43f17@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
generated by cgit (git 2.34.1) at 2025-07-31 09:05:27 +0000