summaryrefslogtreecommitdiff
path: root/include/linux/power_supply.h
AgeCommit message (Collapse)Author
4 daysMerge tag 'for-v6.17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Power-supply core: - battery-info: replace any DT specific bits with fwnode usage - replace any device-tree code with generic fwnode based handling Power-supply drivers: - ug3105_battery: use battery-info API - qcom_battmgr: report capacity - qcom_battmgr: support LiPo battery reporting - add missing missing power-supply ref to a bunch of DT bindings - update drivers regarding pm_runtime_autosuspend() usage - misc minor fixes and cleanups Reset drivers: - misc minor cleanups" * tag 'for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (32 commits) power: supply: core: fix static checker warning power: supply: twl4030_charger: Remove redundant pm_runtime_mark_last_busy() calls power: supply: bq24190: Remove redundant pm_runtime_mark_last_busy() calls MAINTAINERS: rectify file entry in QUALCOMM SMB CHARGER DRIVER power: supply: max1720x correct capacity computation MAINTAINERS: add myself as smbx charger driver maintainer power: supply: pmi8998_charger: rename to qcom_smbx power: supply: qcom_pmi8998_charger: fix wakeirq power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set power: return the correct error code power: reset: POWER_RESET_TORADEX_EC should depend on ARCH_MXC power: supply: cpcap-charger: Fix null check for power_supply_get_by_name power: supply: bq25980_charger: Constify reg_default array power: supply: bq256xx_charger: Constify reg_default array power: reset: at91-sama5d2_shdwc: Refactor wake-up source logging to use dev_info power: reset: qcom-pon: Rename variables to use generic naming power: supply: qcom_battmgr: Add lithium-polymer entry power: supply: qcom_battmgr: Report battery capacity power: supply: bq24190: Free battery_info power: supply: ug3105_battery: Switch to power_supply_batinfo_ocv2cap() ...
2025-07-07power: supply: core: Add power_supply_get/set_property_direct()Armin Wolf
Power supply extensions might want to interact with the underlying power supply to retrieve data like serial numbers, charging status and more. However doing so causes psy->extensions_sem to be locked twice, possibly causing a deadlock. Provide special variants of power_supply_get/set_property() that ignore any power supply extensions and thus do not touch the associated psy->extensions_sem lock. Suggested-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250627205124.250433-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-22power: supply: core: rename power_supply_get_by_phandle to ↵Sebastian Reichel
power_supply_get_by_reference (devm_)power_supply_get_by_phandle now internally uses fwnode and are no longer DT specific. Thus drop the ifdef check for CONFIG_OF and rename to (devm_)power_supply_get_by_reference to avoid the DT terminology. Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250430-psy-core-convert-to-fwnode-v2-5-f9643b958677@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-06-22power: supply: core: convert to fwnnodeSebastian Reichel
Replace any DT specific code with fwnode in the power-supply core. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250430-psy-core-convert-to-fwnode-v2-4-f9643b958677@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-06-22power: supply: core: remove of_node from power_supply_configSebastian Reichel
All drivers have been migrated from .of_node to .fwnode, so let's kill the former. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250430-psy-core-convert-to-fwnode-v2-2-f9643b958677@collabora.com Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-05-29Merge tag 'platform-drivers-x86-v6.16-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform drivers updates from Ilpo Järvinen: "The changes are mostly business as usual. Besides pdx86 changes, there are a few power supply changes needed for related pdx86 features, move of oxpec driver from hwmon (oxp-sensors) to pdx86, and one FW version warning to hid-asus. Highlights: - alienware-wmi-wmax: - Add HWMON support - Add ABI and admin-guide documentation - Expose GPIO debug methods through debug FS - Support manual fan control and "custom" thermal profile - amd/hsmp: - Add sysfs files to show HSMP telemetry - Report power readings and limits via hwmon - amd/isp4: Add AMD ISP platform config for OV05C10 - asus-wmi: - Refactor Ally suspend/resume to work better with older FW - hid-asus: check ROG Ally MCU version and warn about old FW versions - dasharo-acpi: - Add driver for Dasharo devices supporting fans and temperatures monitoring - dell-ddv: - Expose the battery health and manufacture date to userspace using power supply extensions - Implement the battery matching algorithm - dell-pc: - Improve error propagation - Use faux device - int3472: - Add delays to avoid GPIO regulator spikes - Add handshake pin support - Make regulator supply name configurable and allow registering more than 1 GPIO regulator - Map mt9m114 powerdown pin to powerenable - intel/pmc: Add separate SSRAM Telemetry driver - intel-uncore-freq: Add attributes to show agent types and die ID - ISST: - Support SST-TF revision 2 (allows more cores per bucket) - Support SST-PP revision 2 (fabric 1 frequencies) - Remove unnecessary SST MSRs restore (the package retains MSRs despite CPU offlining) - mellanox: Add support for SN2201, SN4280, SN5610, and SN5640 - mellanox: mlxbf-pmc: Support additional PMC blocks - oxpec: - Add OneXFly variants - Add support for charge limit, charge thresholds, and turbo LED - Distinguish current X1 variants to avoid unwanted matching to new variants - Follow hwmon conventions - Move from hwmon/oxp-sensors to platform/x86 to match the enlarged scope - power supply: - Add inhibit-charge-awake (needed by oxpec) - Add additional battery health status values ("blown fuse" and "cell imbalance") (needed by dell-ddv) - powerwell-ec: Add driver for Portwell EC supporting GPIO and watchdog - thinkpad-acpi: Support camera shutter switch hotkey - tuxedo: Add virtual LampArray for TUXEDO NB04 devices - tools/power/x86/intel-speed-select: - Support displaying SST-PP revision 2 fields - Skip uncore frequency update on newer generations of CPUs - Miscellaneous cleanups / refactoring / improvements" * tag 'platform-drivers-x86-v6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (112 commits) thermal/drivers/acerhdf: Constify struct thermal_zone_device_ops platform/x86/amd/hsmp: fix building with CONFIG_HWMON=m platform/x86: asus-wmi: fix build without CONFIG_SUSPEND docs: ABI: Fix "aassociated" to "associated" platform/x86: Add AMD ISP platform config for OV05C10 Documentation: admin-guide: pm: Add documentation for die_id platform/x86/intel-uncore-freq: Add attributes to show die_id platform/x86/intel: power-domains: Add interface to get Linux die ID Documentation: admin-guide: pm: Add documentation for agent_types platform/x86/intel-uncore-freq: Add attributes to show agent types platform/x86/tuxedo: Prevent invalid Kconfig state platform/x86: dell-ddv: Expose the battery health to userspace platform/x86: dell-ddv: Expose the battery manufacture date to userspace platform/x86: dell-ddv: Implement the battery matching algorithm power: supply: core: Add additional health status values platform/x86/amd/hsmp: acpi: Add sysfs files to display HSMP telemetry platform/x86/amd/hsmp: Report power via hwmon sensors platform/x86/amd/hsmp: Use a single DRIVER_VERSION for all hsmp modules platform/mellanox: mlxreg-dpu: Fix smatch warnings platform: mellanox: nvsw-sn2200: Fix .items in nvsw_sn2201_busbar_hotplug ...
2025-05-12power: supply: core: Add additional health status valuesArmin Wolf
Some batteries can signal when an internal fuse was blown. In such a case POWER_SUPPLY_HEALTH_DEAD is too vague for userspace applications to perform meaningful diagnostics. Additionally some batteries can also signal when some of their internal cells are imbalanced. In such a case returning POWER_SUPPLY_HEALTH_UNSPEC_FAILURE is again too vague for userspace applications to perform meaningful diagnostics. Add new health status values for both cases. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250429003606.303870-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-30power: supply: add inhibit-charge-awake to charge_behaviourAntheas Kapenekakis
OneXPlayer devices have a charge inhibit feature that allows the user to select between it being active always or only when the device is on. Therefore, add attribute inhibit-charge-awake to charge_behaviour to allow the user to select that charge should be paused only when the device is awake. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://lore.kernel.org/r/20250425111821.88746-14-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-04-29power: supply: support charge_types in extensionsJelle van der Waa
Similar to charge_behaviour, charge_types is an enum option where reading the property shows the supported values, with the active value surrounded by brackets. To be able to use it with a power_supply extension a bitmask with the supported charge_Types values has to be added to power_supply_ext. Signed-off-by: Jelle van der Waa <jvanderwaa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20250414131840.382756-2-jvanderwaa@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: core: get rid of of_nodeSebastian Reichel
This removes .of_node from 'struct power_supply', since there is already a copy in .dev.of_node and there is no need to have two copies. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250225-psy-core-convert-to-fwnode-v1-1-d5e4369936bb@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: Remove unused set_charged methodDr. David Alan Gilbert
The previous patches in this series removed the only caller and only setter of this method. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-4-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: core: Remove unused power_supply_set_battery_chargedDr. David Alan Gilbert
power_supply_set_battery_charged() has been unused since 2019's commit 0f884f8a090e ("ARM: pxa: remove raumfeld board files and defconfig") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-2-linux@treblig.org 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>
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: 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: 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-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: 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-10-17power: supply: hwmon: move interface to private headerThomas Weißschuh
The interface of power_supply_hwmon.c is only meant to be used by the psy core. Remove it from the public header file and use the private one instead. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241017-power-supply-cleanups-v2-1-cb0f5deab088@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-10-16power: supply: core: unexport power_supply_property_is_writeable()Thomas Weißschuh
Since commit ("power: supply: Drop use_cnt check from power_supply_property_is_writeable()"), this function does not check use_cnt anymore, making it unsuitable for general usage. As it is only used by the psy core anyways, remove it from the public header and unexport it to avoid misusage. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241005-power-supply-cleanups-v1-2-45303b2d0a4d@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-10-15power: supply: core: remove {,devm_}power_supply_register_no_ws()Thomas Weißschuh
The same functionality is available through power_supply_config::no_wakeup_source, which is more idiomatic. All users of the old API have been converted. Also remove the argument "ws" from __power_supply_register(), as it is now always "true". Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20241005-power-supply-no-wakeup-source-v1-8-1d62bf9bcb1d@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-10-15power: supply: core: add wakeup source inhibit by power_supply_configThomas Weißschuh
To inhibit wakeup users currently have to use dedicated functions to register the power supply: {,devm_}power_supply_register_no_ws(). This is inconsistent to other runtime settings which can be configured through struct power_supply_config. It's also not obvious what _no_ws() is meant to mean. Extend power_supply_config to also be able to inhibit the wakeup source. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20241005-power-supply-no-wakeup-source-v1-1-1d62bf9bcb1d@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-10-15power: supply: core: constify power_supply_battery_info::ocv_tableThomas Weißschuh
The power supply core never modifies the ocv table. Reflect this in the API, so drivers can mark their static tables as const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241005-power-supply-battery-const-v1-5-c1f721927048@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-10-15power: supply: core: constify power_supply_battery_info::resist_tableThomas Weißschuh
The power supply core never modifies the resist table. Reflect this in the API, so drivers can mark their static tables as const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241005-power-supply-battery-const-v1-1-c1f721927048@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-09-03power: supply: Change usb_types from an array into a bitmaskHans de Goede
The bit_types array just hold a list of valid enum power_supply_usb_type values which map to 0 - 9. This can easily be represented as a bitmap. This reduces the size of struct power_supply_desc and further reduces the data section size by drivers no longer needing to store the array. This also unifies how usb_types are handled with charge_behaviours, which allows power_supply_show_usb_type() to be removed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240831142039.28830-7-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: samsung-sdi-battery: Constify struct ↵Christophe JAILLET
power_supply_maintenance_charge_table 'struct power_supply_maintenance_charge_table' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, some code also needs to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o After: ===== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4087 4552 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/6caafd0ac2556a40405273b1a4badc508ea8e9b0.1719125040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-26power: supply: samsung-sdi-battery: Constify struct power_supply_vbat_ri_tableChristophe JAILLET
'struct power_supply_vbat_ri_table' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increase overall security. In order to do it, some code also needs to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 955 7664 0 8619 21ab drivers/power/supply/samsung-sdi-battery.o After: ===== $ size drivers/power/supply/samsung-sdi-battery.o text data bss dec hex filename 4055 4584 0 8639 21bf drivers/power/supply/samsung-sdi-battery.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/d01818abd880bf435d1106a9a6cc11a7a8a3e661.1719125040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: leds: Share trig pointer for online and charging_fullHans de Goede
Either 5 different LED triggers are registered for battery power-supply devices or a single online LED trigger is used for non battery power-supply devices. These 5 / 1 LED trigger(s) are never used at the same time. So there is no need for a separate LED trigger pointer for the online trigger. Rename the first battery trigger from charging_full_trig to just trig and use this for the online trigger too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531134702.166145-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-06-03power: supply: leds: Add power_supply_[un]register_led_trigger()Hans de Goede
Add power_supply_[un]register_led_trigger() helper functions. The primary goal of this is as a preparation patch for adding an activate callback to the power-supply LED triggers to ensure that power-supply LEDs get the correct initial value when the LED gets registered after the power_supply has been registered (this will use the psy back pointer). There also is quite a lot of code duplication in the existing LED trigger registration in the form of the kasprintf() for the name-template for each trigger + related error handling. This duplication is removed by these new helpers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531134702.166145-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-05-31power: supply: power-supply-leds: Add charging_orange_full_green trigger for ↵Kate Hsuan
RGB LED Add a charging_orange_full_green LED trigger and the trigger is based on led_mc_trigger_event() which can set an RGB LED when the trigger is triggered. The LED will show orange when the battery status is charging. The LED will show green when the battery status is full. Link: https://lore.kernel.org/linux-leds/f40a0b1a-ceac-e269-c2dd-0158c5b4a1ad@gmail.com/ Signed-off-by: Kate Hsuan <hpa@redhat.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> [hdegoede@redhat.com change color order to RGB] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-7-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-06power: supply: core: fix charge_behaviour formattingThomas Weißschuh
This property is documented to have a special format which exposes all available behaviours and the currently active one at the same time. For this special format some helpers are provided. When the charge_behaviour property was added in 1b0b6cc8030d ("power: supply: add charge_behaviour attributes"), it did not update the default logic in in power_supply_sysfs.c to use the format helpers. Thus by default only the currently active behaviour is printed. This fixes the default logic to follow the documented format. There is currently only one in-tree drivers exposing charge behaviours - thinkpad_acpi, which is not affected by the change, as it directly uses the helpers and does not use the power_supply_sysfs.c logic. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240303-power_supply-charge_behaviour_prop-v2-3-8ebb0a7c2409@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-03-06power: supply: core: add power_supply_for_each_device()Sebastian Reichel
Introduce power_supply_for_each_device(), which is a wrapper for class_for_each_device() using the power_supply_class and going through all devices. This allows making the power_supply_class itself a local variable, so that drivers cannot mess with it and simplifies the code slightly. Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240301-psy-class-cleanup-v1-1-aebe8c4b6b08@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-03-01power: supply: core: make power_supply_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the power_supply_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240301-class_cleanup-power-v1-1-97e0b7bf9c94@marliere.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-09-17power: supply: core: Don't export power_supply_notifierSebastian Reichel
power_supply_notifier can be internal, since all users are going through power_supply_reg_notifier()/power_supply_unreg_notifier(). Link: https://lore.kernel.org/r/20230913133900.591637-1-sebastian.reichel@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-09-13power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaintKai-Heng Feng
AMD PMF driver can cause the following warning: [ 196.159546] ------------[ cut here ]------------ [ 196.159556] Voluntary context switch within RCU read-side critical section! [ 196.159571] WARNING: CPU: 0 PID: 9 at kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x43d/0x560 [ 196.159604] Modules linked in: nvme_fabrics ccm rfcomm snd_hda_scodec_cs35l41_spi cmac algif_hash algif_skcipher af_alg bnep joydev btusb btrtl uvcvideo btintel btbcm videobuf2_vmalloc intel_rapl_msr btmtk videobuf2_memops uvc videobuf2_v4l2 intel_rapl_common binfmt_misc hid_sensor_als snd_sof_amd_vangogh hid_sensor_trigger bluetooth industrialio_triggered_buffer videodev snd_sof_amd_rembrandt hid_sensor_iio_common amdgpu ecdh_generic kfifo_buf videobuf2_common hp_wmi kvm_amd sparse_keymap snd_sof_amd_renoir wmi_bmof industrialio ecc mc nls_iso8859_1 kvm snd_sof_amd_acp irqbypass snd_sof_xtensa_dsp crct10dif_pclmul crc32_pclmul mt7921e snd_sof_pci snd_ctl_led polyval_clmulni mt7921_common polyval_generic snd_sof ghash_clmulni_intel mt792x_lib mt76_connac_lib sha512_ssse3 snd_sof_utils aesni_intel snd_hda_codec_realtek crypto_simd mt76 snd_hda_codec_generic cryptd snd_soc_core snd_hda_codec_hdmi rapl ledtrig_audio input_leds snd_compress i2c_algo_bit drm_ttm_helper mac80211 snd_pci_ps hid_multitouch ttm drm_exec [ 196.159970] drm_suballoc_helper snd_rpl_pci_acp6x amdxcp drm_buddy snd_hda_intel snd_acp_pci snd_hda_scodec_cs35l41_i2c serio_raw gpu_sched snd_hda_scodec_cs35l41 snd_acp_legacy_common snd_intel_dspcfg snd_hda_cs_dsp_ctls snd_hda_codec libarc4 drm_display_helper snd_pci_acp6x cs_dsp snd_hwdep snd_soc_cs35l41_lib video k10temp snd_pci_acp5x thunderbolt snd_hda_core drm_kms_helper cfg80211 snd_seq snd_rn_pci_acp3x snd_pcm snd_acp_config cec snd_soc_acpi snd_seq_device rc_core ccp snd_pci_acp3x snd_timer snd soundcore wmi amd_pmf platform_profile amd_pmc mac_hid serial_multi_instantiate wireless_hotkey hid_sensor_hub sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log cdc_ether usbnet r8152 mii hid_generic nvme i2c_hid_acpi i2c_hid nvme_core i2c_piix4 xhci_pci amd_sfh drm xhci_pci_renesas nvme_common hid [ 196.160382] CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.6.0-rc1 #4 [ 196.160397] Hardware name: HP HP EliteBook 845 14 inch G10 Notebook PC/8B6E, BIOS V82 Ver. 01.02.00 08/24/2023 [ 196.160405] Workqueue: events power_supply_changed_work [ 196.160426] RIP: 0010:rcu_note_context_switch+0x43d/0x560 [ 196.160440] Code: 00 48 89 be 40 08 00 00 48 89 86 48 08 00 00 48 89 10 e9 63 fe ff ff 48 c7 c7 10 e7 b0 9e c6 05 e8 d8 20 02 01 e8 13 0f f3 ff <0f> 0b e9 27 fc ff ff a9 ff ff ff 7f 0f 84 cf fc ff ff 65 48 8b 3c [ 196.160450] RSP: 0018:ffffc900001878f0 EFLAGS: 00010046 [ 196.160462] RAX: 0000000000000000 RBX: ffff88885e834040 RCX: 0000000000000000 [ 196.160470] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 196.160476] RBP: ffffc90000187910 R08: 0000000000000000 R09: 0000000000000000 [ 196.160482] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 196.160488] R13: 0000000000000000 R14: ffff888100990000 R15: ffff888100990000 [ 196.160495] FS: 0000000000000000(0000) GS:ffff88885e800000(0000) knlGS:0000000000000000 [ 196.160504] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 196.160512] CR2: 000055cb053c8246 CR3: 000000013443a000 CR4: 0000000000750ef0 [ 196.160520] PKRU: 55555554 [ 196.160526] Call Trace: [ 196.160532] <TASK> [ 196.160548] ? show_regs+0x72/0x90 [ 196.160570] ? rcu_note_context_switch+0x43d/0x560 [ 196.160580] ? __warn+0x8d/0x160 [ 196.160600] ? rcu_note_context_switch+0x43d/0x560 [ 196.160613] ? report_bug+0x1bb/0x1d0 [ 196.160637] ? handle_bug+0x46/0x90 [ 196.160658] ? exc_invalid_op+0x19/0x80 [ 196.160675] ? asm_exc_invalid_op+0x1b/0x20 [ 196.160709] ? rcu_note_context_switch+0x43d/0x560 [ 196.160727] __schedule+0xb9/0x15f0 [ 196.160746] ? srso_alias_return_thunk+0x5/0x7f [ 196.160765] ? srso_alias_return_thunk+0x5/0x7f [ 196.160778] ? acpi_ns_search_one_scope+0xbe/0x270 [ 196.160806] schedule+0x68/0x110 [ 196.160820] schedule_timeout+0x151/0x160 [ 196.160829] ? srso_alias_return_thunk+0x5/0x7f [ 196.160842] ? srso_alias_return_thunk+0x5/0x7f [ 196.160855] ? acpi_ns_lookup+0x3c5/0xa90 [ 196.160878] __down_common+0xff/0x220 [ 196.160905] __down_timeout+0x16/0x30 [ 196.160920] down_timeout+0x64/0x70 [ 196.160938] acpi_os_wait_semaphore+0x85/0x200 [ 196.160959] acpi_ut_acquire_mutex+0x9e/0x280 [ 196.160979] acpi_ex_enter_interpreter+0x2d/0xb0 [ 196.160992] acpi_ns_evaluate+0x2f0/0x5f0 [ 196.161005] acpi_evaluate_object+0x172/0x490 [ 196.161018] ? acpi_os_signal_semaphore+0x8a/0xd0 [ 196.161038] acpi_evaluate_integer+0x52/0xe0 [ 196.161055] ? kfree+0x79/0x120 [ 196.161071] ? srso_alias_return_thunk+0x5/0x7f [ 196.161089] acpi_ac_get_state.part.0+0x27/0x80 [ 196.161110] get_ac_property+0x5c/0x70 [ 196.161127] ? __pfx___power_supply_is_system_supplied+0x10/0x10 [ 196.161146] __power_supply_is_system_supplied+0x44/0xb0 [ 196.161166] class_for_each_device+0x124/0x160 [ 196.161184] ? acpi_ac_get_state.part.0+0x27/0x80 [ 196.161203] ? srso_alias_return_thunk+0x5/0x7f [ 196.161223] power_supply_is_system_supplied+0x3c/0x70 [ 196.161243] amd_pmf_get_power_source+0xe/0x20 [amd_pmf] [ 196.161276] amd_pmf_power_slider_update_event+0x49/0x90 [amd_pmf] [ 196.161310] amd_pmf_pwr_src_notify_call+0xe7/0x100 [amd_pmf] [ 196.161340] notifier_call_chain+0x5f/0xe0 [ 196.161362] atomic_notifier_call_chain+0x33/0x60 [ 196.161378] power_supply_changed_work+0x84/0x110 [ 196.161394] process_one_work+0x178/0x360 [ 196.161412] ? __pfx_worker_thread+0x10/0x10 [ 196.161424] worker_thread+0x307/0x430 [ 196.161440] ? __pfx_worker_thread+0x10/0x10 [ 196.161451] kthread+0xf4/0x130 [ 196.161467] ? __pfx_kthread+0x10/0x10 [ 196.161486] ret_from_fork+0x43/0x70 [ 196.161502] ? __pfx_kthread+0x10/0x10 [ 196.161518] ret_from_fork_asm+0x1b/0x30 [ 196.161558] </TASK> [ 196.161562] ---[ end trace 0000000000000000 ]--- Since there's no guarantee that all the callbacks can work in atomic context, switch to use blocking_notifier_call_chain to relax the constraint. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: Allen Zhong <allen@atr.me> Fixes: 4c71ae414474 ("platform/x86/amd/pmf: Add support SPS PMF feature") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217571 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230913033233.602986-1-kai.heng.feng@canonical.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2023-03-29power: supply: core: auto-exposure of simple-battery dataSebastian Reichel
Automatically expose data from the simple-battery firmware node for all battery drivers. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2022-09-11power: supply: Explain maintenance chargingLinus Walleij
In order for everyone to understand clearly why we want to use maintenance charging for batteries, expand the description with two diagrams and some text. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-28power: supply: Support VBAT-to-Ri lookup tablesLinus Walleij
In Samsung devices, the method used to compensate for temperature, age, load etc is by way of VBAT to Ri tables, which correlates the battery voltage under load (VBAT) to an internal resistance (Ri). Using this Ri and a measurement of the current out of the battery (IBAT) the open circuit voltage (OCV) can be calculated as: OCV = VBAT - (Ri * IBAT) The details are described in comments to struct power_supply_battery_info in the commit. Since not all batteries supply this VBAT-to-Ri data, the fallback method to use the temperature-to-Ri lookup table can also be used as a fallback. Add two helper functions to check if we have the tables needed for using power_supply_vbat2ri() or power_supply_temp2resist_simple() respectively, so capacity estimation code can choose which one to employ. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-28power: supply: ab8500: Standardize BTI resistanceLinus Walleij
The Battery Type Indicator (BTI) resistor is a resistor mounted between a special terminal on the battery and ground. By sending a fixed current (such as 7mA) through this resistor and measuring the voltage over it, the resistance can be determined, and this verifies the battery type. Typical side view of the battery: o o o GND BTI +3.8V Typical example of the electrical layout: +3.8 V BTI | | | + | _______ [ ] 7kOhm ___ | | | | | GND GND By verifying this resistance before attempting to charge the battery we add an additional level of security. In some systems this is used for plug-and-play of batteries with different capacity. In other cases, this is merely used to verify that the right type of battery is connected, if several batteries have the same physical shape and can be plugged into the same slot. Sometimes this is just a surplus security mechanism. Nokia and Samsung among many other vendors are known to use these BTI resistors. Add the BTI properties to struct power_supply_battery_info and switch the AB8500 charger code over to using it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-28power: supply: ab8500: Standardize alert mode chargingLinus Walleij
The AB8500 code is using a special current and voltage setting when the battery is in "alert mode", i.e. when it is starting to go outside normal operating conditions so it is too cold or too hot. This makes sense as a way for the charging algorithm to deal with hostile environments. Add the needed members to the struct power_supply_battery_info, and switch the AB8500 charging code over to using this. Reviewed-by: Matti Vaittineen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-28power: supply: ab8500: Standardize maintenance chargingLinus Walleij
Maintenance charging is the phase of keeping up the charge after the battery has charged fully using CC/CV charging. This can be done in many successive phases and is usually done with a slightly lower constant voltage than CV, and a slightly lower allowed current. Add an array of maintenance charging points each with a current, voltage and safety timer, and add helper functions to use these. Migrate the AB8500 code over. This is used in several Samsung products using the AB8500 and these batteries and their complete parameters will be added later as full examples, but the default battery in the AB8500 code serves as a reasonable example so far. Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-24power: supply: Introduces bypass charging propertyRicardo Rivera-Matos
Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE property to facilitate bypass charging operation. In bypass charging operation, the charger bypasses the charging path around the integrated converter allowing for a "smart" wall adaptor to perform the power conversion externally. This operational mode is critical for the USB PPS standard of power adaptors and is becoming a common feature in modern charging ICs such as: - BQ25980 - BQ25975 - BQ25960 - LN8000 - LN8410 Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-01power: supply: core: Refactor ↵Hans de Goede
power_supply_set_input_current_limit_from_supplier() Some (USB) charger ICs have variants with USB D+ and D- pins to do their own builtin charger-type detection, like e.g. the bq24190 and bq25890 and also variants which lack this functionality, e.g. the bq24192 and bq25892. In case the charger-type; and thus the input-current-limit detection is done outside the charger IC then we need some way to communicate this to the charger IC. In the past extcon was used for this, but if the external detection does e.g. full USB PD negotiation then the extcon cable-types do not convey enough information. For these setups it was decided to model the external charging "brick" and the parameters negotiated with it as a power_supply class-device itself; and power_supply_set_input_current_limit_from_supplier() was introduced to allow drivers to get the input-current-limit this way. But in some cases psy drivers may want to know other properties, e.g. the bq25892 can do "quick-charge" negotiation by pulsing its current draw, but this should only be done if the usb_type psy-property of its supplier is set to DCP (and device-properties indicate the board allows higher voltages). Instead of adding extra helper functions for each property which a psy-driver wants to query from its supplier, refactor power_supply_set_input_current_limit_from_supplier() into a more generic power_supply_get_property_from_supplier() function. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-01-11Merge tag 'platform-drivers-x86-v5.17-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: "Highlights: New drivers: - asus-tf103c-dock - intel_crystal_cove_charger - lenovo-yogabook-wmi - simatic-ipc platform-code + led driver + watchdog driver - x86-android-tablets (kernel module to workaround DSDT bugs on these) amd-pmc: - bug-fixes - smar trace buffer support asus-wmi: - support for custom fan curves int3472 (camera info ACPI object for Intel IPU3/SkyCam cameras): - ACPI core + int3472 changes to delay enumeration of camera sensor I2C clients until the PMIC for the sensor has been fully probed - Add support for board data (DSDT info is incomplete) for setting up the tps68470 PMIC used on some boards with these cameras - Add board data for the Microsoft Surface Go (original, v2 and v3) thinkpad_acpi: - various cleanups - support for forced battery discharging (for battery calibration) - support to inhibit battery charging - this includes power_supply core changes to add new APIs for this think_lmi: - enhanced BIOS password support various other small fixes and hardware-id additions" * tag 'platform-drivers-x86-v5.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (78 commits) power: supply: Provide stubs for charge_behaviour helpers platform/x86: x86-android-tablets: Fix GPIO lookup leak on error-exit platform/x86: int3472: Add board data for Surface Go 3 platform/x86: Add Asus TF103C dock driver platform/x86: x86-android-tablets: Add TM800A550L data platform/x86: x86-android-tablets: Add Asus MeMO Pad 7 ME176C data platform/x86: x86-android-tablets: Add Asus TF103C data platform/x86: x86-android-tablets: Add support for preloading modules platform/x86: x86-android-tablets: Add support for registering GPIO lookup tables platform/x86: x86-android-tablets: Add support for instantiating serdevs platform/x86: x86-android-tablets: Add support for instantiating platform-devs platform/x86: x86-android-tablets: Add support for PMIC interrupts platform/x86: x86-android-tablets: Don't return -EPROBE_DEFER from a non probe() function platform/x86: touchscreen_dmi: Remove the Glavey TM800A550L entry platform/x86: touchscreen_dmi: Enable pen support on the Chuwi Hi10 Plus and Pro platform/x86: touchscreen_dmi: Correct min/max values for Chuwi Hi10 Pro (CWI529) tablet platform/x86: Add intel_crystal_cove_charger driver power: supply: fix charge_behaviour attribute initialization platform/x86: intel-uncore-frequency: use default_groups in kobj_type x86/platform/uv: use default_groups in kobj_type ...
2022-01-08power: supply: Provide stubs for charge_behaviour helpersThomas Weißschuh
When CONFIG_SYSFS is not enabled provide stubs for the helper functions to not break their callers. Fixes: 539b9c94ac83 ("power: supply: add helpers for charge_behaviour sysfs") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20220108153158.189489-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-01-03power: supply_core: Pass pointer to battery infoLinus Walleij
The function to retrieve battery info (from the device tree) assumes we have a static info struct that gets populated by calling into power_supply_get_battery_info(). This is awkward since I want to support tables of static battery info by just assigning a pointer to all info based on e.g. a compatible value in the device tree. We also have a mixture of static and dynamically allocated variables here. Bite the bullet and let power_supply_get_battery_info() allocate also the memory used for the very top level struct power_supply_battery_info container. Pass pointers around and lifecycle this with the psy device just like the stuff we allocate inside it. Change all current users over. As part of the change, initializers need to be added to some previously uninitialized fields in struct power_supply_battery_info. Reviewed-By: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-12-21power: supply: add helpers for charge_behaviour sysfsThomas Weißschuh
These helper functions can be used by drivers to implement their own sysfs-attributes. This is useful for ACPI-drivers extending the default ACPI-battery with their own charge_behaviour attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20211123232704.25394-3-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-21power: supply: add charge_behaviour attributesThomas Weißschuh
This a revised version of "[RFC] add standardized attributes for force_discharge and inhibit_charge" [0], incorporating discussion results. The biggest change is the switch from two boolean attributes to a single enum attribute. [0] https://lore.kernel.org/platform-driver-x86/21569a89-8303-8573-05fb-c2fec29983d1@gmail.com/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20211123232704.25394-2-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-11-17power: supply: core: Add kerneldoc to battery structLinus Walleij
This complements the struct power_supply_battery_info with extensive kerneldoc explaining the different semantics of the fields, including an overview of the CC/CV charging concepts implicit in some of the struct members. This is done to first establish semantics before I can add more charging methods by breaking out the CC/CV parameters to its own struct. Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>