summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-15dt-bindings: power: supply: max17042: add max77705 supportDzmitry Sankouski
Add max77705 fuel gauge support. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-2-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: add undervoltage health status propertyDzmitry Sankouski
Add POWER_SUPPLY_HEALTH_UNDERVOLTAGE status for power supply to report under voltage lockout failures. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-1-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: max17042: add platform driver variantDzmitry Sankouski
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>
2025-01-15power: supply: max17042: make interrupt sharedDzmitry Sankouski
Fuelgauge blocks often are incorporated in bigger chip, which may use only 1 line for interrupts. Make interrupt shared. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-1-3d0104ad5bc7@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: reset: keystone: Use syscon_regmap_lookup_by_phandle_argsKrzysztof Kozlowski
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>
2025-01-15power: supply: Use str_enable_disable-like helpersKrzysztof Kozlowski
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>
2025-01-03platform/x86: dell-laptop: Use power_supply_charge_types_show/_parse() helpersHans de Goede
Make battery_modes a map between tokens and enum power_supply_charge_type values instead of between tokens and strings and use the new power_supply_charge_types_show/_parse() helpers for show()/store() to ensure that things are handled in the same way as in other drivers. This also changes battery_supported_modes to be a bitmap of charge-types (enum power_supply_charge_type values) rather then a bitmap of indices into battery_modes[]. Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20241221125140.345776-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-23power: supply: bq2415x_charger: Immediately reschedule delayed work on ↵Sicelo A. Mhlongo
notifier events When the notifier is called we want to schedule the worker as soon as possible. Thus it makes sense to reschedule any waiting work and only queue a new one if there is none. Suggested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20241221161124.114989-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-21power: supply: Add STC3117 fuel gauge unit driverBhavin Sharma
Adds initial support for the STC3117 fuel gauge. The driver provides functionality to monitor key parameters including: Voltage, Current, State of Charge (SOC), Temperature, Status Co-developed-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> Signed-off-by: Bhavin Sharma <bhavin.sharma@siliconsignals.io> Link: https://lore.kernel.org/r/20241220084958.32367-3-bhavin.sharma@siliconsignals.io Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-21dt-bindings: power: supply: Add STC3117 Fuel GaugeHardevsinh Palaniya
The STC3117 provides a simple fuel gauge via I2C. Add a DT schema to describe how to set it up in the device tree. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> Signed-off-by: Bhavin Sharma <bhavin.sharma@siliconsignals.io> Link: https://lore.kernel.org/r/20241220084958.32367-2-bhavin.sharma@siliconsignals.io Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: ug3105_battery: Let the core handle POWER_SUPPLY_PROP_TECHNOLOGYHans de Goede
The power-supply core already takes care of handling POWER_SUPPLY_PROP_TECHNOLOGY based on the battery_info. Drop the unnecessary handling from the driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241215172133.178460-4-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: gpio-charger: add support for default charge current limitDimitri Fedrau
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>
2024-12-20dt-bindings: power: supply: gpio-charger: add support for default charge ↵Dimitri Fedrau
current limit 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. Add property charge-current-limit-default-microamp which selects a default charge current limit that must be listed in charge-current-limit-mapping. This is helpful when the smallest possible charge current limit is 0uA. The driver defaults to the smallest possible value at the moment, which disables charging on probe. With the default its possible to setup a safe charge current limit. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20241218-default-charge-current-limit-v3-1-b26118cf06b5@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: Use power_supply_external_power_changed() in ↵Hans de Goede
__power_supply_changed_work() 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>
2024-12-19power: supply: core: fix build of extension sysfs group if CONFIG_SYSFS=nThomas Weißschuh
Add and use wrapper functions for the sysfs interaction. Restore the compatibility of CONFIG_POWER_SUPPLY=y and CONFIG_SYSFS=n. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/lkml/20241218195229.GA2796534@ax162/ Fixes: 288a2cabcf6b ("power: supply: core: add UAPI to discover currently used extensions") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241219-psy-extensions-sysfs-v1-1-868fc6cb46d6@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq2415x_charger: report charging state changes to userspaceSicelo A. Mhlongo
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>
2024-12-19bq27xxx: add voltage min design for bq27000 and bq27200Sicelo A. Mhlongo
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>
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: 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-19dt-bindings: power: supply: bq24190: Add BQ24297 compatibleHans 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). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20241116203648.169100-1-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-13dt-bindings: power: supply: ltc4162-l-charger: Add ltc4162-f/s and ltc4015Kim Seer Paller
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>
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-13dt-bindings: power: reset: atmel,sama5d2-shdwc: add sam9x7Varshini Rajendran
Add shutdown controller DT bindings. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241010120425.93102-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: introduce dev_to_psy()Thomas Weißschuh
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>
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: 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>