With DT properties charge-current-limit-gpios and
charge-current-limit-mapping one can define charge current limits in uA
using up to 32 GPIOs. At the moment the driver defaults to smallest charge
current limitation for safety reasons. When disabling charging is
supported, which should be common, the driver defaults to non charging on
probe. By having a default, charging can be enabled on probe for such
devices.
Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
Link: https://lore.kernel.org/r/20241218-default-charge-current-limit-v3-2-b26118cf06b5@liebherr.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The power-supply core is designed so that power-supply driver callbacks
such as get_property() and external_power_changed() will not be called
until the power-supply's parent driver's probe() function has completed.
There is a race where power_supply_changed() can be called for a supplier
of a power-supply which is being probed after the device_add() in
__power_supply_register() but before the parent driver's probe() function
has completed. Hitting this race breaks the power-supply core's design
to not call power-supply driver callbacks before probe() completion.
This problem is caused by __power_supply_changed_work() calling
the external_power_changed() directly rather then going through
the power_supply_external_power_changed() helper which correcly checks
psy->use_cnt .
Switch to using power_supply_external_power_changed() to fix this race.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241215172133.178460-2-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Continuously track the charging status register in order to send uevents
whenever the state changes. Generate an uevent also when the chip's OTG
line is toggled, in bq2415x_notifier_call().
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Link: https://lore.kernel.org/r/20241128085759.11840-2-absicsz@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The bq27x00 gauges have an EEPROM register which contains the value of
the voltage that should be considered to be zero battery capacity. Expose
this to userspace using the VOLTAGE_MIN_DESIGN property.
Tested on Nokia N900 with bq27200.
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20241125151321.45440-1-absicsz@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
