power: supply: ab8500: Standardize BTI resistance

The Battery Type Indicator (BTI) resistor is a resistor mounted
between a special terminal on the battery and ground. By sending
a fixed current (such as 7mA) through this resistor and measuring
the voltage over it, the resistance can be determined, and this
verifies the battery type.

Typical side view of the battery:

o o o
GND BTI +3.8V

Typical example of the electrical layout:

+3.8 V BTI
| |
| + |
_______ [ ] 7kOhm
___ |
| |
| |
GND GND

By verifying this resistance before attempting to charge the
battery we add an additional level of security.

In some systems this is used for plug-and-play of batteries with
different capacity. In other cases, this is merely used to verify
that the right type of battery is connected, if several batteries
have the same physical shape and can be plugged into the same
slot. Sometimes this is just a surplus security mechanism.

Nokia and Samsung among many other vendors are known to use these
BTI resistors.

Add the BTI properties to struct power_supply_battery_info and
switch the AB8500 charger code over to using it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize alert mode charging

The AB8500 code is using a special current and voltage setting
when the battery is in "alert mode", i.e. when it is starting
to go outside normal operating conditions so it is too
cold or too hot. This makes sense as a way for the charging
algorithm to deal with hostile environments.

Add the needed members to the struct power_supply_battery_info,
and switch the AB8500 charging code over to using this.

Reviewed-by: Matti Vaittineen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize maintenance charging

Maintenance charging is the phase of keeping up the charge
after the battery has charged fully using CC/CV charging.

This can be done in many successive phases and is usually
done with a slightly lower constant voltage than CV, and
a slightly lower allowed current.

Add an array of maintenance charging points each with a
current, voltage and safety timer, and add helper functions
to use these. Migrate the AB8500 code over.

This is used in several Samsung products using the AB8500
and these batteries and their complete parameters will
be added later as full examples, but the default battery
in the AB8500 code serves as a reasonable example so far.

Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Integrate thermal zone

Instead of providing our own homebrewn thermal measurement
code for an NTC and passing tables, we put the NTC thermistor
into the device tree, create a passive thermal zone, and poll
this thermal zone for the temperature.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Swap max and overvoltage

We should terminate charging when we reach the voltage_max_design_uv
not overvoltage_limit_uv, this is an abuse of that struct member.

The overvoltage limit is actually not configurable on the AB8500,
it is fixed to 4.75 V so drop a comment about that in the code.

Fixes: 2a5f41830aad ("power: supply: ab8500: Standardize voltages")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Drop BATCTRL thermal mode

The BATCTRL mode reads the temperature of the battery by
enabling a certain probing current (7-20 mA) and then measure
the voltage of the NTC mounted inside the battery.

None of the AB8500 product or the reference designs use this
mode. What we use is the so-called BATTEMP mode which enables
an internal 230 kOhm pull-up to 1.8 V to the external NTC on
pin BatTemp (N16) and then measures the voltage over the NTC
using the ADC:

1.8V (VTVOUT)
|
[ ] 230 kOhm
|
BatTemp +---------------- ADC
Pin N16 | _
|/
[/] NTC
_/|
|
GND

Cut out the BATCTRL code to clear the forest and stop
maintaining code we can never test.

The current inducing method is still used to probe for the
battery type using the internal BTI (battery type indicator)
on the BatCtrl (C3) pin in a separate code path.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply_core: Pass pointer to battery info

The function to retrieve battery info (from the device tree) assumes
we have a static info struct that gets populated by calling into
power_supply_get_battery_info().

This is awkward since I want to support tables of static battery
info by just assigning a pointer to all info based on e.g. a
compatible value in the device tree.

We also have a mixture of static and dynamically allocated
variables here.

Bite the bullet and let power_supply_get_battery_info() allocate
also the memory used for the very top level
struct power_supply_battery_info container. Pass pointers
around and lifecycle this with the psy device just like the
stuff we allocate inside it.

Change all current users over.

As part of the change, initializers need to be added to some
previously uninitialized fields in struct
power_supply_battery_info.

Reviewed-By: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize capacity lookup

The AB8500 charger only has one capacity table with
unspecified temperature, so we assume this capacity is given
for 20 degrees Celsius.

Convert this table to use the OCV (open circuit voltage)
tables in struct power_supply_battery_ocv_table.

In the process, convert the fuel gauge driver to use
microvolts and microamperes so we can use the same internals
as the power supply subsystem without having to multiply
and divide with 1000 in a few places.

Also convert high_curr_threshold and lowbat_threshold to
use microamperes and microvolts as these are closely
related to these changes.

Drop the unused overbat_threshold member in the custom
struct ab8500_fg_parameters.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize temp res lookup

The lookup from battery temperature to internal resistance was
using its own format. Rewrite this to use the table inside
struct power_supply_battery_info:s resist_table.

The supplied resistance table has to be rewritten to express
the resistance in percent of the factory resistance as a
side effect.

We can then rely on the library function
power_supply_temp2resist_simple() to interpolate the internal
resistance percent from the temperature.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize CV voltage

The voltage used in the constant voltage phase of the charging
exist in struct power_supply_battery_info as
constant_charge_voltage_max_uv.

Switch the custom property normal_vol_lvl to this and
consequentially change everything that relates to this value
over to using microvolts rather than millivolts so
we align internal representation of current with the
power core. Prefix every variable we change with *_uv
to indicate the unit everywhere but also to make sure
we do not miss any outlier.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize CC current

The current used in the constant current phase of the charging
exist in struct power_supply_battery_info as
constant_charge_current_max_ua.

Switch the custom property max_out_curr to this and
consequentally change everything that relates to this value
over to using microamperes rather than milliamperes so
we align internal representation of current with the
power core. Prefix every variable we change with *_ua
to indicate the unit everywhere but also to make sure
we do not miss any outlier.

Drop some duplicate unused defines in a header.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Make recharge capacity a constant

The recharge capacity is the hysteresis level for a charger to
restart when a battery does not support maintenance charging.

All products using the AB8500 have batteries supporting
maintenace charging and all code has always set this to 95%.

Turn it into a constant.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize termination current

The AB8500 custom termination current can be replaced by the
corresponding struct power_supply_battery_info field.

Remove the struct member and amend the code to use the
standard property.

Add *_ua suffix for clarity and to make sure we have
changed all code sites using this member.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize internal resistance

The nominal internal resistance isn't used by the AB8500
charging code, instead this resistance is measured continuously,
but we anyways migrate this to the standard property in
struct power_supply_battery_info.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize voltages

The nominal voltage in this charge driver corresponds to
both the voltage_min_design_uv and voltage_max_design_uv
of struct power_supply_battery_info so assign both if this
is undefined.

The overcharge max voltage (when the charger should cut off)
is migrated at the same time so we move both voltages to
struct power_supply_battery_info.

Adjust the code to deal directly with the microvolt values
instead of converting them to millivolts.

Add *_uv suffixes for clarity and to make sure we have
changed all code sites using this member.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize technology

The AB8500 custom battery type can be replaced by the
corresponding struct power_supply_battery_info field.

Remove the struct member and amend the code to use the
standard property.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize design capacity

Now that we know that we have only one battery type to
deal with we can proceed to transfer properties to
struct power_supply_battery_info.

The designed capacity for the battery was in a custom field
of the custom battery type in mAh, transfer this to the
standard charge_full_design_uah property in
struct power_supply_battery_info and augment the code
accordingly.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Use only one battery type

The code was going through hoops and loops to detect what
battery is connected and check the resistance for this battery
etc.

Skip this trouble: we will support one battery (currently
"unknown") then we will find the connected battery in the
device tree using a compatible string. The battery resistance
may be used to double-check that the right battery is
connected.

Convert the array of battery types into one battery type so
we can next move over the properties of this one type into
the standard struct power_supply_battery_info.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Drop unused battery types

The code tries to detect a lot of battery variants on the reference
designs, but we are not using the reference designs in practice, we
are using real products such as Samsung Phones.

The reference design with no battery plugged in will be detected as
a LIPO battery with a thermistor on the batctrl pin so we will
assume this and later on we can support other types through the
device tree if we want, just like the products do.

Drop the tables for external thermistor, only keep the internal
thermistor tables that we will use as default.

We can delete the assignment of the temperature to resistance table
since the default will be the only and correct option.

Also get rid of some unused variables and unused exports.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Standardize operating temperature

Instead of storing the temperature limits in our custom
struct struct ab8500_bm_data, make struct power_supply_battery_info
a member of this and store the min and max temperatures inside
that struct as the temp_min/temp_max and
temp_alert_min/temp_alert_max respectively.

The values can be assigned from the device tree, but if
not present will be set to the same defaults as are currently
in the code.

This way we start to move over to using
struct power_supply_battery_info and make it possible to move
the data over to the device tree and we will move piece by
piece toward using the standard info struct.

Temperature hysteresis is currently not supported by the
standard struct but we move the assignment here as well so
that we have all parameterization in one spot.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Sink current tables into charger code

The two tables for input and output current translation from
register values does not need to be passed around from the
battery manager data. Just push it down into the charger code
where it is used, like other tables in that code.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Use core battery parser

This deploys the core battery DT parser to read the basic properties
of the battery. We only use very little of it as we start out, but
we will improve as we go along.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500_bmdata: Use standard phandle

Look up the battery using the "monitored-battery" phandle
as is nowadays a standard DT binding. The actual bindings
for these charger elements are not upstream so let's sort
out this mess by conforming to the standard.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Drop some includes from bmdata

This file isn't using any AB8500 symbols so drop these includes.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Drop abx500 concept

Drop the entire idea with abx500 being abstract and different from ab8500
in the AB8500 charging drivers. This rids the two identical definitions
of a slew of structs in ab8500-bm.h and makes things less confusion and
easier to understand.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

mfd/power: ab8500: Push data to power supply code

The global definition of platform data for the battery
management code has no utility after the OF conversion,
move the <linux/mfd/abx500/ab8500-bm.h> to be a local
file in drivers/power/supply and stop defining the
platform data in drivers/power/supply/ab8500_bmdata.c
and broadcast to the kernel only to have it assigned
as platform data to the MFD cells and then picked back
into the same subsystem that defined it in the first
place. This kills off a layer of indirection.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

power: supply: ab8500: fix leaked of_node refs in ab8500_bm_of_probe

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: Wen Yang <wen.yang99@zte.com.cn>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: ab8500: Drop AB8540/9540 support

The AB8540 was an evolved version of the AB8500, but it was never
mass produced or put into products, only reference designs exist.
The upstream support was never completed and it is unlikely that
this will happen so drop the support for now to simplify
maintenance of the AB8500.

Cc: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

power: supply: ab8500: Replaced spaces with tabs in indent

This patch fixes 4 checkpatch.pl errors on lines 433 to 436:
ERROR: code indent should use tabs where possible

Signed-off-by: Munir Contractor <munircontractor@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>

power: move power supply drivers to power/supply

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>