Add driver for Microchip UCS1002 Programmable USB Port Power
Controller with Charger Emulation. The driver exposed a power supply
device to control/monitor various parameter of the device as well as a
regulator to allow controlling VBUS line.
Signed-off-by: NEnric Balletbo Serra <enric.balletbo@collabora.com>
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
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: NSebastian Reichel <sebastian.reichel@collabora.com>

Add bindings for Microchip UCS1002 Programmable USB Port Power
Controller with Charger Emulation.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NRob Herring <robh+dt@kernel.org>
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: NSebastian Reichel <sebastian.reichel@collabora.com>

Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow
singalling overcurrent condition via power supply health information.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: NGuenter 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: NSebastian Reichel <sebastian.reichel@collabora.com>

The increment operator of  pointer in be32_to_cpu() is not explicitly.
It made the warning from clang:

drivers/power/supply/power_supply_core.c:674:36: error: multiple
unsequenced modifications to 'list' [-Werror,-Wunsequenced]
drivers/power/supply/power_supply_core.c:675:41: error: multiple
unsequenced modifications to 'list' [-Werror,-Wunsequenced]

Link: https://github.com/ClangBuiltLinux/linux/issues/460Signed-off-by: NPhong Tran <tranmanphong@gmail.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties
don't have documentation. I add that documentation here.

v5 changes:
- Split this commit out from the previous two commits.
Signed-off-by: NNick Crews <ncrews@chromium.org>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

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: NNick Crews <ncrews@chromium.org>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

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: NNick Crews <ncrews@chromium.org>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The ACEPC T8 and T11 Cherry Trail Z8350 mini PCs use an AXP288 and as PCs,
rather then portables, they does not have a battery. Still for some
reason the AXP288 not only thinks there is a battery, it actually
thinks it is discharging while the PC is running, slowly going to
0% full, causing userspace to shutdown the system due to the battery
being critically low after a while.

This commit adds the ACEPC T8 and T11 to the axp288 fuel-gauge driver
blacklist, so that we stop reporting bogus battery readings on this device.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

User-space might be interested in receiving uevents when the charging
starts/stops or if conditions of battery changes (e.g.
over-temperature).  Notify about changes in battery also when the flags
change, not only SoC.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

This immutable branch contains the changes required for OLPC
1.75 battery, which touches x86 and power-supply and is based
on v5.1-rc1.
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The power framework gained ability to register groups of sysfs
attributes in commit cef8fe6a ("power: supply: core: add support for
custom sysfs attributes").
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Suggested-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The battery and the protocol are essentially the same as OLPC XO 1.5,
but the responses from the EC are LSB first.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

This wouldn't work on the DT-based ARM platform. Let's read the EC version
directly from the EC driver instead.

This removes x86 specific bits that would prevent this driver from being
used with the EC of ARM-based OLPC XO 1.75.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

This simplifies the error handling.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The global variables for private data are not too nice. I'd like some
more, and that would clutter the global name space even further.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Avoid using the x86 OLPC platform specific call to get the board
version. That wouldn't work on FDT-based ARM MMP2 platform.

Add the XO 1.5 compatible string too. This is actually not completely
necessary as the battery nodes on XO 1.5 claim to be compatible with
"olpc,xo1-battery", but there are, in fact, differencies.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature. We need to use a different compatible string for the
XO-1.5 battery.

Previously olpc_dt_fixup() used the presence of the battery node's
compatible property to decide whether the DT is up to date. Now we need
to look for a particular value in the compatible string, to decide
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

This makes the following patch more concise.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

It was pointed out in a review, and checkpatch.pl complains about this.
Breaking it down into multiple ofw evaluations works just as well and
reads better.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Add a driver for battery present on Ingenic JZ47xx SoCs.
Signed-off-by: NArtur Rojek <contact@artur-rojek.eu>
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Add documentation for the ingenic-battery driver, used on JZ47xx SoCs.
Signed-off-by: NArtur Rojek <contact@artur-rojek.eu>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Merge immutable branch containing the IIO changes required
for the new Ingenic JZ47xx battery fuel gauge driver.
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This adds support for AXP813 PMIC. It is almost the same as AXP22X but
has a different current limit.
Signed-off-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

To prepare for a new PMIC, factor out the code responsible of returning
the maximum current to axp20x_get_current_max.
Signed-off-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin
is high, either due to the PMIC driving it high or as an input, the VBUS
detection related interrupt mechanisms are disabled.

Previously this was worked around in the phy-sun4i-usb driver, which
needed to sense VBUS changes and report them to the musb driver in a
timely matter. However this workaround was only for the A31 and A33 type
USB PHYs. To support newer platforms we would have to enable it for
almost all the post-A31 SoCs.

However, since this is actually the result of the PMIC's behavior, the
workaround would be better if done in the PMIC driver, in this case the
VBUS power supply driver.

Add the same workqueue-based polling to the VBUS power supply driver.
The polling interval is chosen to be the debounce interval from the USB
PHY driver, as this short interval is needed in some cases, but the
power supply driver would not know when.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The VBUS current limit value macros have VBUS typed as VBUC, while
the bitmask macro is named correctly. Fix it.

Fixes: 69fb4dca ("power: Add an axp20x-usb-power driver")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

This adds the "x-powers,axp813-usb-power-supply" to the list of
compatibles for AXP20X VBUS power supply driver.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
./drivers/power/supply/power_supply_core.c:601:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:604:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:632:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:635:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:653:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:664:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
./drivers/power/supply/power_supply_core.c:673:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 595, but without a corresponding object release within this function.
Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

492 int ab8500_bm_of_probe(struct device *dev,
493                        struct device_node *np,
494                        struct abx500_bm_data *bm)
495 {
496         const struct batres_vs_temp *tmp_batres_tbl;
497         struct device_node *battery_node;
    ...
501         /* get phandle to 'battery-info' node */
502         battery_node = of_parse_phandle(np, "battery", 0);
    ...
509         if (!btech) {
510                 dev_warn(dev, "missing property battery-name/type\n");
511                 return -EINVAL;    ---> leaked here
512         }
    ...
540         of_node_put(battery_node);   ---> released here
541
542         return 0;
543 }

Detected by coccinelle with the following warnings:
./drivers/power/supply/ab8500_bmdata.c:511:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 502, but without a corresponding object release within this function.
Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

With loadable modules we may get the following during init:

could not initialize VBUS or ID IIO: -517

Let's not print any pointless error messages for deferred probe.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

With loadable modules we may get the following during init:

could not initialize VBUS or ID IIO: -517

Let's not print any pointless error messages for deferred probe.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

We should not use measured current value for average since we have proper
coulomb counter values available. Using measured current value should
be only used when the value is queried at a higher rate than the 250 ms
rate the coulomb counter is configured to run at.

Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The coulomb counter calibration is not CCO, it's CCM. And the CCM is
nine bits wide signed register, so let's use sign_extend32() for it.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

The accumulator sample register is signed 32-bits wide register on
droid 4. And only the earlier version of cpcap has a signed 24-bits
wide register. We're currently passing it around as unsigned, so
let's fix that and use sign_extend32() for the earlier revision.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

We need to check current instead of the charge counter to see if
a charger is connected. The charge counter shows the cumulated value
instead of the current charge current and can be negative or positive.

Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Merge fixes branch into next branch for cpcap-battery
patches.
Signed-off-by: NSebastian Reichel <sre@collabora.com>

Introduce optional support of POWER_SUPPLY_PROP_STATUS for chargers
which provide charging status GPIO.
Signed-off-by: NArtur Rojek <contact@artur-rojek.eu>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

Add documentation for the "charge-status-gpios" property.
Update the "gpios" property with a valid example.
Signed-off-by: NArtur Rojek <contact@artur-rojek.eu>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>

There is a spelling mistake in ps_get_cur_charge_cntl_limit function so
replace 'chrage' for 'charge'.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>