2019-05-28 20:10:21 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2007-05-04 00:27:45 +04:00
|
|
|
/*
|
|
|
|
* Universal power supply monitor class
|
|
|
|
*
|
|
|
|
* Copyright © 2007 Anton Vorontsov <cbou@mail.ru>
|
|
|
|
* Copyright © 2004 Szabolcs Gyurko
|
|
|
|
* Copyright © 2003 Ian Molton <spyro@f2s.com>
|
|
|
|
*
|
|
|
|
* Modified: 2004, Oct Szabolcs Gyurko
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __LINUX_POWER_SUPPLY_H__
|
|
|
|
#define __LINUX_POWER_SUPPLY_H__
|
|
|
|
|
2015-03-12 10:44:11 +03:00
|
|
|
#include <linux/device.h>
|
2007-05-04 00:27:45 +04:00
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/leds.h>
|
2013-08-03 00:38:02 +04:00
|
|
|
#include <linux/spinlock.h>
|
2013-11-19 14:18:03 +04:00
|
|
|
#include <linux/notifier.h>
|
2007-05-04 00:27:45 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* All voltages, currents, charges, energies, time and temperatures in uV,
|
|
|
|
* µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
|
|
|
|
* stated. It's driver's job to convert its raw values to units in which
|
|
|
|
* this class operates.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For systems where the charger determines the maximum battery capacity
|
|
|
|
* the min and max fields should be used to present these values to user
|
|
|
|
* space. Unused/unknown fields will not appear in sysfs.
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_STATUS_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_STATUS_CHARGING,
|
|
|
|
POWER_SUPPLY_STATUS_DISCHARGING,
|
|
|
|
POWER_SUPPLY_STATUS_NOT_CHARGING,
|
|
|
|
POWER_SUPPLY_STATUS_FULL,
|
|
|
|
};
|
|
|
|
|
2019-04-18 19:43:12 +03:00
|
|
|
/* What algorithm is the charger using? */
|
2009-07-02 17:45:18 +04:00
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_NONE,
|
2019-04-18 19:43:12 +03:00
|
|
|
POWER_SUPPLY_CHARGE_TYPE_TRICKLE, /* slow speed */
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_FAST, /* fast speed */
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_STANDARD, /* normal speed */
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE, /* dynamically adjusted speed */
|
|
|
|
POWER_SUPPLY_CHARGE_TYPE_CUSTOM, /* use CHARGE_CONTROL_* props */
|
2020-07-30 06:26:09 +03:00
|
|
|
POWER_SUPPLY_CHARGE_TYPE_LONGLIFE, /* slow speed, longer life */
|
2022-02-15 03:07:56 +03:00
|
|
|
POWER_SUPPLY_CHARGE_TYPE_BYPASS, /* bypassing the charger */
|
2009-07-02 17:45:18 +04:00
|
|
|
};
|
|
|
|
|
2007-05-04 00:27:45 +04:00
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_HEALTH_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_HEALTH_GOOD,
|
|
|
|
POWER_SUPPLY_HEALTH_OVERHEAT,
|
|
|
|
POWER_SUPPLY_HEALTH_DEAD,
|
|
|
|
POWER_SUPPLY_HEALTH_OVERVOLTAGE,
|
|
|
|
POWER_SUPPLY_HEALTH_UNSPEC_FAILURE,
|
2008-12-01 00:43:21 +03:00
|
|
|
POWER_SUPPLY_HEALTH_COLD,
|
2012-11-30 12:27:46 +04:00
|
|
|
POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
|
|
|
|
POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
|
2019-05-03 20:00:40 +03:00
|
|
|
POWER_SUPPLY_HEALTH_OVERCURRENT,
|
2020-05-13 21:56:00 +03:00
|
|
|
POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED,
|
2020-07-20 23:43:57 +03:00
|
|
|
POWER_SUPPLY_HEALTH_WARM,
|
|
|
|
POWER_SUPPLY_HEALTH_COOL,
|
|
|
|
POWER_SUPPLY_HEALTH_HOT,
|
2021-11-08 19:27:05 +03:00
|
|
|
POWER_SUPPLY_HEALTH_NO_BATTERY,
|
2007-05-04 00:27:45 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_NiMH,
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_LION,
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_LIPO,
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_LiFe,
|
|
|
|
POWER_SUPPLY_TECHNOLOGY_NiCd,
|
2008-01-07 04:12:41 +03:00
|
|
|
POWER_SUPPLY_TECHNOLOGY_LiMn,
|
2007-05-04 00:27:45 +04:00
|
|
|
};
|
|
|
|
|
2009-06-30 10:13:01 +04:00
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL,
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_LOW,
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_NORMAL,
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_HIGH,
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_FULL,
|
|
|
|
};
|
|
|
|
|
2011-12-07 23:24:20 +04:00
|
|
|
enum {
|
|
|
|
POWER_SUPPLY_SCOPE_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_SCOPE_SYSTEM,
|
|
|
|
POWER_SUPPLY_SCOPE_DEVICE,
|
|
|
|
};
|
|
|
|
|
2007-05-04 00:27:45 +04:00
|
|
|
enum power_supply_property {
|
|
|
|
/* Properties of type `int' */
|
|
|
|
POWER_SUPPLY_PROP_STATUS = 0,
|
2009-07-02 17:45:18 +04:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_TYPE,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_HEALTH,
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
POWER_SUPPLY_PROP_ONLINE,
|
2012-08-23 05:20:21 +04:00
|
|
|
POWER_SUPPLY_PROP_AUTHENTIC,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
2009-10-15 14:31:30 +04:00
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
2008-01-07 04:12:41 +03:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MAX,
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_AVG,
|
2012-04-10 14:51:20 +04:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_OCV,
|
2014-08-27 22:14:08 +04:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_BOOT,
|
2010-10-04 11:51:38 +04:00
|
|
|
POWER_SUPPLY_PROP_CURRENT_MAX,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_CURRENT_NOW,
|
|
|
|
POWER_SUPPLY_PROP_CURRENT_AVG,
|
2014-08-27 22:14:08 +04:00
|
|
|
POWER_SUPPLY_PROP_CURRENT_BOOT,
|
2009-03-28 05:23:52 +03:00
|
|
|
POWER_SUPPLY_PROP_POWER_NOW,
|
|
|
|
POWER_SUPPLY_PROP_POWER_AVG,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_EMPTY,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_NOW,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_AVG,
|
2008-05-13 05:46:29 +04:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_COUNTER,
|
2012-05-06 16:46:44 +04:00
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
|
2012-07-30 11:19:21 +04:00
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
|
2012-05-06 16:46:44 +04:00
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
|
2012-07-30 11:19:21 +04:00
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
|
2012-10-09 20:55:29 +04:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
|
2019-04-18 19:43:13 +03:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
|
2021-11-24 02:27:01 +03:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR,
|
2014-07-08 10:04:18 +04:00
|
|
|
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
|
power: supply: add input power and voltage limit properties
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-07 12:52:47 +03:00
|
|
|
POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT,
|
|
|
|
POWER_SUPPLY_PROP_INPUT_POWER_LIMIT,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_EMPTY,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_NOW,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_AVG,
|
|
|
|
POWER_SUPPLY_PROP_CAPACITY, /* in percents! */
|
2012-07-05 15:29:12 +04:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_ALERT_MIN, /* in percents! */
|
|
|
|
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
|
2020-05-13 21:55:58 +03:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN, /* in percents! */
|
2009-06-30 10:13:01 +04:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_TEMP,
|
2014-07-08 10:04:18 +04:00
|
|
|
POWER_SUPPLY_PROP_TEMP_MAX,
|
|
|
|
POWER_SUPPLY_PROP_TEMP_MIN,
|
2012-07-05 15:29:12 +04:00
|
|
|
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
|
|
|
|
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_TEMP_AMBIENT,
|
2012-07-05 15:29:12 +04:00
|
|
|
POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MIN,
|
|
|
|
POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MAX,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
|
|
|
|
POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
|
|
|
|
POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
|
|
|
|
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
|
2010-05-18 23:49:51 +04:00
|
|
|
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
|
power: supply: Add 'usb_type' property and supporting code
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>
2018-04-23 17:10:59 +03:00
|
|
|
POWER_SUPPLY_PROP_USB_TYPE,
|
2011-12-07 23:24:20 +04:00
|
|
|
POWER_SUPPLY_PROP_SCOPE,
|
2017-06-07 21:37:52 +03:00
|
|
|
POWER_SUPPLY_PROP_PRECHARGE_CURRENT,
|
2014-07-08 10:04:18 +04:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
|
2014-08-27 22:14:08 +04:00
|
|
|
POWER_SUPPLY_PROP_CALIBRATE,
|
2020-05-13 21:55:59 +03:00
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_YEAR,
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_MONTH,
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_DAY,
|
2007-05-04 00:27:45 +04:00
|
|
|
/* Properties of type `const char *' */
|
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
2008-01-22 20:46:50 +03:00
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
2007-05-04 00:27:45 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
enum power_supply_type {
|
2011-12-01 11:08:33 +04:00
|
|
|
POWER_SUPPLY_TYPE_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_TYPE_BATTERY,
|
2007-05-04 00:27:45 +04:00
|
|
|
POWER_SUPPLY_TYPE_UPS,
|
|
|
|
POWER_SUPPLY_TYPE_MAINS,
|
2017-05-09 01:02:48 +03:00
|
|
|
POWER_SUPPLY_TYPE_USB, /* Standard Downstream Port */
|
|
|
|
POWER_SUPPLY_TYPE_USB_DCP, /* Dedicated Charging Port */
|
|
|
|
POWER_SUPPLY_TYPE_USB_CDP, /* Charging Downstream Port */
|
|
|
|
POWER_SUPPLY_TYPE_USB_ACA, /* Accessory Charger Adapters */
|
|
|
|
POWER_SUPPLY_TYPE_USB_TYPE_C, /* Type C Port */
|
|
|
|
POWER_SUPPLY_TYPE_USB_PD, /* Power Delivery Port */
|
|
|
|
POWER_SUPPLY_TYPE_USB_PD_DRP, /* PD Dual Role Port */
|
|
|
|
POWER_SUPPLY_TYPE_APPLE_BRICK_ID, /* Apple Charging Method */
|
2020-08-13 21:34:08 +03:00
|
|
|
POWER_SUPPLY_TYPE_WIRELESS, /* Wireless */
|
2007-05-04 00:27:45 +04:00
|
|
|
};
|
|
|
|
|
power: supply: Add 'usb_type' property and supporting code
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>
2018-04-23 17:10:59 +03:00
|
|
|
enum power_supply_usb_type {
|
|
|
|
POWER_SUPPLY_USB_TYPE_UNKNOWN = 0,
|
|
|
|
POWER_SUPPLY_USB_TYPE_SDP, /* Standard Downstream Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_DCP, /* Dedicated Charging Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_CDP, /* Charging Downstream Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_ACA, /* Accessory Charger Adapters */
|
|
|
|
POWER_SUPPLY_USB_TYPE_C, /* Type C Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_PD, /* Power Delivery Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_PD_DRP, /* PD Dual Role Port */
|
|
|
|
POWER_SUPPLY_USB_TYPE_PD_PPS, /* PD Programmable Power Supply */
|
|
|
|
POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID, /* Apple Charging Method */
|
|
|
|
};
|
|
|
|
|
2021-11-24 02:27:01 +03:00
|
|
|
enum power_supply_charge_behaviour {
|
|
|
|
POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO = 0,
|
|
|
|
POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE,
|
|
|
|
POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE,
|
|
|
|
};
|
|
|
|
|
2013-11-19 14:18:03 +04:00
|
|
|
enum power_supply_notifier_events {
|
|
|
|
PSY_EVENT_PROP_CHANGED,
|
|
|
|
};
|
|
|
|
|
2007-05-04 00:27:45 +04:00
|
|
|
union power_supply_propval {
|
|
|
|
int intval;
|
|
|
|
const char *strval;
|
|
|
|
};
|
|
|
|
|
2013-06-29 05:17:22 +04:00
|
|
|
struct device_node;
|
2015-03-12 10:44:11 +03:00
|
|
|
struct power_supply;
|
2013-06-29 05:17:22 +04:00
|
|
|
|
2015-03-12 10:44:11 +03:00
|
|
|
/* Run-time specific power supply configuration */
|
2015-03-12 10:44:02 +03:00
|
|
|
struct power_supply_config {
|
|
|
|
struct device_node *of_node;
|
2018-05-22 18:16:23 +03:00
|
|
|
struct fwnode_handle *fwnode;
|
|
|
|
|
2015-03-12 10:44:02 +03:00
|
|
|
/* Driver private data */
|
|
|
|
void *drv_data;
|
|
|
|
|
2018-09-27 16:46:03 +03:00
|
|
|
/* Device specific sysfs attributes */
|
|
|
|
const struct attribute_group **attr_grp;
|
|
|
|
|
2015-03-12 10:44:02 +03:00
|
|
|
char **supplied_to;
|
|
|
|
size_t num_supplicants;
|
|
|
|
};
|
|
|
|
|
2015-03-12 10:44:11 +03:00
|
|
|
/* Description of power supply */
|
|
|
|
struct power_supply_desc {
|
2007-05-04 00:27:45 +04:00
|
|
|
const char *name;
|
|
|
|
enum power_supply_type type;
|
2020-04-03 23:20:32 +03:00
|
|
|
const enum power_supply_usb_type *usb_types;
|
power: supply: Add 'usb_type' property and supporting code
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>
2018-04-23 17:10:59 +03:00
|
|
|
size_t num_usb_types;
|
2020-04-03 23:20:32 +03:00
|
|
|
const enum power_supply_property *properties;
|
2007-05-04 00:27:45 +04:00
|
|
|
size_t num_properties;
|
|
|
|
|
2015-03-12 10:44:03 +03:00
|
|
|
/*
|
|
|
|
* Functions for drivers implementing power supply class.
|
|
|
|
* These shouldn't be called directly by other drivers for accessing
|
|
|
|
* this power supply. Instead use power_supply_*() functions (for
|
|
|
|
* example power_supply_get_property()).
|
|
|
|
*/
|
2007-05-04 00:27:45 +04:00
|
|
|
int (*get_property)(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val);
|
2010-05-18 23:49:52 +04:00
|
|
|
int (*set_property)(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
const union power_supply_propval *val);
|
2015-06-08 04:09:48 +03:00
|
|
|
/*
|
|
|
|
* property_is_writeable() will be called during registration
|
|
|
|
* of power supply. If this happens during device probe then it must
|
|
|
|
* not access internal data of device (because probe did not end).
|
|
|
|
*/
|
2010-05-18 23:49:52 +04:00
|
|
|
int (*property_is_writeable)(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp);
|
2007-05-04 00:27:45 +04:00
|
|
|
void (*external_power_changed)(struct power_supply *psy);
|
2009-07-23 22:35:53 +04:00
|
|
|
void (*set_charged)(struct power_supply *psy);
|
2007-05-04 00:27:45 +04:00
|
|
|
|
2014-10-07 19:47:36 +04:00
|
|
|
/*
|
|
|
|
* Set if thermal zone should not be created for this power supply.
|
|
|
|
* For example for virtual supplies forwarding calls to actual
|
|
|
|
* sensors or other supplies.
|
|
|
|
*/
|
|
|
|
bool no_thermal;
|
2007-05-04 00:27:45 +04:00
|
|
|
/* For APM emulation, think legacy userspace. */
|
|
|
|
int use_for_apm;
|
2015-03-12 10:44:11 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
struct power_supply {
|
|
|
|
const struct power_supply_desc *desc;
|
|
|
|
|
|
|
|
char **supplied_to;
|
|
|
|
size_t num_supplicants;
|
|
|
|
|
|
|
|
char **supplied_from;
|
|
|
|
size_t num_supplies;
|
|
|
|
struct device_node *of_node;
|
2007-05-04 00:27:45 +04:00
|
|
|
|
2015-03-12 10:44:01 +03:00
|
|
|
/* Driver private data */
|
|
|
|
void *drv_data;
|
|
|
|
|
2007-05-04 00:27:45 +04:00
|
|
|
/* private */
|
2015-03-12 10:44:11 +03:00
|
|
|
struct device dev;
|
2007-05-04 00:27:45 +04:00
|
|
|
struct work_struct changed_work;
|
2015-05-19 10:13:02 +03:00
|
|
|
struct delayed_work deferred_register_work;
|
2013-08-03 00:38:02 +04:00
|
|
|
spinlock_t changed_lock;
|
|
|
|
bool changed;
|
2016-06-22 18:45:52 +03:00
|
|
|
bool initialized;
|
2018-06-25 10:51:48 +03:00
|
|
|
bool removing;
|
2015-03-12 10:44:03 +03:00
|
|
|
atomic_t use_cnt;
|
2012-05-09 19:06:47 +04:00
|
|
|
#ifdef CONFIG_THERMAL
|
|
|
|
struct thermal_zone_device *tzd;
|
2012-10-09 20:55:59 +04:00
|
|
|
struct thermal_cooling_device *tcd;
|
2012-05-09 19:06:47 +04:00
|
|
|
#endif
|
2007-05-04 00:27:45 +04:00
|
|
|
|
|
|
|
#ifdef CONFIG_LEDS_TRIGGERS
|
|
|
|
struct led_trigger *charging_full_trig;
|
|
|
|
char *charging_full_trig_name;
|
|
|
|
struct led_trigger *charging_trig;
|
|
|
|
char *charging_trig_name;
|
|
|
|
struct led_trigger *full_trig;
|
|
|
|
char *full_trig_name;
|
|
|
|
struct led_trigger *online_trig;
|
|
|
|
char *online_trig_name;
|
2011-01-07 19:28:17 +03:00
|
|
|
struct led_trigger *charging_blink_full_solid_trig;
|
|
|
|
char *charging_blink_full_solid_trig_name;
|
2007-05-04 00:27:45 +04:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is recommended structure to specify static power supply parameters.
|
|
|
|
* Generic one, parametrizable for different power supplies. Power supply
|
|
|
|
* class itself does not use it, but that's what implementing most platform
|
|
|
|
* drivers, should try reuse for consistency.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct power_supply_info {
|
|
|
|
const char *name;
|
|
|
|
int technology;
|
|
|
|
int voltage_max_design;
|
|
|
|
int voltage_min_design;
|
|
|
|
int charge_full_design;
|
|
|
|
int charge_empty_design;
|
|
|
|
int energy_full_design;
|
|
|
|
int energy_empty_design;
|
|
|
|
int use_for_apm;
|
|
|
|
};
|
|
|
|
|
2018-11-05 10:39:09 +03:00
|
|
|
struct power_supply_battery_ocv_table {
|
|
|
|
int ocv; /* microVolts */
|
|
|
|
int capacity; /* percent */
|
|
|
|
};
|
|
|
|
|
2019-12-09 06:56:22 +03:00
|
|
|
struct power_supply_resistance_temp_table {
|
|
|
|
int temp; /* celsius */
|
|
|
|
int resistance; /* internal resistance percent */
|
|
|
|
};
|
|
|
|
|
2022-02-26 02:27:58 +03:00
|
|
|
struct power_supply_vbat_ri_table {
|
|
|
|
int vbat_uv; /* Battery voltage in microvolt */
|
|
|
|
int ri_uohm; /* Internal resistance in microohm */
|
|
|
|
};
|
|
|
|
|
2022-02-26 02:27:55 +03:00
|
|
|
/**
|
|
|
|
* struct power_supply_maintenance_charge_table - setting for maintenace charging
|
|
|
|
* @charge_current_max_ua: maintenance charging current that is used to keep
|
|
|
|
* the charge of the battery full as current is consumed after full charging.
|
|
|
|
* The corresponding charge_voltage_max_uv is used as a safeguard: when we
|
|
|
|
* reach this voltage the maintenance charging current is turned off. It is
|
|
|
|
* turned back on if we fall below this voltage.
|
|
|
|
* @charge_voltage_max_uv: maintenance charging voltage that is usually a bit
|
|
|
|
* lower than the constant_charge_voltage_max_uv. We can apply this settings
|
|
|
|
* charge_current_max_ua until we get back up to this voltage.
|
|
|
|
* @safety_timer_minutes: maintenance charging safety timer, with an expiry
|
|
|
|
* time in minutes. We will only use maintenance charging in this setting
|
|
|
|
* for a certain amount of time, then we will first move to the next
|
|
|
|
* maintenance charge current and voltage pair in respective array and wait
|
|
|
|
* for the next safety timer timeout, or, if we reached the last maintencance
|
|
|
|
* charging setting, disable charging until we reach
|
|
|
|
* charge_restart_voltage_uv and restart ordinary CC/CV charging from there.
|
|
|
|
* These timers should be chosen to align with the typical discharge curve
|
|
|
|
* for the battery.
|
|
|
|
*
|
2022-07-19 14:41:31 +03:00
|
|
|
* Ordinary CC/CV charging will stop charging when the charge current goes
|
|
|
|
* below charge_term_current_ua, and then restart it (if the device is still
|
|
|
|
* plugged into the charger) at charge_restart_voltage_uv. This happens in most
|
|
|
|
* consumer products because the power usage while connected to a charger is
|
|
|
|
* not zero, and devices are not manufactured to draw power directly from the
|
|
|
|
* charger: instead they will at all times dissipate the battery a little, like
|
|
|
|
* the power used in standby mode. This will over time give a charge graph
|
|
|
|
* such as this:
|
|
|
|
*
|
|
|
|
* Energy
|
|
|
|
* ^ ... ... ... ... ... ... ...
|
|
|
|
* | . . . . . . . . . . . . .
|
|
|
|
* | .. . .. . .. . .. . .. . .. . ..
|
|
|
|
* |. .. .. .. .. .. ..
|
|
|
|
* +-------------------------------------------------------------------> t
|
|
|
|
*
|
|
|
|
* Practically this means that the Li-ions are wandering back and forth in the
|
|
|
|
* battery and this causes degeneration of the battery anode and cathode.
|
|
|
|
* To prolong the life of the battery, maintenance charging is applied after
|
|
|
|
* reaching charge_term_current_ua to hold up the charge in the battery while
|
|
|
|
* consuming power, thus lowering the wear on the battery:
|
|
|
|
*
|
|
|
|
* Energy
|
|
|
|
* ^ .......................................
|
|
|
|
* | . ......................
|
|
|
|
* | ..
|
|
|
|
* |.
|
|
|
|
* +-------------------------------------------------------------------> t
|
|
|
|
*
|
|
|
|
* Maintenance charging uses the voltages from this table: a table of settings
|
|
|
|
* is traversed using a slightly lower current and voltage than what is used for
|
2022-02-26 02:27:55 +03:00
|
|
|
* CC/CV charging. The maintenance charging will for safety reasons not go on
|
|
|
|
* indefinately: we lower the current and voltage with successive maintenance
|
|
|
|
* settings, then disable charging completely after we reach the last one,
|
|
|
|
* and after that we do not restart charging until we reach
|
|
|
|
* charge_restart_voltage_uv (see struct power_supply_battery_info) and restart
|
|
|
|
* ordinary CC/CV charging from there.
|
|
|
|
*
|
|
|
|
* As an example, a Samsung EB425161LA Lithium-Ion battery is CC/CV charged
|
2022-07-19 14:41:31 +03:00
|
|
|
* at 900mA to 4340mV, then maintenance charged at 600mA and 4150mV for up to
|
|
|
|
* 60 hours, then maintenance charged at 600mA and 4100mV for up to 200 hours.
|
2022-02-26 02:27:55 +03:00
|
|
|
* After this the charge cycle is restarted waiting for
|
|
|
|
* charge_restart_voltage_uv.
|
|
|
|
*
|
|
|
|
* For most mobile electronics this type of maintenance charging is enough for
|
|
|
|
* the user to disconnect the device and make use of it before both maintenance
|
2022-07-19 14:41:31 +03:00
|
|
|
* charging cycles are complete, if the current and voltage has been chosen
|
|
|
|
* appropriately. These need to be determined from battery discharge curves
|
|
|
|
* and expected standby current.
|
|
|
|
*
|
|
|
|
* If the voltage anyway drops to charge_restart_voltage_uv during maintenance
|
|
|
|
* charging, ordinary CC/CV charging is restarted. This can happen if the
|
|
|
|
* device is e.g. actively used during charging, so more current is drawn than
|
|
|
|
* the expected stand-by current. Also overvoltage protection will be applied
|
|
|
|
* as usual.
|
2022-02-26 02:27:55 +03:00
|
|
|
*/
|
|
|
|
struct power_supply_maintenance_charge_table {
|
|
|
|
int charge_current_max_ua;
|
|
|
|
int charge_voltage_max_uv;
|
|
|
|
int charge_safety_timer_minutes;
|
|
|
|
};
|
|
|
|
|
2018-11-05 10:39:09 +03:00
|
|
|
#define POWER_SUPPLY_OCV_TEMP_MAX 20
|
|
|
|
|
2021-11-17 01:44:28 +03:00
|
|
|
/**
|
|
|
|
* struct power_supply_battery_info - information about batteries
|
|
|
|
* @technology: from the POWER_SUPPLY_TECHNOLOGY_* enum
|
|
|
|
* @energy_full_design_uwh: energy content when fully charged in microwatt
|
|
|
|
* hours
|
|
|
|
* @charge_full_design_uah: charge content when fully charged in microampere
|
|
|
|
* hours
|
|
|
|
* @voltage_min_design_uv: minimum voltage across the poles when the battery
|
|
|
|
* is at minimum voltage level in microvolts. If the voltage drops below this
|
|
|
|
* level the battery will need precharging when using CC/CV charging.
|
|
|
|
* @voltage_max_design_uv: voltage across the poles when the battery is fully
|
|
|
|
* charged in microvolts. This is the "nominal voltage" i.e. the voltage
|
|
|
|
* printed on the label of the battery.
|
|
|
|
* @tricklecharge_current_ua: the tricklecharge current used when trickle
|
|
|
|
* charging the battery in microamperes. This is the charging phase when the
|
|
|
|
* battery is completely empty and we need to carefully trickle in some
|
|
|
|
* charge until we reach the precharging voltage.
|
|
|
|
* @precharge_current_ua: current to use in the precharge phase in microamperes,
|
|
|
|
* the precharge rate is limited by limiting the current to this value.
|
|
|
|
* @precharge_voltage_max_uv: the maximum voltage allowed when precharging in
|
|
|
|
* microvolts. When we pass this voltage we will nominally switch over to the
|
|
|
|
* CC (constant current) charging phase defined by constant_charge_current_ua
|
|
|
|
* and constant_charge_voltage_max_uv.
|
|
|
|
* @charge_term_current_ua: when the current in the CV (constant voltage)
|
|
|
|
* charging phase drops below this value in microamperes the charging will
|
|
|
|
* terminate completely and not restart until the voltage over the battery
|
|
|
|
* poles reach charge_restart_voltage_uv unless we use maintenance charging.
|
|
|
|
* @charge_restart_voltage_uv: when the battery has been fully charged by
|
|
|
|
* CC/CV charging and charging has been disabled, and the voltage subsequently
|
|
|
|
* drops below this value in microvolts, the charging will be restarted
|
|
|
|
* (typically using CV charging).
|
|
|
|
* @overvoltage_limit_uv: If the voltage exceeds the nominal voltage
|
|
|
|
* voltage_max_design_uv and we reach this voltage level, all charging must
|
|
|
|
* stop and emergency procedures take place, such as shutting down the system
|
|
|
|
* in some cases.
|
|
|
|
* @constant_charge_current_max_ua: current in microamperes to use in the CC
|
|
|
|
* (constant current) charging phase. The charging rate is limited
|
|
|
|
* by this current. This is the main charging phase and as the current is
|
|
|
|
* constant into the battery the voltage slowly ascends to
|
|
|
|
* constant_charge_voltage_max_uv.
|
|
|
|
* @constant_charge_voltage_max_uv: voltage in microvolts signifying the end of
|
|
|
|
* the CC (constant current) charging phase and the beginning of the CV
|
|
|
|
* (constant voltage) charging phase.
|
2022-02-26 02:27:55 +03:00
|
|
|
* @maintenance_charge: an array of maintenance charging settings to be used
|
|
|
|
* after the main CC/CV charging phase is complete.
|
|
|
|
* @maintenance_charge_size: the number of maintenance charging settings in
|
|
|
|
* maintenance_charge.
|
2022-02-26 02:27:56 +03:00
|
|
|
* @alert_low_temp_charge_current_ua: The charging current to use if the battery
|
|
|
|
* enters low alert temperature, i.e. if the internal temperature is between
|
|
|
|
* temp_alert_min and temp_min. No matter the charging phase, this
|
|
|
|
* and alert_high_temp_charge_voltage_uv will be applied.
|
|
|
|
* @alert_low_temp_charge_voltage_uv: Same as alert_low_temp_charge_current_ua,
|
|
|
|
* but for the charging voltage.
|
|
|
|
* @alert_high_temp_charge_current_ua: The charging current to use if the
|
|
|
|
* battery enters high alert temperature, i.e. if the internal temperature is
|
|
|
|
* between temp_alert_max and temp_max. No matter the charging phase, this
|
|
|
|
* and alert_high_temp_charge_voltage_uv will be applied, usually lowering
|
|
|
|
* the charging current as an evasive manouver.
|
|
|
|
* @alert_high_temp_charge_voltage_uv: Same as
|
|
|
|
* alert_high_temp_charge_current_ua, but for the charging voltage.
|
2021-11-17 01:44:28 +03:00
|
|
|
* @factory_internal_resistance_uohm: the internal resistance of the battery
|
|
|
|
* at fabrication time, expressed in microohms. This resistance will vary
|
|
|
|
* depending on the lifetime and charge of the battery, so this is just a
|
2022-02-26 02:27:58 +03:00
|
|
|
* nominal ballpark figure. This internal resistance is given for the state
|
|
|
|
* when the battery is discharging.
|
|
|
|
* @factory_internal_resistance_charging_uohm: the internal resistance of the
|
|
|
|
* battery at fabrication time while charging, expressed in microohms.
|
|
|
|
* The charging process will affect the internal resistance of the battery
|
|
|
|
* so this value provides a better resistance under these circumstances.
|
|
|
|
* This resistance will vary depending on the lifetime and charge of the
|
|
|
|
* battery, so this is just a nominal ballpark figure.
|
2021-11-17 01:44:28 +03:00
|
|
|
* @ocv_temp: array indicating the open circuit voltage (OCV) capacity
|
|
|
|
* temperature indices. This is an array of temperatures in degrees Celsius
|
|
|
|
* indicating which capacity table to use for a certain temperature, since
|
|
|
|
* the capacity for reasons of chemistry will be different at different
|
|
|
|
* temperatures. Determining capacity is a multivariate problem and the
|
|
|
|
* temperature is the first variable we determine.
|
|
|
|
* @temp_ambient_alert_min: the battery will go outside of operating conditions
|
|
|
|
* when the ambient temperature goes below this temperature in degrees
|
|
|
|
* Celsius.
|
|
|
|
* @temp_ambient_alert_max: the battery will go outside of operating conditions
|
|
|
|
* when the ambient temperature goes above this temperature in degrees
|
|
|
|
* Celsius.
|
|
|
|
* @temp_alert_min: the battery should issue an alert if the internal
|
|
|
|
* temperature goes below this temperature in degrees Celsius.
|
|
|
|
* @temp_alert_max: the battery should issue an alert if the internal
|
|
|
|
* temperature goes above this temperature in degrees Celsius.
|
|
|
|
* @temp_min: the battery will go outside of operating conditions when
|
|
|
|
* the internal temperature goes below this temperature in degrees Celsius.
|
|
|
|
* Normally this means the system should shut down.
|
|
|
|
* @temp_max: the battery will go outside of operating conditions when
|
|
|
|
* the internal temperature goes above this temperature in degrees Celsius.
|
|
|
|
* Normally this means the system should shut down.
|
|
|
|
* @ocv_table: for each entry in ocv_temp there is a corresponding entry in
|
|
|
|
* ocv_table and a size for each entry in ocv_table_size. These arrays
|
|
|
|
* determine the capacity in percent in relation to the voltage in microvolts
|
|
|
|
* at the indexed temperature.
|
|
|
|
* @ocv_table_size: for each entry in ocv_temp this array is giving the size of
|
|
|
|
* each entry in the array of capacity arrays in ocv_table.
|
|
|
|
* @resist_table: this is a table that correlates a battery temperature to the
|
|
|
|
* expected internal resistance at this temperature. The resistance is given
|
|
|
|
* as a percentage of factory_internal_resistance_uohm. Knowing the
|
|
|
|
* resistance of the battery is usually necessary for calculating the open
|
|
|
|
* circuit voltage (OCV) that is then used with the ocv_table to calculate
|
|
|
|
* the capacity of the battery. The resist_table must be ordered descending
|
|
|
|
* by temperature: highest temperature with lowest resistance first, lowest
|
|
|
|
* temperature with highest resistance last.
|
|
|
|
* @resist_table_size: the number of items in the resist_table.
|
2022-02-26 02:27:58 +03:00
|
|
|
* @vbat2ri_discharging: this is a table that correlates Battery voltage (VBAT)
|
|
|
|
* to internal resistance (Ri). The resistance is given in microohm for the
|
|
|
|
* corresponding voltage in microvolts. The internal resistance is used to
|
|
|
|
* determine the open circuit voltage so that we can determine the capacity
|
|
|
|
* of the battery. These voltages to resistance tables apply when the battery
|
|
|
|
* is discharging. The table must be ordered descending by voltage: highest
|
|
|
|
* voltage first.
|
|
|
|
* @vbat2ri_discharging_size: the number of items in the vbat2ri_discharging
|
|
|
|
* table.
|
|
|
|
* @vbat2ri_charging: same function as vbat2ri_discharging but for the state
|
|
|
|
* when the battery is charging. Being under charge changes the battery's
|
|
|
|
* internal resistance characteristics so a separate table is needed.*
|
|
|
|
* The table must be ordered descending by voltage: highest voltage first.
|
|
|
|
* @vbat2ri_charging_size: the number of items in the vbat2ri_charging
|
|
|
|
* table.
|
2022-02-26 02:27:57 +03:00
|
|
|
* @bti_resistance_ohm: The Battery Type Indicator (BIT) nominal resistance
|
|
|
|
* in ohms for this battery, if an identification resistor is mounted
|
|
|
|
* between a third battery terminal and ground. This scheme is used by a lot
|
|
|
|
* of mobile device batteries.
|
|
|
|
* @bti_resistance_tolerance: The tolerance in percent of the BTI resistance,
|
|
|
|
* for example 10 for +/- 10%, if the bti_resistance is set to 7000 and the
|
|
|
|
* tolerance is 10% we will detect a proper battery if the BTI resistance
|
|
|
|
* is between 6300 and 7700 Ohm.
|
2021-11-17 01:44:28 +03:00
|
|
|
*
|
2017-06-07 21:37:51 +03:00
|
|
|
* This is the recommended struct to manage static battery parameters,
|
|
|
|
* populated by power_supply_get_battery_info(). Most platform drivers should
|
|
|
|
* use these for consistency.
|
2021-11-17 01:44:28 +03:00
|
|
|
*
|
2017-06-07 21:37:51 +03:00
|
|
|
* Its field names must correspond to elements in enum power_supply_property.
|
2022-02-26 02:27:58 +03:00
|
|
|
* The default field value is -EINVAL or NULL for pointers.
|
|
|
|
*
|
|
|
|
* CC/CV CHARGING:
|
2021-11-17 01:44:28 +03:00
|
|
|
*
|
|
|
|
* The charging parameters here assume a CC/CV charging scheme. This method
|
|
|
|
* is most common with Lithium Ion batteries (other methods are possible) and
|
|
|
|
* looks as follows:
|
|
|
|
*
|
|
|
|
* ^ Battery voltage
|
|
|
|
* | --- overvoltage_limit_uv
|
|
|
|
* |
|
|
|
|
* | ...................................................
|
|
|
|
* | .. constant_charge_voltage_max_uv
|
|
|
|
* | ..
|
|
|
|
* | .
|
|
|
|
* | .
|
|
|
|
* | .
|
|
|
|
* | .
|
|
|
|
* | .
|
|
|
|
* | .. precharge_voltage_max_uv
|
|
|
|
* | ..
|
|
|
|
* |. (trickle charging)
|
|
|
|
* +------------------------------------------------------------------> time
|
|
|
|
*
|
|
|
|
* ^ Current into the battery
|
|
|
|
* |
|
|
|
|
* | ............. constant_charge_current_max_ua
|
|
|
|
* | . .
|
|
|
|
* | . .
|
|
|
|
* | . .
|
|
|
|
* | . .
|
|
|
|
* | . ..
|
|
|
|
* | . ....
|
|
|
|
* | . .....
|
|
|
|
* | ... precharge_current_ua ....... charge_term_current_ua
|
|
|
|
* | . .
|
|
|
|
* | . .
|
|
|
|
* |.... tricklecharge_current_ua .
|
|
|
|
* | .
|
|
|
|
* +-----------------------------------------------------------------> time
|
|
|
|
*
|
|
|
|
* These diagrams are synchronized on time and the voltage and current
|
|
|
|
* follow each other.
|
|
|
|
*
|
|
|
|
* With CC/CV charging commence over time like this for an empty battery:
|
|
|
|
*
|
|
|
|
* 1. When the battery is completely empty it may need to be charged with
|
|
|
|
* an especially small current so that electrons just "trickle in",
|
|
|
|
* this is the tricklecharge_current_ua.
|
|
|
|
*
|
|
|
|
* 2. Next a small initial pre-charge current (precharge_current_ua)
|
|
|
|
* is applied if the voltage is below precharge_voltage_max_uv until we
|
|
|
|
* reach precharge_voltage_max_uv. CAUTION: in some texts this is referred
|
|
|
|
* to as "trickle charging" but the use in the Linux kernel is different
|
|
|
|
* see below!
|
|
|
|
*
|
|
|
|
* 3. Then the main charging current is applied, which is called the constant
|
|
|
|
* current (CC) phase. A current regulator is set up to allow
|
|
|
|
* constant_charge_current_max_ua of current to flow into the battery.
|
|
|
|
* The chemical reaction in the battery will make the voltage go up as
|
|
|
|
* charge goes into the battery. This current is applied until we reach
|
|
|
|
* the constant_charge_voltage_max_uv voltage.
|
|
|
|
*
|
|
|
|
* 4. At this voltage we switch over to the constant voltage (CV) phase. This
|
|
|
|
* means we allow current to go into the battery, but we keep the voltage
|
|
|
|
* fixed. This current will continue to charge the battery while keeping
|
|
|
|
* the voltage the same. A chemical reaction in the battery goes on
|
|
|
|
* storing energy without affecting the voltage. Over time the current
|
|
|
|
* will slowly drop and when we reach charge_term_current_ua we will
|
|
|
|
* end the constant voltage phase.
|
|
|
|
*
|
|
|
|
* After this the battery is fully charged, and if we do not support maintenance
|
|
|
|
* charging, the charging will not restart until power dissipation makes the
|
|
|
|
* voltage fall so that we reach charge_restart_voltage_uv and at this point
|
|
|
|
* we restart charging at the appropriate phase, usually this will be inside
|
|
|
|
* the CV phase.
|
|
|
|
*
|
|
|
|
* If we support maintenance charging the voltage is however kept high after
|
|
|
|
* the CV phase with a very low current. This is meant to let the same charge
|
|
|
|
* go in for usage while the charger is still connected, mainly for
|
|
|
|
* dissipation for the power consuming entity while connected to the
|
|
|
|
* charger.
|
|
|
|
*
|
|
|
|
* All charging MUST terminate if the overvoltage_limit_uv is ever reached.
|
|
|
|
* Overcharging Lithium Ion cells can be DANGEROUS and lead to fire or
|
|
|
|
* explosions.
|
|
|
|
*
|
2022-02-26 02:27:58 +03:00
|
|
|
* DETERMINING BATTERY CAPACITY:
|
|
|
|
*
|
|
|
|
* Several members of the struct deal with trying to determine the remaining
|
|
|
|
* capacity in the battery, usually as a percentage of charge. In practice
|
|
|
|
* many chargers uses a so-called fuel gauge or coloumb counter that measure
|
|
|
|
* how much charge goes into the battery and how much goes out (+/- leak
|
|
|
|
* consumption). This does not help if we do not know how much capacity the
|
|
|
|
* battery has to begin with, such as when it is first used or was taken out
|
|
|
|
* and charged in a separate charger. Therefore many capacity algorithms use
|
|
|
|
* the open circuit voltage with a look-up table to determine the rough
|
|
|
|
* capacity of the battery. The open circuit voltage can be conceptualized
|
|
|
|
* with an ideal voltage source (V) in series with an internal resistance (Ri)
|
|
|
|
* like this:
|
|
|
|
*
|
|
|
|
* +-------> IBAT >----------------+
|
|
|
|
* | ^ |
|
|
|
|
* [ ] Ri | |
|
|
|
|
* | | VBAT |
|
|
|
|
* o <---------- | |
|
|
|
|
* +| ^ | [ ] Rload
|
|
|
|
* .---. | | |
|
|
|
|
* | V | | OCV | |
|
|
|
|
* '---' | | |
|
|
|
|
* | | | |
|
|
|
|
* GND +-------------------------------+
|
|
|
|
*
|
|
|
|
* If we disconnect the load (here simplified as a fixed resistance Rload)
|
|
|
|
* and measure VBAT with a infinite impedance voltage meter we will get
|
|
|
|
* VBAT = OCV and this assumption is sometimes made even under load, assuming
|
|
|
|
* Rload is insignificant. However this will be of dubious quality because the
|
|
|
|
* load is rarely that small and Ri is strongly nonlinear depending on
|
|
|
|
* temperature and how much capacity is left in the battery due to the
|
|
|
|
* chemistry involved.
|
|
|
|
*
|
|
|
|
* In many practical applications we cannot just disconnect the battery from
|
|
|
|
* the load, so instead we often try to measure the instantaneous IBAT (the
|
|
|
|
* current out from the battery), estimate the Ri and thus calculate the
|
|
|
|
* voltage drop over Ri and compensate like this:
|
|
|
|
*
|
|
|
|
* OCV = VBAT - (IBAT * Ri)
|
|
|
|
*
|
|
|
|
* The tables vbat2ri_discharging and vbat2ri_charging are used to determine
|
|
|
|
* (by interpolation) the Ri from the VBAT under load. These curves are highly
|
|
|
|
* nonlinear and may need many datapoints but can be found in datasheets for
|
|
|
|
* some batteries. This gives the compensated open circuit voltage (OCV) for
|
|
|
|
* the battery even under load. Using this method will also compensate for
|
|
|
|
* temperature changes in the environment: this will also make the internal
|
|
|
|
* resistance change, and it will affect the VBAT under load, so correlating
|
|
|
|
* VBAT to Ri takes both remaining capacity and temperature into consideration.
|
|
|
|
*
|
|
|
|
* Alternatively a manufacturer can specify how the capacity of the battery
|
|
|
|
* is dependent on the battery temperature which is the main factor affecting
|
|
|
|
* Ri. As we know all checmical reactions are faster when it is warm and slower
|
|
|
|
* when it is cold. You can put in 1500mAh and only get 800mAh out before the
|
|
|
|
* voltage drops too low for example. This effect is also highly nonlinear and
|
|
|
|
* the purpose of the table resist_table: this will take a temperature and
|
|
|
|
* tell us how big percentage of Ri the specified temperature correlates to.
|
|
|
|
* Usually we have 100% of the factory_internal_resistance_uohm at 25 degrees
|
|
|
|
* Celsius.
|
|
|
|
*
|
2021-11-17 01:44:28 +03:00
|
|
|
* The power supply class itself doesn't use this struct as of now.
|
2017-06-07 21:37:51 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
struct power_supply_battery_info {
|
2021-11-17 01:44:28 +03:00
|
|
|
unsigned int technology;
|
|
|
|
int energy_full_design_uwh;
|
|
|
|
int charge_full_design_uah;
|
|
|
|
int voltage_min_design_uv;
|
|
|
|
int voltage_max_design_uv;
|
|
|
|
int tricklecharge_current_ua;
|
|
|
|
int precharge_current_ua;
|
|
|
|
int precharge_voltage_max_uv;
|
|
|
|
int charge_term_current_ua;
|
|
|
|
int charge_restart_voltage_uv;
|
|
|
|
int overvoltage_limit_uv;
|
|
|
|
int constant_charge_current_max_ua;
|
|
|
|
int constant_charge_voltage_max_uv;
|
2022-02-26 02:27:55 +03:00
|
|
|
struct power_supply_maintenance_charge_table *maintenance_charge;
|
|
|
|
int maintenance_charge_size;
|
2022-02-26 02:27:56 +03:00
|
|
|
int alert_low_temp_charge_current_ua;
|
|
|
|
int alert_low_temp_charge_voltage_uv;
|
|
|
|
int alert_high_temp_charge_current_ua;
|
|
|
|
int alert_high_temp_charge_voltage_uv;
|
2021-11-17 01:44:28 +03:00
|
|
|
int factory_internal_resistance_uohm;
|
2022-02-26 02:27:58 +03:00
|
|
|
int factory_internal_resistance_charging_uohm;
|
2021-11-17 01:44:28 +03:00
|
|
|
int ocv_temp[POWER_SUPPLY_OCV_TEMP_MAX];
|
|
|
|
int temp_ambient_alert_min;
|
|
|
|
int temp_ambient_alert_max;
|
|
|
|
int temp_alert_min;
|
|
|
|
int temp_alert_max;
|
|
|
|
int temp_min;
|
|
|
|
int temp_max;
|
2018-11-05 10:39:09 +03:00
|
|
|
struct power_supply_battery_ocv_table *ocv_table[POWER_SUPPLY_OCV_TEMP_MAX];
|
|
|
|
int ocv_table_size[POWER_SUPPLY_OCV_TEMP_MAX];
|
2019-12-09 06:56:22 +03:00
|
|
|
struct power_supply_resistance_temp_table *resist_table;
|
|
|
|
int resist_table_size;
|
2022-02-26 02:27:58 +03:00
|
|
|
struct power_supply_vbat_ri_table *vbat2ri_discharging;
|
|
|
|
int vbat2ri_discharging_size;
|
|
|
|
struct power_supply_vbat_ri_table *vbat2ri_charging;
|
|
|
|
int vbat2ri_charging_size;
|
2022-02-26 02:27:57 +03:00
|
|
|
int bti_resistance_ohm;
|
|
|
|
int bti_resistance_tolerance;
|
2017-06-07 21:37:51 +03:00
|
|
|
};
|
|
|
|
|
2013-11-19 14:18:03 +04:00
|
|
|
extern struct atomic_notifier_head power_supply_notifier;
|
|
|
|
extern int power_supply_reg_notifier(struct notifier_block *nb);
|
|
|
|
extern void power_supply_unreg_notifier(struct notifier_block *nb);
|
2021-03-08 16:31:46 +03:00
|
|
|
#if IS_ENABLED(CONFIG_POWER_SUPPLY)
|
2013-02-01 23:40:17 +04:00
|
|
|
extern struct power_supply *power_supply_get_by_name(const char *name);
|
2015-03-12 10:44:12 +03:00
|
|
|
extern void power_supply_put(struct power_supply *psy);
|
2021-03-08 16:31:46 +03:00
|
|
|
#else
|
|
|
|
static inline void power_supply_put(struct power_supply *psy) {}
|
|
|
|
static inline struct power_supply *power_supply_get_by_name(const char *name)
|
|
|
|
{ return NULL; }
|
|
|
|
#endif
|
2013-11-24 20:49:29 +04:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
extern struct power_supply *power_supply_get_by_phandle(struct device_node *np,
|
|
|
|
const char *property);
|
2015-06-10 00:37:56 +03:00
|
|
|
extern struct power_supply *devm_power_supply_get_by_phandle(
|
|
|
|
struct device *dev, const char *property);
|
2013-11-24 20:49:29 +04:00
|
|
|
#else /* !CONFIG_OF */
|
|
|
|
static inline struct power_supply *
|
|
|
|
power_supply_get_by_phandle(struct device_node *np, const char *property)
|
|
|
|
{ return NULL; }
|
2015-06-10 00:37:56 +03:00
|
|
|
static inline struct power_supply *
|
|
|
|
devm_power_supply_get_by_phandle(struct device *dev, const char *property)
|
|
|
|
{ return NULL; }
|
2013-11-24 20:49:29 +04:00
|
|
|
#endif /* CONFIG_OF */
|
2017-06-07 21:37:51 +03:00
|
|
|
|
|
|
|
extern int power_supply_get_battery_info(struct power_supply *psy,
|
2021-12-15 04:01:18 +03:00
|
|
|
struct power_supply_battery_info **info_out);
|
2018-11-05 10:39:09 +03:00
|
|
|
extern void power_supply_put_battery_info(struct power_supply *psy,
|
|
|
|
struct power_supply_battery_info *info);
|
|
|
|
extern int power_supply_ocv2cap_simple(struct power_supply_battery_ocv_table *table,
|
|
|
|
int table_len, int ocv);
|
|
|
|
extern struct power_supply_battery_ocv_table *
|
|
|
|
power_supply_find_ocv2cap_table(struct power_supply_battery_info *info,
|
|
|
|
int temp, int *table_len);
|
|
|
|
extern int power_supply_batinfo_ocv2cap(struct power_supply_battery_info *info,
|
|
|
|
int ocv, int temp);
|
2019-12-09 06:56:22 +03:00
|
|
|
extern int
|
|
|
|
power_supply_temp2resist_simple(struct power_supply_resistance_temp_table *table,
|
|
|
|
int table_len, int temp);
|
2022-02-26 02:27:58 +03:00
|
|
|
extern int power_supply_vbat2ri(struct power_supply_battery_info *info,
|
|
|
|
int vbat_uv, bool charging);
|
2022-02-26 02:27:55 +03:00
|
|
|
extern struct power_supply_maintenance_charge_table *
|
|
|
|
power_supply_get_maintenance_charging_setting(struct power_supply_battery_info *info, int index);
|
2022-02-26 02:27:57 +03:00
|
|
|
extern bool power_supply_battery_bti_in_range(struct power_supply_battery_info *info,
|
|
|
|
int resistance);
|
2007-05-04 00:27:45 +04:00
|
|
|
extern void power_supply_changed(struct power_supply *psy);
|
|
|
|
extern int power_supply_am_i_supplied(struct power_supply *psy);
|
2022-02-01 16:06:47 +03:00
|
|
|
int power_supply_get_property_from_supplier(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val);
|
2009-07-23 22:35:53 +04:00
|
|
|
extern int power_supply_set_battery_charged(struct power_supply *psy);
|
2007-05-04 00:27:45 +04:00
|
|
|
|
2022-02-26 02:27:55 +03:00
|
|
|
static inline bool
|
|
|
|
power_supply_supports_maintenance_charging(struct power_supply_battery_info *info)
|
|
|
|
{
|
|
|
|
struct power_supply_maintenance_charge_table *mt;
|
|
|
|
|
|
|
|
mt = power_supply_get_maintenance_charging_setting(info, 0);
|
|
|
|
|
|
|
|
return (mt != NULL);
|
|
|
|
}
|
|
|
|
|
2022-02-26 02:27:58 +03:00
|
|
|
static inline bool
|
|
|
|
power_supply_supports_vbat2ri(struct power_supply_battery_info *info)
|
|
|
|
{
|
|
|
|
return ((info->vbat2ri_discharging != NULL) &&
|
|
|
|
info->vbat2ri_discharging_size > 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
power_supply_supports_temp2ri(struct power_supply_battery_info *info)
|
|
|
|
{
|
|
|
|
return ((info->resist_table != NULL) &&
|
|
|
|
info->resist_table_size > 0);
|
|
|
|
}
|
2022-02-26 02:27:57 +03:00
|
|
|
|
power_supply: Make the core a boolean instead of a tristate
On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote:
> > drivers/built-in.o: In function `.nouveau_pm_trigger':
> > (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
> >
> > nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
> > build with the latter is =m
>
> Ok, not that trivial...
>
> The problem is more like POWER_SUPPLY should be a bool, not a tristate.
>
> If you think about it: you don't want things like nouveau to depend on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs when not enabled, so that's
> really designed to not have depends...
>
> However that -cannot- work if POWER_SUPPLY is modular and the drivers
> who use it are not.
>
> The only fixes here that make sense I can think of
> that don't also involve Kconfig horrors are:
>
> - Ugly: in power_supply.h, use the extern variant if
>
> defined(CONFIG_POWER_SUPPLY) ||
> (defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))
>
> IE. use the stub if power supply is a module and what is being built is
> built-in. Of course that's not only ugly, it somewhat sucks from a user
> perspective as the subsystem now exists but can't be used by some
> drivers...
>
> - Better: Just make the bloody thing a bool :-) The power supply
> framework itself is small enough, just make it a boolean option and
> avoid the problem entirely. The actual power supply sub drivers can
> remain modular of course.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2012-05-05 08:06:19 +04:00
|
|
|
#ifdef CONFIG_POWER_SUPPLY
|
2008-08-27 00:09:59 +04:00
|
|
|
extern int power_supply_is_system_supplied(void);
|
|
|
|
#else
|
|
|
|
static inline int power_supply_is_system_supplied(void) { return -ENOSYS; }
|
|
|
|
#endif
|
|
|
|
|
2015-03-12 10:44:03 +03:00
|
|
|
extern int power_supply_get_property(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val);
|
2021-03-27 21:28:09 +03:00
|
|
|
#if IS_ENABLED(CONFIG_POWER_SUPPLY)
|
2015-03-12 10:44:03 +03:00
|
|
|
extern int power_supply_set_property(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
const union power_supply_propval *val);
|
2021-03-27 21:28:09 +03:00
|
|
|
#else
|
|
|
|
static inline int power_supply_set_property(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
const union power_supply_propval *val)
|
|
|
|
{ return 0; }
|
|
|
|
#endif
|
2015-03-12 10:44:03 +03:00
|
|
|
extern int power_supply_property_is_writeable(struct power_supply *psy,
|
|
|
|
enum power_supply_property psp);
|
|
|
|
extern void power_supply_external_power_changed(struct power_supply *psy);
|
2015-03-12 10:44:11 +03:00
|
|
|
|
|
|
|
extern struct power_supply *__must_check
|
|
|
|
power_supply_register(struct device *parent,
|
|
|
|
const struct power_supply_desc *desc,
|
2015-03-12 10:44:02 +03:00
|
|
|
const struct power_supply_config *cfg);
|
2015-03-12 10:44:11 +03:00
|
|
|
extern struct power_supply *__must_check
|
|
|
|
power_supply_register_no_ws(struct device *parent,
|
|
|
|
const struct power_supply_desc *desc,
|
2015-03-12 10:44:02 +03:00
|
|
|
const struct power_supply_config *cfg);
|
2015-03-12 10:44:11 +03:00
|
|
|
extern struct power_supply *__must_check
|
|
|
|
devm_power_supply_register(struct device *parent,
|
|
|
|
const struct power_supply_desc *desc,
|
2015-03-12 10:44:02 +03:00
|
|
|
const struct power_supply_config *cfg);
|
2015-03-12 10:44:11 +03:00
|
|
|
extern struct power_supply *__must_check
|
|
|
|
devm_power_supply_register_no_ws(struct device *parent,
|
|
|
|
const struct power_supply_desc *desc,
|
2015-03-12 10:44:02 +03:00
|
|
|
const struct power_supply_config *cfg);
|
2007-05-04 00:27:45 +04:00
|
|
|
extern void power_supply_unregister(struct power_supply *psy);
|
2011-12-07 21:15:45 +04:00
|
|
|
extern int power_supply_powers(struct power_supply *psy, struct device *dev);
|
2007-05-04 00:27:45 +04:00
|
|
|
|
2018-02-07 17:58:27 +03:00
|
|
|
#define to_power_supply(device) container_of(device, struct power_supply, dev)
|
|
|
|
|
2015-03-12 10:44:01 +03:00
|
|
|
extern void *power_supply_get_drvdata(struct power_supply *psy);
|
2007-05-04 00:27:45 +04:00
|
|
|
/* For APM emulation, think legacy userspace. */
|
|
|
|
extern struct class *power_supply_class;
|
|
|
|
|
2011-01-25 22:10:06 +03:00
|
|
|
static inline bool power_supply_is_amp_property(enum power_supply_property psp)
|
|
|
|
{
|
|
|
|
switch (psp) {
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_EMPTY:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_AVG:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
|
2017-06-07 21:37:52 +03:00
|
|
|
case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
|
2012-05-06 16:46:44 +04:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
|
2012-07-30 11:19:21 +04:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
|
2011-01-25 22:10:06 +03:00
|
|
|
case POWER_SUPPLY_PROP_CURRENT_MAX:
|
|
|
|
case POWER_SUPPLY_PROP_CURRENT_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_CURRENT_AVG:
|
2014-08-27 22:14:08 +04:00
|
|
|
case POWER_SUPPLY_PROP_CURRENT_BOOT:
|
2021-02-09 12:58:43 +03:00
|
|
|
return true;
|
2011-01-25 22:10:06 +03:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-02-09 12:58:43 +03:00
|
|
|
return false;
|
2011-01-25 22:10:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool power_supply_is_watt_property(enum power_supply_property psp)
|
|
|
|
{
|
|
|
|
switch (psp) {
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_EMPTY:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_AVG:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MAX:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MIN:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
|
2012-04-10 14:51:20 +04:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_OCV:
|
2014-08-27 22:14:08 +04:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_BOOT:
|
2012-05-06 16:46:44 +04:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
|
2012-07-30 11:19:21 +04:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
|
2011-03-01 03:55:31 +03:00
|
|
|
case POWER_SUPPLY_PROP_POWER_NOW:
|
2021-02-09 12:58:43 +03:00
|
|
|
return true;
|
2011-01-25 22:10:06 +03:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-02-09 12:58:43 +03:00
|
|
|
return false;
|
2011-01-25 22:10:06 +03:00
|
|
|
}
|
|
|
|
|
2019-06-12 11:44:04 +03:00
|
|
|
#ifdef CONFIG_POWER_SUPPLY_HWMON
|
|
|
|
int power_supply_add_hwmon_sysfs(struct power_supply *psy);
|
|
|
|
void power_supply_remove_hwmon_sysfs(struct power_supply *psy);
|
|
|
|
#else
|
|
|
|
static inline int power_supply_add_hwmon_sysfs(struct power_supply *psy)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline
|
|
|
|
void power_supply_remove_hwmon_sysfs(struct power_supply *psy) {}
|
|
|
|
#endif
|
|
|
|
|
2021-11-24 02:27:02 +03:00
|
|
|
#ifdef CONFIG_SYSFS
|
|
|
|
ssize_t power_supply_charge_behaviour_show(struct device *dev,
|
|
|
|
unsigned int available_behaviours,
|
|
|
|
enum power_supply_charge_behaviour behaviour,
|
|
|
|
char *buf);
|
|
|
|
|
|
|
|
int power_supply_charge_behaviour_parse(unsigned int available_behaviours, const char *buf);
|
2022-01-08 18:31:58 +03:00
|
|
|
#else
|
|
|
|
static inline
|
|
|
|
ssize_t power_supply_charge_behaviour_show(struct device *dev,
|
|
|
|
unsigned int available_behaviours,
|
|
|
|
enum power_supply_charge_behaviour behaviour,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int power_supply_charge_behaviour_parse(unsigned int available_behaviours,
|
|
|
|
const char *buf)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
2021-11-24 02:27:02 +03:00
|
|
|
#endif
|
|
|
|
|
2007-05-04 00:27:45 +04:00
|
|
|
#endif /* __LINUX_POWER_SUPPLY_H__ */
|