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>
Add LTC4162-F/S and LTC4015 to the supported devices of LTC4162-L.
They share a common set of registers. The only differences lie 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 differences also include the calculation of
setting and getting the actual voltage applied to the charge voltage,
as well as getting the die temperature.
This add compatible entries for ltc4162-f/s and ltc4015 and include
datasheets for new devices.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://lore.kernel.org/r/20241213023746.34168-2-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>
The psy core and drivers currently use dev_get_drvdata() to go from a
'struct device' to its 'struct power_supply'.
This is not typesafe and or documented.
Introduce a new helper to make this pattern explicit.
Instead of using dev_get_drvdata(), use container_of_const() which
also preserves the constness.
Furthermore 'dev' does need to be dereferenced anymore and at some point
the drvdata could be reused for something else.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20241210-power-supply-dev_to_psy-v2-7-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: 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>
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>
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: 75853406fa ("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>
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>
Use the device lifecycle managed work init function. This helps prevent
mistakes like canceling out of order in cleanup functions and
forgetting to canceling on error paths.
Note we move this to after the registering the power supply so that
the cancel is called before unregistering.
This was the last thing the .remove() function did, so remove that too.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20241202211519.199635-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
