Pull power supply and reset updates from Sebastian Reichel:
"Power-supply core:
- introduce power supply extensions, which allows adding properties
to a power supply device from a separate driver. This will be used
initially to extend the generic ACPI charger/battery driver with
vendor extensions for charge thresholds.
- convert all drivers from power_supply_for_each_device to new
power_supply_for_each_psy(), which avoids lots of casting being
done in the drivers.
- avoid LED trigger like values in uevent for
POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR
- introduce POWER_SUPPLY_PROP_CHARGE_TYPES, which is similar to the
POWER_SUPPLY_PROP_CHARGE_TYPE property, but also lists the
available options on the specific platform
Power-supply drivers
- dell-laptop: use new power_supply_charge_types_show/_parse helpers
- stc3117: new driver for equally named fuel gauge chip
- bq24190: add support for new POWER_SUPPLY_PROP_CHARGE_TYPES
- bq24190: add BQ24297 support
- bq27xxx: add voltage min design for bq27000/bq27200
- cros_charge-control: convert to new power supply extension API
- multiple drivers: constify 'struct bin_attribute'
- ds2782: convert to device managed resources
- max1720x: add charge full property
- max1720x: support extra thermistor temperatures
- max17042: add max77705 support
- ip5xxx-power: add support for IP5306
- ltc4162-l-charger: add ltc4162-f/s and ltc4015 support
- gpio-charger: support for default charge current limit
- misc small cleanups and fixes
Reset drivers:
- at91-poweroff: add sam9x7 support"
* tag 'for-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (77 commits)
power: supply: max1720x: add support for reading internal and thermistor temperatures
power: supply: ltc4162l: Use GENMASK macro in bitmask operation
power: supply: max17042: add max77705 fuel gauge support
dt-bindings: power: supply: max17042: add max77705 support
power: supply: add undervoltage health status property
power: supply: max17042: add platform driver variant
power: supply: max17042: make interrupt shared
power: reset: keystone: Use syscon_regmap_lookup_by_phandle_args
power: supply: Use str_enable_disable-like helpers
platform/x86: dell-laptop: Use power_supply_charge_types_show/_parse() helpers
power: supply: bq2415x_charger: Immediately reschedule delayed work on notifier events
power: supply: Add STC3117 fuel gauge unit driver
dt-bindings: power: supply: Add STC3117 Fuel Gauge
power: supply: ug3105_battery: Let the core handle POWER_SUPPLY_PROP_TECHNOLOGY
power: supply: gpio-charger: add support for default charge current limit
dt-bindings: power: supply: gpio-charger: add support for default charge current limit
power: supply: Use power_supply_external_power_changed() in __power_supply_changed_work()
power: supply: core: fix build of extension sysfs group if CONFIG_SYSFS=n
power: supply: bq2415x_charger: report charging state changes to userspace
bq27xxx: add voltage min design for bq27000 and bq27200
...
Pull power sequencing updates from Bartosz Golaszewski:
"We added support for another Qualcomm WCN model and a FIXME comment
that explains why we still need to keep a GPIO workaround for now
despite having merged a set of changes to the PCI code that seemingly
fixed the underlying problem:
- support a new model in the qcom-wcn pwrseq driver
- explain the need to keep the WLAN_EN GPIO workaround for now with a
FIXME comment"
* tag 'pwrseq-updates-for-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: qcom-wcn: explain why we need the WLAN_EN GPIO hack
power: sequencing: qcom-wcn: add support for the WCN6750 PMU
Maxim PMICs may include fuel gauge with additional features, which is
out of single Linux power supply driver scope.
For example, in max77705 PMIC fuelgauge has additional registers, like
IIN_REG, VSYS_REG, ISYS_REG. Those needed to measure PMIC input current,
system voltage and current respectively. Those measurements cannot be
bound to any of fuelgauge properties.
The solution here add and option to use max17042 driver as a MFD sub
device, thus allowing any additional functionality be implemented as
another sub device. This will help to reduce code duplication in MFD
fuel gauge drivers.
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-2-3d0104ad5bc7@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
syscon_regmap_lookup_by_phandle() combined with getting the syscon
argument. Except simpler code this annotates within one line that given
phandle has arguments, so grepping for code would be easier.
There is also no real benefit in printing errors on missing syscon
argument, because this is done just too late: runtime check on
static/build-time data. Dtschema and Devicetree bindings offer the
static/build-time check for this already.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250111185358.183725-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250114203611.1013324-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
With the recent rework of the PCI power control code, the workaround for
the wlan-enable GPIO - where we don't set a default (low) state in the
power sequencing driver, but instead request the pin as-is - should no
longer be needed but some platforms still fail to probe the WLAN
controller. This is caused by the Qcom PCIe controller and needs a
workaround in the controller driver so add a FIXME to eventually remove
the hack from this driver once this is done.
Link: https://lore.kernel.org/r/20250102121530.26993-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
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>
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: b150a703b5 ("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>
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>
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>
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: c6ed48ef52 ("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>
