Avoid inclusion of unused twl4030-madc.h. This
will allow twl4030-madc.h to be merged into the
iio driver.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The status reported directly by the battery controller is not always
reliable and should be corrected based on the current draw information.
This implements such a correction with a dedicated function, called
where the supply status is retrieved.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
A mechanism to ignore the first external power change notification was
put in place years ago to ignore the power_supply_register notification.
However, this doesn't apply to the current situation anymore, as the
first notification is always the result of a legitimate power change.
This removes this deprecated mechanism, which puts back the driver's
state machine to a sane state (an ignored first notification previously
caused a charging/discharging status inversion).
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Add support for the SCOPE property, always return SCOPE_SYSTEM,
as the max170xx is used for the main battery on all known systems
with a max170xx.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
At least upower prefers the more precise charge_now sysfs value over
capacity and the max17042 has the info, so lets export it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The info is there, lets export it as a property.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The PROP_CHARGE_FULL code was hardcoded for the default sense
resistor of 0.010 Ohm, make it use r_sns which contains the
actual sense resistor value in micro-Ohms instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The info is there, so lets export it, like we already do for VOLT_MAX.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The max17042 is intended for Li-Ion or Li-Po batteries, add a TECHNOLOGY
attribute to reflect this. Note this is hardcoded to Li-Ion as there is
no way to tell the difference, and Lithium-Ion Polymer batteries are
a sub-family of Lithium-Ion so Li-Ion technically is correct for both.
Using Li-Ion for both is already done by many drivers and is much
better then not providing any technology info at all.
Suggested-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
If our supplier changes status, chances are we've changed status too,
let any listeners know about this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Userspace prefers the driver having a status property over having to guess
itself. Specifically this will properly make the GNOME3 UI (and likely
others) properly show discharging / charging / full status, instead
of always showing discharging as status.
Note that in the case there is no charger driver supplying the max17042,
then a status of unknown will get returned. At least upower treats
this the same as not having a status attribute, so in this case nothing
changes from a userspace pov.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Some x86 machines use a max17047 fuel-gauge and x86 might be missing
platform_data if not provided by SFI.
This commit adds default platform_data as fallback option so that the
driver can work on boards where no platform_data is provided.
Since not all boards have a thermistor hooked up, set temp_min to 0 and
change the health checks from temp <= temp_min to temp < temp_min to
not trigger on such boards (where temp reads 0).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The temp alert values are 8-bit 2's complement, so sign-extend them
before reporting them back to the caller.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Use sign_extend32 to sign-extend variables where necessary instead of
DIY code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
trivial fix to spelling mistake in dev_error message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get
a link time error:
drivers/power/built-in.o: In function `axp20x_usb_power_get_property':
undefined reference to `iio_read_channel_processed'
drivers/power/built-in.o: In function `axp20x_usb_power_probe':
undefined reference to `devm_iio_channel_get'
undefined reference to `devm_iio_channel_get'
This adds the same dependency that we already have for the AC power driver
to the USB power driver. For consistency, I'm also moving the two closer
together in the Kconfig file.
Fixes: 33863c938c ("power: supply: axp20x_usb_power: use IIO channels when available")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Function devm_kzalloc() will return a NULL pointer. However, in function
isp1704_charger_probe(), the return value of devm_kzalloc() is directly
used without validation. This may result in a bad memory access bug.
Fixes: 34a109610e ("isp1704_charger: Add DT support")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Since we use the default primary handler for the irq, IRQF_ONESHOT must
be set. Otherwise the request fails and the following errors are
displayed:
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 129
sbs-battery 0-000b: Failed to request irq: -22
Signed-off-by: Ryosuke Saito <raitosyo@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the battery power supply driver to get various data from
the PMIC, such as the battery status (charging, discharging, full,
dead), current max limit, current current, battery capacity (in
percentage), voltage max and min limits, current voltage and battery
capacity (in Ah).
This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
provider.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The driver was registering two classes, bq24190-battery & -charger.
Because the power supply framework cannot surface features from multiple
drivers in a single class, a fuel gauge driver would create a third class,
which some power management utilities cannot see.
Deprecate the -battery class for future removal and replicate its features
in -charger. Set /sys/class...-charger/online = pg_stat && !batfet_disable.
If device_property "omit-battery-class" is set, don't register -battery.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
It is sensible to assume that the hardware actually always has a
way of charging the battery so when power_supply_am_i_supplied does not
find any suppliers, that does not mean that there are none, but simply
that no power_supply-drivers are registered / bound for any suppliers for
the supply calling power_supply_am_i_supplied.
At which point a fuel-gauge driver calling power_supply_am_i_supplied()
cannot determine whether the battery is being charged or not.
Allow a caller of power_supply_am_i_supplied to differentiate between
there not being any suppliers, vs no suppliers being online by returning
-ENODEV if there are no suppliers matching supplied_to / supplied_from,
which allows fuel-gauge drivers to return POWER_SUPPLY_STATUS_UNKNOWN
rather then POWER_SUPPLY_STATUS_DISCHARGING if there are no suppliers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
We can't assume that the battery is or stays present after probing
on devices with replaceable battery.
On some devices (e.g. GTA04 or OpenPanodra) it can be removed
and even be hot swapped by the user while device continues to operate
through external AC or USB power (as long as system power consumption
remains below ca. 500mA as provided by USB). Under certain conditions
it is possible to boot without battery.
So it makes no sense to check for this situation during probe and make
the charger driver (and its status reports) completely non-operational if
the battery can be inserted later.
Tested on: GTA04 and OpenPandora.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Currently, the twl4030 charger defines its own max_current by directly
creating sysfs nodes. It should use the input_current_limit property
which is e.g. used by the bq24257 driver.
This patch adds the input_current_property with the same semantics as
the max_current property. The code to manage the max_current property
is removed by a separate patch.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Allow platform-code to disable the reset on probe and suspend/resume
by setting a "disable-reset" boolean device property on the device.
There are several reasons why the platform-code may want to disable
the reset on probe and suspend/resume:
1) Resetting the charger should never be necessary it should always have
sane values programmed. If it is running with invalid values while we
are not running (system turned off or suspended) there is a big problem
as that may lead to overcharging the battery.
2) The reset in suspend() is meant to put the charger back into default
mode, but this is not necessary and not a good idea. If the charger has
been programmed with a higher max charge_current / charge_voltage then
putting it back in default-mode will reset those to the safe power-on
defaults, leading to slower charging, or charging to a lower voltage
(and thus not using the full capacity) while suspended which is
undesirable. Reprogramming the max charge_current / charge_voltage
after the reset will not help here as that will put the charger back
in host mode and start the i2c watchdog if the host then does not do
anything for 40s (iow if we're suspended for more then 40s) the watchdog
expires resetting the device to default-mode, including resetting all
the registers to there safe power-on defaults. So the only way to keep
using custom charge settings while suspending is to keep the charger in
its normal running state with the i2c watchdog disabled. This is fine
as the charger will still automatically switch from constant current
to constant voltage and stop charging when the battery is full.
3) Besides never being necessary resetting the charger also causes
problems on systems where the charge voltage limit is set higher then the
reset value, if this is the case and the charger is reset while charging
and the battery voltage is between the 2 voltages, then about half the
time the charger gets confused and claims to be charging (REG08 contains
0x64) but in reality the charger has decoupled itself from VBUS (Q1 off)
and is drawing 0A from VBUS, leaving the system running from the battery.
This last problem is happening on a GPD-win mini PC with a bq24292i
charger chip combined with a max17047 fuel-gauge and a LiHV battery.
I've checked and TI does not list any errata for the bq24292i which
could explain this (there are no errata at all).
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
On some devices with an axp288 pmic setting vbus path based on the
id-pin is handled by an ACPI _AIE interrupt on the gpio and the
INT3496 device is disabled.
Instead of returning -EPROBE_DEFER on these devices waiting for the
never to show up INT3496 device, check for its presence and only
request and monitor the matching extcon if the device is there,
otherwise let the firmware handle the vbus path control.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When I submitted the extcon handling I had a patch pending for the
extcon sub-system for extcon_register_notifier to take -1 as cable id
for listening for all type cable events on an extcon with a single
notifier.
In the end it was decided to instead add a new
extcon_register_notifier_all function for this, switch to using this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
On chip reset, polling loop used udelay(10) which is too short
to be useful. Instead, use usleep_range(100, 200).
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
On pm_runtime_get() failure, always emit an error message.
Prevent unbalanced pm_runtime_get by calling:
pm_runtime_put_noidle() in irq handler
pm_runtime_put_sync() on any probe() failure
Rename probe() out labels instead of renumbering them.
Fixes: 13d6fa8447fa ("power: bq24190_charger: Use PM runtime autosuspend")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Polishing and fixes for initial extcon patch.
Fixes: 4db249b6f3b4 ("power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boost")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the charger is unplugged before the battery is full we may
see an over/under voltage fault. Ignore this rather then emitting
a message or uevent.
This fixes messages like these getting logged on charger unplug + replug:
bq24190-charger 15-006b: Fault: boost 0, charge 1, battery 0, ntc 0
bq24190-charger 15-006b: Fault: boost 0, charge 0, battery 0, ntc 0
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This adds a new driver for the LEGO MINDSTORMS EV3 battery. The EV3 is
an embedded ARM device that can use 6 AA batteries or a special rechargeable
Li-ion battery pack. The rechargeable battery pack presses a special key
switch in the battery compartment to indicate that it is present.
The EV3 is only capable of monitoring battery voltage and current. The
charging circuit is built into the rechargeable battery pack and there is
no way to communicate with is, so we can't provide any information about
charging status.
When not using the rechargeable battery pack, it is most common to use
alkaline batteries to power the device, but it is also common for people to
use rechargeable NiMH batteries. Since there is not a way to automatically
differentiate between these, the technology property is made writable.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Equivalent information can be nowadays obtained using function tracer.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Some trivial improvements on the returning value of the
functions:
- remove unnecessary goto labels that just return, return
immediately, instead.
- do not initialize when not needed.
- return the value from the calling function that fails instead
of politically choosing -EINVAL.
Signed-off-by: Andi Shyti <andi@etezian.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
val might become 7 in which case stime[7] (array of length 7) would be
accessed during the scnprintf call later and that will cause issues.
Obviously, string concatenation is not intended here so just a comma needs
to be added to fix the issue.
Fixes: 98a2766493 ("power_supply: Add new lp8788 charger driver")
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a
USB battery charger. It can optionally also have a companion chip that
is used for wireless charging.
The charger on CPCAP also can feed VBUS for the USB host mode. This
can be handled by the existing kernel phy_companion interface.
Cc: devicetree@vger.kernel.org
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add support for monitoring an extcon device with USB SDP/CDP/DCP and HOST
cables and adjust ilimit and enable/disable the 5V boost converter
accordingly. This is necessary on systems where the PSEL pin is hardwired
high and ILIM needs to be set by software based on the detected charger
type, as well as on systems where the 5V boost converter is used, as
that always needs to be enabled from software.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The bq24192 and bq24192i are mostly identical to the bq24190, TI even
published a single datasheet for all 3 of them. The difference
between the bq24190 and bq24192[i] is the way charger-type detection
is done, the bq24190 is to be directly connected to the USB a/b lines,
where as the the bq24192[i] has a gpio which should be driven high/low
externally depending on the type of charger connected, from a register
level access pov there is no difference.
The differences between the bq24192 and bq24192i are:
1) Lower default charge rate on the bq24192i
2) Pre-charge-current can be max 640 mA on the bq24192i
On x86/ACPI systems the code which instantiates the i2c client may not
know the exact variant being used, so instead of coding the model-id
in the i2c_id struct and bailing if it does not match, check the reported
model-id matches one of the supported variants.
This commit only adds support for the bq24192i as I don't
have a bq24192 to test with, adding support for the bq24192 should
be as simple as also accepting its model-id in the model-id test.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The i2c-core already maps of irqs before calling the driver's probe
function and there are no in tree users of
bq24190_platform_data->gpio_int.
Remove the redundant custom irq-mapping code and just use client->irq.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Without CONFIG_PM, we get a harmless warning:
drivers/power/supply/bq24190_charger.c:1514:12: error: 'bq24190_runtime_resume' defined but not used [-Werror=unused-function]
drivers/power/supply/bq24190_charger.c:1501:12: error: 'bq24190_runtime_suspend' defined but not used [-Werror=unused-function]
To avoid the warning, we can mark all four PM functions as __maybe_unused,
which also lets us remove the incorrect #ifdef.
Fixes: 3d8090cba638 ("power: bq24190_charger: Check the interrupt status on resume")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
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>
Since index is always 0, replace gpiod_get_index() by gpiod_get().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
We can get quite a few interrupts when the battery is trickle charging.
Let's enable PM runtime autosuspend to avoid constantly toggling device
driver PM runtime state.
Let's use a 600 ms timeout as that's how long the USB chager detection
might take.
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Some SoCs like omap3 can configure GPIO irqs to use Linux generic
dedicated wakeirq support. If the dedicated wakeirq is configured,
the SoC will use a always-on interrupt controller to produce wake-up
events.
If bq24190 is configured for dedicated wakeirq, we need to check the
interrupt status on PM runtime resume. This is because the Linux
generic wakeirq will call pm_runtime_resume() on the device on a
wakeirq. And as the bq24190 interrupt is falling edge sensitive
and only active for 250 us, there will be no device interrupt seen
by the runtime SoC IRQ controller.
Note that this can cause spurious interrupts on omap3 devices with
bq24190 connected to gpio banks 2 - 5 as there's a glitch on those
pins waking from off mode as listed in "Advisory 1.45". Devices
with this issue should not configure the optional wakeirq interrupt
in the dts file.
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The X-Powers AXP20X and AXP22X PMICs expose the status of AC power
supply.
Moreover, the AXP20X can also expose the current current and voltage
values of the AC power supply.
This adds the driver which exposes the status of the AC power supply of
the AXP20X and AXP22X PMICs.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[removed unused elements from struct axp20x_ac_power]
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The X-Powers AXP20X PMIC exposes the current current and voltage
measures via an internal ADC.
This adds the possibility to read IIO channels directly for processed
values rather than reading the registers and computing the value.
For backward compatibility purpose, if the IIO driver is not compiled,
this driver will fall back on previous behaviour which is direct
register readings.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the driver is built as a module, I2C module alias information is not
filled so the module won't be autoloaded. Export the I2C and OF devices
ID to the module by using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/power/supply/max14656_charger_detector.ko | grep alias
$
After this patch:
$ modinfo drivers/power/supply/max14656_charger_detector.ko | grep alias
alias: i2c:max14656
alias: of:N*T*Cmaxim,max14656C*
alias: of:N*T*Cmaxim,max14656
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
acpi_match_device can potentially return NULL, so it is prudent to
check if acpi_id is null before it is dereferenced. Add a check
and an error message to indicate the failure.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reading both fault and status registers and logging any fault should
take priority over handling status register update.
Fix by moving the status handling to later in interrupt routine.
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Caching the fault register after a single I2C read may not keep an accurate
value.
Fix by doing two reads in irq_handle_thread() and using the cached value
elsewhere. If a safety timer fault later clears itself, we apparently don't get
an interrupt (INT), however other interrupts would refresh the register cache.
From the data sheet: "When a fault occurs, the charger device sends out INT
and keeps the fault state in REG09 until the host reads the fault register.
Before the host reads REG09 and all the faults are cleared, the charger
device would not send any INT upon new faults. In order to read the
current fault status, the host has to read REG09 two times consecutively.
The 1st reads fault register status from the last read [1] and the 2nd reads
the current fault register status."
[1] presumably a typo; should be "last fault"
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
We wrongly get uevents for bq24190-charger and bq24190-battery on every
register change.
Fix by checking the association with charger and battery before
emitting uevent(s).
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The device specific data is not fully initialized on
request_threaded_irq(). This may cause a crash when the IRQ handler
tries to reference them.
Fix the issue by installing IRQ handler at the end of the probe.
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
pm_resume() does a register_reset() which clears charger host mode.
Fix by calling set_mode_host() after the reset.
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The interrupt signal is TRIGGER_FALLING. This is is specified in the
data sheet PIN FUNCTIONS: "The INT pin sends active low, 256us
pulse to host to report charger device status and fault."
Also the direction can be seen in the data sheet Figure 37 "BQ24190
with D+/D- Detection and USB On-The-Go (OTG)" which shows a 10k
pull-up resistor installed for the sample configurations.
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The added regulator dependency in the smbb driver causes build errors
when regulators are disabled, e.g. in randconfig build testing:
drivers/power/supply/qcom_smbb.o: In function `smbb_chg_otg_is_enabled':
qcom_smbb.c:(.text.smbb_chg_otg_is_enabled+0x18): undefined reference to `rdev_get_drvdata'
drivers/power/supply/qcom_smbb.o: In function `smbb_charger_probe':
qcom_smbb.c:(.text.smbb_charger_probe+0x410): undefined reference to `devm_regulator_register'
This adds a Kconfig dependency to avoid the link error.
Fixes: 61274eff0d ("power: supply: qcom_smbb: Add otg regulator for control of vbus")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
drivers/power/supply/max14656_charger_detector.c:317:3-8:
No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Alexander Kurz <akurz@blala.de>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Simplify return logic to avoid unnecessary variable assignments.
These issues were detected using Coccinelle and the following semantic patch:
@@
local idexpression ret;
expression e;
@@
-ret =
+return
e;
-return ret;
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Simplify return logic to avoid unnecessary variable assignments.
These issues were detected using Coccinelle and the following semantic patch:
@@
local idexpression ret;
expression e;
@@
-ret =
+return
e;
-return ret;
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The MAX14656 USB charger detector, also known as "AL32" is used to detect
the presence and capabilities of attached USB chargers. The device is
attached via I2C plus one interrupt line to signalize events.
The device can be found in LG smartphones like LS665 and LS770, compatible
devices are present in 4th/5th generation Amazon Kindle readers referenced
in source code packages as "Maxim AL32".
The initial version of this driver has been extracted from LG source code
package LGLS665_Android_Lollipop_LS665ZV3, enriched with information from
the Kindle_src_4.1.3 source code package and adapted to the current power
class sysfs interface. Non-Standard Apple chargers which the device may
detect are mapped to the USB Battery Charging Specification Revision 1.2
class USB_DCP.
Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add a regulator to control the OTG chargepath switch. This
is used by USB code to control VBUS direction - out for host mode
on the OTG port, and in for charging mode.
Signed-off-by: Tim Bird <tim.bird@sonymobile.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
[stephen.boyd@linaro.org: Fix supply name, constify ops, drop
machine.h and of_regulator.h includes]
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27520G4 chip definition to specifically match the
bq27520-G4 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27520G3 chip definition to specifically match the
bq27520-G3 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27520G2 chip definition to specifically match the
bq27520-G2 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27520G1 chip definition to specifically match the
bq27520-G1 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27510G3 chip definition to specifically match the
bq27510-G3 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Tested-by: Chris Lapa <chris@lapa.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27510G2 chip definition to specifically match the
bq27510-G2 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27510G1 chip definition to specifically match the
bq27510-G1 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This commit adds the BQ27500 chip definition to specifically match the
bq27500/1 functionality as described in the datasheet.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The BQ2751X definition exists only to satisfy backwards compatibility.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The BQ2750X definition exists only to satisfy backwards compatibility.
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Casting of_device_get_match_data return value to int causes warning on 64bit
architectures.
../drivers/power/supply/axp20x_usb_power.c: In function
'axp20x_usb_power_probe':
../drivers/power/supply/axp20x_usb_power.c:297:21: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
Fixes: 0dcc70ca86 ("power: supply: axp20x_usb_power: use of_device_id
data field instead of device_is_compatible")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This is done for readability as the upcoming commits will add a lot of
cases.
tested: no
Signed-off-by: Chris Lapa <chris@lapa.com.au>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The Moorestown support was removed by commit 1a8359e411 ("x86/mid: Remove
Intel Moorestown").
Remove this leftover.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The GPIO charger is using a mix of the legacy GPIO interface
and <linux/of_gpio.h> which is not the modern way to use GPIOs.
Refactor like this:
- Use a GPIO descriptor for the GPIO line used to monitor the
charger.
- Fetch the descriptor with devm_gpiod_get() as the first
method.
- If this fails and we are *not* using device tree, then
start looking to see if we can use platform data instead.
- After looking up and requesting a GPIO number with the
legacy API, convert it to a descriptor.
This way we can later isolate and drop the legacy code as
more platforms move over to using descriptors.
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
trivial fix to spelling mistake in comments in the headers
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
pdata is being null checked twice, the 2nd check is redundant code
and can be removed.
Fixes CoverityScan CID 1392340 "Logically dead code"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Setting the irq_enable bits is taken care of by the irq chip when we
request the irqs and the driver should not be meddling with the
irq?_en registers itself.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If there is no ti,ac-detect-gpios configured, it is normal to
have failed reads of the options register. So, hold back on the
log spamming.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
It is possible to verify AC adapter presence via a register read, without
any physical connection to the ACOK pin on the charger. Allow this.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Prior to this commit the code was using 1 notifier_block for all
types of charger cable, this is incorrect as the notifier_block
becomes part of a linked-list and now the same notifier_block
is part of 3 linked lists.
This commit fixes this by using a separate nb per extcon cable.
Note this happened to work fine sofar because axp288_charger was the only
listener, so when added to each of the 3 notifier chains, the next pointer
in the nb would be set to 0, so we've 3 heads pointing to the same nb,
with its next pointing to NULL. But as soon as we mix in a second extcon
consumer things will go boom.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add a MODULE_DEVICE_TABLE to fix the module not auto-loading.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Setting the irq_enable bits is taken care of by the irq chip when we
request the irqs and the driver should not be meddling with the
irq?_en registers itself.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
To set a bit to 1 one needs to pass the mask for the bit to set
as second argument into regmap_update_bits, not "1".
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Do not wait for an extcon notification before processing the cable
states, instead queue the otg / cable work on probe to make sure we
immediately process the initial hardware state.
Note this also requiree moving the getting of the USB_HOST cable state
from the extcon notifier to the workqueue function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Remove info->health, info->present and info->online caching, as no code
is reading the cached values.
Remove if (changed) check before calling power_supply_changed(), we
return early from axp288_charger_extcon_evt_worker if nothing has
changed, so the check is not needed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Deal with the charger type changing without a vbus-disconnect being
reported in between the 2 charger type states:
-Do not return from axp288_charger_extcon_evt_worker early in this case
(track old_chg_type)
-Make calling axp288_charger_enable_charger with the same value as before
a nop, to avoid the need for the caller to check this
-Do no do a dev_err when axp288_charger_enable_charger returns an error,
axp288_charger_enable_charger already returns an error itself
-Disable the charger before changing the charge-current setting (nop if
vbus was seen as disconnected before the change)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Nothing was setting info->otg.cable, so the extcon_get_cable_state_
calls on it would always return -EINVAL.
This commit fixes this by actually setting info->otg.cable using the new
extcon_get_extcon_dev_by_cable_id function.
This commit also makes failing to register the extcon notifier for the
USB_HOST cable an error rather then a warning, because we MUST have this
notfier to properly disable the VBUS path when in host mode so that we're
not drawing current from the 5V boost converter which is supplying power
to the otg port when in host mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Move the charger_init_hw_regs() above the power_supply_register call,
the axp288_charger_usb_set_property() uses axp288_chrg_info.max_cv and
.max_cc which get set by charger_init_hw_regs().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The extcon notifier work calls power_supply_changed on the power_supply
we register, so the extcon notifiers should be registered after we
register the power_supply.
While touching this code anyways, refactor the code for the 3 cable types
into a loop to avoid code repetition.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use devm_power_supply_register instead of power_supply_register,
this avoids the need to do manual cleanup and results in quite
a nice code cleanup.
Note it may seem excessive to add a "struct device *dev" helper local
variable for the 1 time it is used in this patch, but future patches
in this series also use it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This adds support for sbs-charger compilant chips as defined here:
http://sbs-forum.org/specs/sbc110.pdf
This was tested on a arm board connected to an LTC4100 battery charger
chip.
Signed-off-by: Nicolas Saenz Julienne <nicolas.saenz@prodys.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
So what if there is a status_gpio specified? bq24735_charger_is_present()
do have a working fallback for the case of no status_gpio.
Simplify this by not special casing setups w/o status_gpio, folding
two consecutive if-blocks in the process.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
During probe, it makes no sense to take care to first not issue any
i2c commands to verify if the connected part really is a bq24735, to
later simply fail the probe in the next step when trying to configure
the charger. So, delay configuration of the charging parameters until
the charger is accessible (i.e. when the AC adapter is present) as
part of enabling the charging.
This also fixes the rather serious issue that the charging parameters
are lost when the AC adapter is disconnected.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
bq24735_enable_charging() needs to call bq24735_config_charging(),
which is something to change later, this is just a preparatory patch.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
"tps65217-charger" is more appropriate name because the driver supports
not only AC but also USB charger.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Replace 'ac' of tps65217_charger structure with 'psy'.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This driver supports AC and USB chargers. Generic name is preferred.
Replace 'ac_online' with 'online'.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
TPS65217 has two charger interrupts - AC and USB power status change.
Interrupt number in the TPS65217 driver data:
IRQ number is only used on requesting the interrupt, so no need to keep
it inside the driver data.
Interrupt handler:
Check not only AC but also USB charger status.
In both cases, enable charging operation.
Interrupt request:
If an interrupt number is invalid, then use legacy polling thread.
Otherwise, create IRQ threads to handle AC and USB charger event.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use the task_struct variable for running polling thread. If polling task
is activated, then use it to stop running thread.
This is a preceding step of supporting two interrupts of TPS65217 charger,
so checking single IRQ number is not appropriate when the module is removed.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use managed resource function devm_power_supply_register instead of
power_supply_register to simplify the error path by allowing unregistering
to happen automatically on error and remove.
Removing max8997_battery_remove function also as it is now redundant.
Also removing out of memory printk message after kzalloc as there is
already enough information on failure.
Signed-off-by: Srikant Ritolia <s.ritolia@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The X-Powers AXP223 shares most of its behaviour with the AXP221 PMIC
but allows the VBUS power supply max current to be set to 100mA (like
the AXP209 PMIC).
This basically adds a new compatible to the VBUS power supply driver and
adds a check on the compatible when setting current max limit.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
AXP20X and AXP22X PMICs allow setting the min voltage and max current of
VBUS power supply. This adds entries in sysfs to allow to do so.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This replaces calls to of_device_is_compatible to check data field of
of_device_id matched when probing the driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the ac-detect gpio does not support interrupts, provide a fallback
to poll the gpio at a configurable interval.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In order for the MSB -> LSB latching to work correctly we must read the
2 8 bit registers of a 12 bit value in one consecutive read.
This fixes voltage_ocv reporting inconsistent values on my tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In order for the MSB -> LSB latching to work correctly we must read the
2 8 bit registers of a 15 bit value in one consecutive read.
This fixes charge_full reporting 3498768 on some reads and 3354624 one
other reads on my tablet (for the 3354624 value the raw LSB is 0x00).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If reading the register fails, return the actual error code, instead
of the uninitialized val variable;
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
When the axp288_faul_gauge driver was originally merged, it was
merged with a dependency on some other driver providing platform
data for it.
However the battery-data-framework which should provide that data
never got merged, resulting in x86 tablets / laptops with an axp288
having no working battery monitor, as before this commit the driver
would simply return -ENODEV if there is no platform data.
This commit removes the dependency on the platform_data instead
checking that the firmware has initialized the fuel-gauge and
reading the info back from the pmic.
What is missing from the read-back info is the table to map raw adc
values to temperature, so this commit drops the temperature and
temperature limits properties. The min voltage, charge design and
model name info is also missing. Note that none of these are really
important for userspace to have.
All other functionality is preserved and actually made available
by this commit.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=88471
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
When the axp288_charger driver was originally merged, it was merged with
a dependency on some other driver providing platform data for it.
However the battery-data-framework which should provide that data never
got merged, so the axp288_charger as merged upstream has never worked,
its probe method simply always returns -ENODEV.
This commit removes the dependency on the platform_data instead reading
back the charging current and charging voltage that the firmware has set
and using those values as the maximum values the user may set.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Make charger_init_hw_regs propagate i2c errors, instead of only warning
about them and then ignoring them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
As the power supply framework provides a way to store and retrieve
private supply data, use it.
In the process, change the platform data for wm97xx_battery from a
container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use DEVICE_ATTR_RO for read only attributes. This simplifies the source
code, improves readbility, and reduces the chance of inconsistencies.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@ro@
declarer name DEVICE_ATTR;
identifier x,x_show;
@@
DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL);
@script:ocaml@
x << ro.x;
x_show << ro.x_show;
@@
if not (x^"_show" = x_show) then Coccilib.include_match false
@@
declarer name DEVICE_ATTR_RO;
identifier ro.x,ro.x_show;
@@
- DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL);
+ DEVICE_ATTR_RO(x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The alias for the ipaq_micro_battery driver is incorrect, fix it so the
module can be auto-loaded.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The BQ27510 and BQ27520 use a slightly different register map than the
BQ27500, add a new type enum and add these gauges to it.
Fixes: d74534c277 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices")
Based-on-patch-by: Kenneth R. Crudup <kenny@panix.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
There's a typo, it should do pm_runtime_get_sync, not put.
Fixes: d7bf353fd0 ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Cc: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
We checked that "pdata->chg_params" is non-NULL earlier in this function
so when we add "i" to it, it's still non-NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/power/supply/axp288_fuel_gauge.ko | grep alias
$
After this patch:
$ modinfo drivers/power/supply/axp288_fuel_gauge.ko | grep alias
alias: platform:axp288_fuel_gauge
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/power/supply/max8997_charger.ko | grep alias
$
After this patch:
$ modinfo drivers/power/supply/max8997_charger.ko | grep alias
alias: platform:max8997-battery
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
According to the datasheet, MAX17040 has six 16-bit registers.
Register reads and writes are only valid if all 16 bits are transferred.
Any write command that is terminated early is ignored.
So it's better to change register transacton length from 8 bits to 16 bits.
Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
To avoid canceling the delayed workqueue needlessly, and scheduling an
immediate polling. Check if the new poll_interval value is different
than the previous setting.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In drivers/power/supply/ab8500_fg.c, fix two typos and adjust the function
name in two cases to correspond to the names of the defined functions.
In drivers/power/supply/power_supply_core.c, change two variable names to
the names of the corresponding parameters.
Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Fix issue with poll_interval being not updated till the previous
interval expired.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Liam Breck <liam@networkimprov.net>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
There where still a few lingering references to pdata after commit
power: supply: sbs-battery: simplify DT parsing.
Remove pdata from struct·sbs_info and conditional checks to ser if this
was set from the i2c read / write functions.
Instead of call max in each function for incrementing poll_retry_count
do it once in the probe function.
Fixup null pointer dereference in to pdata in sbs_external_power_changed.
Change retry counts to u32 to avoid need for max.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
According to the Smart Battery Data Specification, the use
of ManufacturerAcess (register 0x0) is implementation-defined.
It appears that some batteries use writes to this register
in order to implement certain functionality, but others may
simply NAK all writes to it. As a result, write failures to
ManufacturerAccess should not be used as an indicator of
battery presence, nor as a failure to enter sleep mode.
The failed write access was seen with SANYO AP13J3K.
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
bq->charger is initialized in bq24257_power_supply_init.
Therefore, bq24257_power_supply_init should be called before the
registration of the IRQ handler bq24257_irq_handler_thread that calls
power_supply_changed(bq->charger).
Signed-off-by: Georges Savoundararadj <savoundg@gmail.com>
Cc: Aurelien Chanot <chanot.a@gmail.com>
Cc: Andreas Dannenberg <dannenberg@ti.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Fixes: 2219a93596 ("power_supply: Add TI BQ24257 charger driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
After the change to use the gpio descriptor interface, we get a warning if
-Wmaybe-uninitialized is added back to the build flags (it is currently
disabled:
drivers/power/supply/sbs-battery.c: In function 'sbs_probe':
drivers/power/supply/sbs-battery.c:760:28: error: 'pdata' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The problem is that if neither the DT properties nor a platform_data
pointer are provided, the chip->pdata pointer gets set to an uninitialized
value.
Looking at the code some more, I found that the sbs_of_populate_pdata
function is more complex than necessary and has confusing calling
conventions of possibly returning a valid pointer, a NULL pointer
or an ERR_PTR pointer (in addition to the uninitialized pointer).
To fix all of that, this gets rid of the chip->pdata pointer and
simply moves the two integers into the sbs_info structure. This
makes it much clearer from reading sbs_probe() what the precedence
of the three possible values are (pdata, DT, hardcoded defaults)
and completely avoids the #ifdef CONFIG_OF guards as
of_property_read_u32() gets replaced with a compile-time stub
when that is disabled, and returns an error if passed a NULL of_node
pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 3b5dd3a494 ("power: supply: sbs-battery: Use gpio_desc and sleeping calls for battery detect")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This requests the status GPIO with initial input setup. It is required
to read the GPIO status at probe time and thus correctly avoid sending
I2C messages when AC is not plugged.
When requesting the GPIO without initial input setup, it always reads 0
which causes probe to fail as it assumes the charger is connected, sends
I2C messages and fails.
While at it, this switches the driver over to gpiod API.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Switch to using new gpio_desc interface and devm gpio get calls to
automatically manage gpio resource. Use gpiod_get_value which handles
active high / low calls.
If gpio_detect is set then force loading of the driver as it is
reasonable to assume that the battery may not be present.
Update the is_present flag immediately in the IRQ.
Remove legacy gpio specification from platform data.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add the power supply's current max property,
POWER_SUPPLY_PROP_CURRENT_MAX.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add the power supply capacity level property, it corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.
It also utilizes the precision voltage detector function module
to catch the low battery voltage.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The power supply type property is varying as the external power
supply changes. It is not a constant.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add the charger status change interrupt support, it will report
the power supply changed event.
This interrupt is generated by one of the conditions as below:
- the state machine jumps out of or into the EOC state
- the CHGIN input voltage goes out of or into the valid range.
- the battery temperature goes out of or into the valid range.
- the PRECHARGE time-out occurs.
- the total charge time-out occurs.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
When get the property, first check the charger state machine,
then check the status bit to decide what value is assigned to
the corresponding property.
Retain the SUSCHG bit of REG 0x71 when configure the timers to
avoid losting the charger suspending info after boot.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Remove "battery_temperature" member, it is redundant, it is the
hardware's responsibility to handle TH pin properly.
It is unnecessary to use the dt property to check if there is
a battery temperature monitor or not.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Since the act8945a_charger is regarded as a sub-device, all properties will
be assigned to its own device node. All properties can be achieved from its
own node, instead of from its parent device.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
When the charger is missing (disconnected), it is safe to assume that
the charger chip is no charging.
This is especially relevant when a status GPIO is present and the
charger is getting disconnected. bq24735_charger_is_charging will be
triggered due to the interrupt then, it will attempt to read whether it
is charging through i2c, which will fail as the charger is disconnected.
This also fixes that specific issue.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Change my email address to kernel.org instead of Samsung one for the
purpose of any future contact. The copyrights remain untouched and are
attributed to Samsung.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
