summaryrefslogtreecommitdiff
path: root/drivers/power/supply/max17042_battery.c
AgeCommit message (Collapse)Author
2022-11-20power: supply: max17042_battery: Convert to i2c's .probe_new()Uwe Kleine-König
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2022-02-24power: supply: max17042_battery: Use devm_work_autocancel()Christophe JAILLET
Use devm_work_autocancel() instead of hand-writing it. This saves a few lines of code. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-10-12power: supply: max17042_battery: Prevent int underflow in set_soc_thresholdSebastian Krzyszkowiak
max17042_set_soc_threshold gets called with offset set to 1, which means that minimum threshold value would underflow once SOC got down to 0, causing invalid alerts from the gauge. Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-10-12power: supply: max17042_battery: Clear status bits in interrupt handlerSebastian Krzyszkowiak
The gauge requires us to clear the status bits manually for some alerts to be properly dismissed. Previously the IRQ was configured to react only on falling edge, which wasn't technically correct (the ALRT line is active low), but it had a happy side-effect of preventing interrupt storms on uncleared alerts from happening. Fixes: 7fbf6b731bca ("power: supply: max17042: Do not enforce (incorrect) interrupt trigger type") Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-10-02power: supply: max17042_battery: fix typo in MAX17042_IAvg_emptyHenrik Grimler
Datasheet gives the name IAvg_empty, not LAvg_empty. Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-10-02power: supply: max17042_battery: use VFSOC for capacity when no rsnsHenrik Grimler
On Galaxy S3 (i9300/i9305), which has the max17047 fuel gauge and no current sense resistor (rsns), the RepSOC register does not provide an accurate state of charge value. The reported value is wrong, and does not change over time. VFSOC however, which uses the voltage fuel gauge to determine the state of charge, always shows an accurate value. For devices without current sense, VFSOC is already used for the soc-alert (0x0003 is written to MiscCFG register), so with this change the source of the alert and the PROP_CAPACITY value match. Fixes: 359ab9f5b154 ("power_supply: Add MAX17042 Fuel Gauge Driver") Cc: <stable@vger.kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Suggested-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-17power: supply: max17042_battery: log SOC threshold using debug log levelSebastian Krzyszkowiak
There's no need to print a message on every change in battery percentage on regular log levels. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-17power: supply: max17042_battery: more robust chip type checksSebastian Krzyszkowiak
Prepared by checking the datasheets of max17042, max17047/50 and max170455 for differences in register maps. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-17power: supply: max17042_battery: fix typo in MAx17042_TOFFSebastian Krzyszkowiak
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-17power: supply: max17042_battery: clean up MAX17055_V_emptySebastian Krzyszkowiak
This register is same as in MAX17047 and MAX17050, so there's no need for custom casing it. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-16power: supply: max17042: remove duplicated STATUS bit definesKrzysztof Kozlowski
All bits of STATUS register are already defined (see STATUS_SMN_BIT and further) so there is no need to define status SoC threshold min/max values one more time. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-16power: supply: max17042: handle fails of reading status registerKrzysztof Kozlowski
Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-06power: supply: max17042_battery: Add support for MAX77849 Fuel-GaugeNikita Travkin
MAX77849 is a combined fuel-gauge, charger and MUIC IC. Notably, fuel-gauge has dedicated i2c lines and seems to be fully compatible with max17047. Add new compatible for it reusing max17047 code paths. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-06-04power: supply: max17042: Do not enforce (incorrect) interrupt trigger typeKrzysztof Kozlowski
Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 17047/77693 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. The interrupt line is shared between PMIC and RTC driver, so using level sensitive interrupt is here especially important to avoid races. With an edge configuration in case if first PMIC signals interrupt followed shortly after by the RTC, the interrupt might not be yet cleared/acked thus the second one would not be noticed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-03-23power: supply: max17042: Trivial spelling fixesBhaskar Chowdhury
Few trivial spelling fixes. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-11-30power: supply: max17042_battery: Export charge termination current propertySebastian Krzyszkowiak
The value is there, so let's export it. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-11-30power: supply: max17042_battery: Take r_sns value into account in charge_counterSebastian Krzyszkowiak
The default r_sns value was hardcoded there, so let's change it to the actually configured one. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-11-30power: supply: max17042_battery: Improve accuracy of current_now and ↵Sebastian Krzyszkowiak
current_avg readings Dividing 1562500 by r_sns value usually doesn't result in an integer. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-11-30power: supply: max17042_battery: Fix current_{avg,now} hiding with no ↵Sebastian Krzyszkowiak
current sense When current sense is disabled, max17042_no_current_sense_psy_desc gets used which ignores two last properties from the list. Fixes: 21b01cc879cc ("power: supply: max17042_battery: Add support for the TTE_NOW prop") Reported-by: Timon Baetz <timon.baetz@protonmail.com> Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-04-29power: supply: max17042_battery: Add support for the TTE_NOW propGeordan Neukum
The max170{42,47,50,55} family of fuel gauges all provide time-to-empty estimation. As such, let's export this as a property. Signed-off-by: Geordan Neukum <gneukum1@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-12-19power: supply: max17042: add MAX17055 supportAngus Ainslie (Purism)
The MAX17055 is very similar to the MAX17042 so extend the driver. Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: max17042_battery: Fix a typo in function namesChristophe JAILLET
It is likely that 'max10742_[un]lock_model()' functions should be 'max17042_[un]lock_model()' (0 and 7 switched in 10742) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-06-23power: supply: max17042_battery: simplify getting the adapter of a clientWolfram Sang
We have a dedicated pointer for that, so use it. Much easier to read and less computation involved. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-02-20max17042_battery: fix potential use-after-free on device removeSven Van Asbroeck
The work which is scheduled on a POR boot is potentially left pending or running until after the device module is removed, which could result in a use-after-free. Fix by registering a cancel/sync callback, which gets executed as part of standard resource unwinding. This issue was detected with the help of Coccinelle. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-08-30power: supply: maxim: Add SPDX license identifiersKrzysztof Kozlowski
Replace GPL v2.0 and v2.0+ license statements with SPDX license identifiers. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-03-12max17042: propagate of_node to power supply devicePierre Bourdon
max17042_get_status uses the core power_supply_am_i_supplied. That function relies on DT properties to figure out the power supply topology, and will error out without DT. Fixes max17042 battery status being reported as "unknown". Signed-off-by: Pierre Bourdon <delroth@google.com> Signed-off-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-23power: supply: max17042_battery: Always fall back to default platform-dataHans de Goede
It is possible to have CONFIG_OF enabled on x86 builds, where we have no firmware provided max17042_platform_data. The CONFIG_OF implementation of max17042_get_pdata would return NULL in this case, causing the probe to fail. Instead always fallback to the default platform-data, as used on x86 sofar, when there is no firmware provided pdata, independent of CONFIG_OF. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-22power: supply: max17042_battery: Check battery current for status when suppliedHans de Goede
Even though the system is supplied, it may still be discharging if the supply is e.g. only delivering 5V 0.5A. Check the avg battery current if available for more accurate status reporting. Cc: James <kernel@madingley.org> Suggested-by: James <kernel@madingley.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-08-29power: supply: max17042_battery: Fix compiler warningHans de Goede
Fix drivers/power/supply/max17042_battery.c:1059:6: warning: 'acpi_id' may be used uninitialized in this function. No idea why my gcc version did not catch this. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-08-28power: supply: max17042_battery: Fix ACPI interrupt issuesHans de Goede
On some x86/ACPI boards the DSDT defines an ACPI event handler for the max17047 IRQ, this causes several problems: 1) We need to share the IRQ to avoid an error getting it 2) Even of we are willing to share, we may fail to share because some DSDTs claim it exclusivly 3) If we are unable to share the IRQ, or the IRQ is only listed as an ACPI event source and not in the max1704 firmware node, then the charge threshold IRQ (which is used to give an IRQ every 1 percent charge change) becomes a problem, the ACPI event handler will not update this to the next 1 percent threshold, so the IRQ keeps firing and we get an IRQ storm pegging 1 CPU core. This happens despite the max17042 driver not setting the charge threshold because Windows uses it and leaves it set on reboot. So if we are unable to get the IRQ we need to reprogram the charge threshold to its disabled setting. This commit fixes al of the above, while at it it also makes the error msg when being unable to get the IRQ consistent with other messages. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-08-28power: supply: max17042_battery: Add support for ACPI enumerationHans de Goede
Some x86 devices enumerate a max17047 fuel-gauge through a MAX17047 ACPI firmware-node, add support for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-05-01power: supply: max17042_battery: Add support for the SCOPE propertyHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add support for the CHARGE_NOW propertyHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add support for the CHARGE_FULL_DESIGN propertyHans de Goede
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>
2017-05-01power: supply: max17042_battery: mAh readings depend on r_sns valueHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add support for the VOLT_MIN propertyHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add support for the TECHNOLOGY attributeHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add external_power_changed callbackHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add support for the STATUS propertyHans de Goede
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>
2017-05-01power: supply: max17042_battery: Add default platform_data fallback dataHans de Goede
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>
2017-05-01power: supply: max17047_battery: The temp alert values are 8-bit 2's complementHans de Goede
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>
2017-05-01power: supply: max17042_battery: Use sign_extend32 instead of DIY codeHans de Goede
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>
2016-08-16Merge tag 'for-v4.8-rc' into psy-nextSebastian Reichel
Power Supply Fixes for 4.8 cycle
2016-08-11power: move power supply drivers to power/supplySebastian Reichel
This moves all power supply drivers from drivers/power/ to drivers/power/supply/. The intention is a cleaner source tree, since drivers/power/ also contains frameworks unrelated to power supply, like adaptive voltage scaling. Signed-off-by: Sebastian Reichel <sre@kernel.org>
generated by cgit (git 2.34.1) at 2025-04-26 15:25:06 +0000