summaryrefslogtreecommitdiff
path: root/drivers/power/supply/power_supply_sysfs.c
AgeCommit message (Collapse)Author
2020-12-13power: supply: Fix a typo in warning messageMasanari Iida
This patch fix a warning messages in power_supply_sysfs.c Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-08-26power: supply: add wireless typeSubbaraman Narayanamurthy
Currently, power_supply framework supports only Battery, UPS, Mains and USB power_supply_type. Add wireless power_supply_type so that the drivers which supports wireless can register a power supply class device with POWER_SUPPLY_TYPE_WIRELESS. Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-07-31power: supply: wilco_ec: Add long life charging modeCrag Wang
This is a long life mode set in the factory for extended warranty battery, the power charging rate is customized so that battery at work last longer. Presently switching to a different battery charging mode is through EC PID 0x0710 to configure the battery firmware, this operation will be blocked by EC with failure code 0x01 when PLL mode is already in use. Signed-off-by: Crag Wang <crag.wang@dell.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-07-21power_supply: Add additional health properties to the headerDan Murphy
Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum. HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken from JEITA specification JISC8712:2015 Acked-by: Andrew F. Davis <afd@ti.com> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-06-19power: supply: use kobj_to_devWang Qing
Use kobj_to_dev() API instead of open-coded container_of(). Signed-off-by: Wang Qing <wangqing@vivo.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-28power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIREDSebastian Reichel
Some battery fuel gauges know when the battery needs to be recalibrated before providing usable values. This should be reported via the health property. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-28power: supply: core: add manufacture date propertiesSebastian Reichel
Some smart batteries store their manufacture date, which is useful to identify the battery and/or to know about the cell quality. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-28power: supply: core: add capacity error margin propertySebastian Reichel
Add a property for reporting the error margin expected by fuel gauge chips. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-07power: supply: core: Add type property to uevent envMathew King
Add POWER_SUPPLY_TYPE to the uevent env for power supply. Type is a property of all power supplies and there is a sysfs entry for it but it is not included in the properties array of the power supply so explicitly add it to the udev env. Signed-off-by: Mathew King <mathewk@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-07power: supply: core: Add a macro that maps enum properties to text valuesMathew King
Reduce the number of touch points to add a new enum property to the power_supply class by mapping the array of text values to the device attribute descriptor. A new enum property can now added by creating an array with the text values named POWER_SUPPLY_${PROPNAME}_TEXT and adding POWER_SUPPLY_ENUM_ATTR(${PROPNAME}) to the power_supply_attrs array. Signed-off-by: Mathew King <mathewk@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-07power: supply: core: Use designated initializer for property text arraysMathew King
Use designated initializers for the sysfs power supply text values. This will help ensure that the text values are kept in sync with the enum values from power_supply.h. Signed-off-by: Mathew King <mathewk@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-07power: supply: core: Cleanup power supply sysfs attribute listMathew King
Make the device attribute list used to create sysfs attributes more robust by decoupling the list order from order of the enum defined in power_supply.h. This is done by using a designated initializer in the POWER_SUPPLY_ATTR macro. Signed-off-by: Mathew King <mathewk@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-05-01power: supply: core: reduce power_supply_show_usb_type() parametersMichał Mirosław
Reduce power_supply_show_usb_type() parameter count by folding power_supply_desc dereference into the function. This makes following patch making usb_types const easier. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-07-15Merge tag 'for-v5.3' 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: "Core: - add HWMON compat layer - new properties: - input power limit - input voltage limit Drivers: - qcom-pon: add gen2 support - new driver for storing reboot move in NVMEM - new driver for Wilco EC charger configuration - simplify getting the adapter of a client" * tag 'for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: reset: nvmem-reboot-mode: add CONFIG_OF dependency power_supply: wilco_ec: Add charging config driver power: supply: cros: allow to set input voltage and current limit power: supply: add input power and voltage limit properties power: supply: fix semicolon.cocci warnings power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface dt-bindings: power: reset: add document for NVMEM based reboot-mode reset: qcom-pon: Add support for gen2 pon dt-bindings: power: reset: qcom: Add qcom,pm8998-pon compatibility line power: supply: Add HWMON compatibility layer power: supply: sbs-manager: simplify getting the adapter of a client power: supply: rt9455_charger: simplify getting the adapter of a client power: supply: rt5033_battery: simplify getting the adapter of a client power: supply: max17042_battery: simplify getting the adapter of a client power: supply: max17040_battery: simplify getting the adapter of a client power: supply: max14656_charger_detector: simplify getting the adapter of a client power: supply: bq25890_charger: simplify getting the adapter of a client power: supply: bq24257_charger: simplify getting the adapter of a client power: supply: bq24190_charger: simplify getting the adapter of a client
2019-06-28power: supply: add input power and voltage limit propertiesEnric Balletbo i Serra
For thermal management strategy you might be interested on limit the input power for a power supply. We already have current limit but basically what we probably want is to limit power. So, introduce the input_power_limit property. Although the common use case is limit the input power, in some specific cases it is the voltage that is problematic (i.e some regulators have different efficiencies at higher voltage resulting in more heat). So introduce also the input_voltage_limit property. This happens in one Chromebook and is used on the Pixel C's thermal management strategy to effectively limit the input power to 5V 3A when the screen is on. When the screen is on, the display, the CPU, and the GPU all contribute more heat to the system than while the screen is off, and we made a tradeoff to throttle the charger in order to give more of the thermal budget to those other components. So there's nothing fundamentally broken about the hardware that would cause the Pixel C to malfunction if we were charging at 9V or 12V instead of 5V when the screen is on, i.e. if userspace doesn't change this. What would happen is that you wouldn't meet Google's skin temperature targets on the system if the charger was allowed to run at 9V or 12V with the screen on. For folks hacking on Pixel Cs (which is now outside of Google's official support window for Android) and customizing their own kernel and userspace this would be acceptable, but we wanted to expose this feature in the power supply properties because the feature does exist in the Emedded Controller firmware of the Pixel C and all of Google's Chromebooks with USB-C made since 2015 in case someone running an up to date kernel wanted to limit the charging power for thermal or other reasons. This patch exposes a new property, similar to input current limit, to re-configure the maximum voltage from the external supply at runtime based on system-level knowledge or user input. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 218Thomas Gleixner
Based on 1 normalized pattern(s): you may use this code as per gpl version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 5 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Steve Winslow <swinslow@gmail.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528171439.762454146@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-15Merge tag 'for-v5.2' 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: "Core: - Add over-current health state - Add standard, adaptive and custom charge types - Add new properties for start/end charge threshold New Drivers / Hardware: - UCS1002 Programmable USB Port Power Controller - Ingenic JZ47xx Battery Fuel Gauge - AXP20x USB Power: Add AXP813 support - AT91 poweroff: Add SAM9X60 support - OLPC battery: Add XO-1.5 and XO-1.75 support Misc Changes: - syscon-reboot: support mask property - AXP288 fuel gauge: Blacklist ACEPC T8/T11. Looks like some vendor thought it's a good idea to build a desktop system with a fuel gauge, that slowly "discharges"... - cpcap-battery: Fix calculation errors - misc fixes" * tag 'for-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (54 commits) power: supply: olpc_battery: force the le/be casts power: supply: ucs1002: Fix build error without CONFIG_REGULATOR power: supply: ucs1002: Fix wrong return value checking power: supply: Add driver for Microchip UCS1002 dt-bindings: power: supply: Add bindings for Microchip UCS1002 power: supply: core: Add POWER_SUPPLY_HEALTH_OVERCURRENT constant power: supply: core: fix clang -Wunsequenced power: supply: core: Add missing documentation for CHARGE_CONTROL_* properties power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties power: supply: core: Add Standard, Adaptive, and Custom charge types power: supply: axp288_fuel_gauge: Add ACEPC T8 and T11 mini PCs to the blacklist power: supply: bq27xxx_battery: Notify also about status changes power: supply: olpc_battery: Have the framework register sysfs files for us power: supply: olpc_battery: Add OLPC XO 1.75 support power: supply: olpc_battery: Avoid using platform_info power: supply: olpc_battery: Use devm_power_supply_register() power: supply: olpc_battery: Move priv data to a struct power: supply: olpc_battery: Use DT to get battery version x86/platform/olpc: Use a correct version when making up a battery node x86/platform/olpc: Trivial code move in DT fixup ...
2019-05-03power: supply: core: Add POWER_SUPPLY_HEALTH_OVERCURRENT constantAndrey Smirnov
Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow singalling overcurrent condition via power supply health information. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Cc: Enric Balletbo Serra <enric.balletbo@collabora.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-05-02power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} ↵Nick Crews
properties Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand the existing CHARGE_CONTROL_* properties. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. When the charge_type is "Custom", the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. For example, in the use case that I am supporting, this means the battery begins charging when the percentage level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and charging ceases when the percentage level goes above POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD. v5 changes: - Add the other missing CHARGE_CONTROL_* properties documentation in a separate commit - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-05-02power: supply: core: Add Standard, Adaptive, and Custom charge typesNick Crews
Add "Standard", "Adaptive", and "Custom" modes to the charge_type property, to expand the existing "Trickle" and "Fast" modes. I am adding them in order to support a new Chrome OS device, but these properties should be general enough that they can be used on other devices. The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are more tricky: "Adaptive" means that the charge controller uses some custom algorithm to change the charge type automatically, with no configuration needed. "Custom" means that the charge controller uses the POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some other algorithm. v5 changes: - Split up adding the charge types and adding the POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into two different commits. v4 changes: - Add documentation for the new properties, and add documentation for the the previously missing charge_control_limit and charge_control_limit_max properties. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-26power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUGAndrey Smirnov
Fix a similar endless event loop as was done in commit 8dcf32175b4e ("i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE"): The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry Both CONFIG_I2C_DEBUG_CORE and CONFIG_POWER_SUPPLY_DEBUG were reported in https://bugs.freedesktop.org/show_bug.cgi?id=76886 but only former seems to have been fixed. Drop debug prints as it was done in I2C subsystem to resolve the issue. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-09-16power: supply: sysfs: ratelimit property read error messageDavid Lechner
This adds rate limiting to the message that is printed when reading a power supply property via sysfs returns an error. This will prevent userspace applications from unintentionally dDOSing the system by continuously reading a property that returns an error. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-04-26Merge tag 'tags/tcpm-pps-4.18' into psy-nextSebastian Reichel
Tag/Merge point for adding typeC power supply support This is a signed tag/merge point to handle the cross-tree merge of the USB and power supply subsystems for the patch series: Subject: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS It is based on the usb.git tree, in the usb-next branch, for merging in 4.18-rc1. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-04-25power: supply: sysfs: Use enum to specify propertyLadislav Michl
Power supply property is in fact enum, so reflect it in code. Also use switch statement in show property function as is done for storing property. Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-04-25power: supply: Add 'usb_type' property and supporting codeAdam Thomson
This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event, to represent what was connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations however don't show all supported connectable types, so this knowledge has to be exlicitly known for each driver that supports this. The 'usb_type' property is intended to fill this void and show users all possible USB types supported by a driver. The property, when read, shows all available types for the driver, and the one currently chosen is highlighted/bracketed. It is expected that the 'type' property would then just show the top-level type 'USB', and this would be static. Currently the 'usb_type' enum contains all of the USB variant types that exist for the 'type' enum at this time, and in addition has SDP and PPS types. The mirroring is intentional so as to not impact existing usage of the 'type' property. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-08power: supply: core: Add power_supply_prop_prechargeLiam Breck
Battery chargers use POWER_SUPPLY_PROP_PRECHARGE_CURRENT Clarify related item POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT Signed-off-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-06-08power: supply: sysfs: parse string as enum when writing propertyDavid Lechner
This fixes the TODO to parse strings and convert them to enum values when writing to a power_supply class property sysfs attribute. There is at least one driver that has a writable enum property that previously could only be written as an integer, so a fallback to writing enums as integers instead of strings is provided so we don't break existing userspace programs. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-06-08power: supply: Add Apple Brick ID power supply typeBenson Leung
Apple currently supports three very common USB chargers: https://www.apple.com/power-adapters/ These chargers implement a proprietary Apple method for advertising 1A, 2.1A, and 2.4A at 5V called "Brick ID". In addition, 3rd parties implement the same charging method in many charging accessories that work with iOS devices. Devices that have charger detection chips such as the Pericom PI3USB9281, eg. Google Chromebook Pixel 2015, are capable of detecting these chargers, so let's add a type to facilicate passing that info up to userspace. This adds a separate power supply type for Apple's proprietary "Brick ID" charging method. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2016-08-11power: move power supply drivers to power/supplySebastian Reichel
This moves all power supply drivers from drivers/power/ to drivers/power/supply/. The intention is a cleaner source tree, since drivers/power/ also contains frameworks unrelated to power supply, like adaptive voltage scaling. Signed-off-by: Sebastian Reichel <sre@kernel.org>