#
c06a65ac |
|
20-Jul-2023 |
Przemyslaw Chwiala <przemekchwiala@gmail.com> |
power: supply: max17042_battery: Do not use CONFIG_ prefix in regular C code Using CONFIG_ prefix for macros is not a good practice. Use CONFIG_ prefix in Kconfig only. Signed-off-by: Przemyslaw Chwiala <przemekchwiala@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20230720123102.154699-1-przemekchwiala@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
fe20b1dc |
|
17-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
power: supply: Switch i2c drivers back to use .probe() After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
1269774a |
|
15-Apr-2023 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Refactor max17042_external_power_changed() max17042_external_power_changed() is a wrapper around "power_supply_changed(psy);" and it has the same prototype. Remove it, replacing it with making the external_power_changed callback directly point to power_supply_changed. Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Cc: Purism Kernel Team <kernel@puri.sm> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
d9ac265b |
|
18-Nov-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
power: supply: max17042_battery: Convert to i2c's .probe_new() .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>
|
#
e5372503 |
|
18-Feb-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
power: supply: max17042_battery: Use devm_work_autocancel() 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>
|
#
e660dbb6 |
|
14-Sep-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Prevent int underflow in set_soc_threshold 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>
|
#
0cf48167 |
|
14-Sep-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Clear status bits in interrupt handler 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>
|
#
d0c27c92 |
|
29-Sep-2021 |
Henrik Grimler <henrik@grimler.se> |
power: supply: max17042_battery: fix typo in MAX17042_IAvg_empty 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>
|
#
223a3b82 |
|
29-Sep-2021 |
Henrik Grimler <henrik@grimler.se> |
power: supply: max17042_battery: use VFSOC for capacity when no rsns 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>
|
#
eaa2c490 |
|
16-Aug-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: log SOC threshold using debug log level 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>
|
#
4bf00434 |
|
16-Aug-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: more robust chip type checks 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>
|
#
ed0d0a05 |
|
16-Aug-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: fix typo in MAx17042_TOFF Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
1e4f30ea |
|
16-Aug-2021 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: clean up MAX17055_V_empty 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>
|
#
22b6907c |
|
16-Aug-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17042: remove duplicated STATUS bit defines 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>
|
#
54784ffa |
|
16-Aug-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17042: handle fails of reading status register 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>
|
#
4415e4ce |
|
27-Jul-2021 |
Nikita Travkin <nikita@trvn.ru> |
power: supply: max17042_battery: Add support for MAX77849 Fuel-Gauge 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>
|
#
7fbf6b73 |
|
26-May-2021 |
Krzysztof Kozlowski <krzk@kernel.org> |
power: supply: max17042: Do not enforce (incorrect) interrupt trigger type 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>
|
#
37ad56aa |
|
23-Mar-2021 |
Bhaskar Chowdhury <unixbhaskar@gmail.com> |
power: supply: max17042: Trivial spelling fixes Few trivial spelling fixes. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
5225371e |
|
24-Nov-2020 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Export charge termination current property 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>
|
#
6dcfa009 |
|
24-Nov-2020 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Take r_sns value into account in charge_counter 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>
|
#
9e39ef14 |
|
24-Nov-2020 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Improve accuracy of current_now and 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>
|
#
4b0a56e6 |
|
24-Nov-2020 |
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> |
power: supply: max17042_battery: Fix current_{avg,now} hiding with no 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>
|
#
21b01cc8 |
|
29-Mar-2020 |
Geordan Neukum <gneukum1@gmail.com> |
power: supply: max17042_battery: Add support for the TTE_NOW prop 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>
|
#
bc90705b |
|
14-Dec-2019 |
Angus Ainslie (Purism) <angus@akkea.ca> |
power: supply: max17042: add MAX17055 support 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>
|
#
40badfa3 |
|
21-Jul-2019 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
power: supply: max17042_battery: Fix a typo in function names 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>
|
#
dee2f3cf |
|
07-Jun-2019 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
power: supply: max17042_battery: simplify getting the adapter of a client 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>
|
#
bf592c56 |
|
15-Feb-2019 |
Sven Van Asbroeck <thesven73@gmail.com> |
max17042_battery: fix potential use-after-free on device remove 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>
|
#
7b38ebdf |
|
07-Aug-2018 |
Krzysztof Kozlowski <krzk@kernel.org> |
power: supply: maxim: Add SPDX license identifiers 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>
|
#
66ec32fc |
|
20-Feb-2018 |
Pierre Bourdon <delroth@google.com> |
max17042: propagate of_node to power supply device 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>
|
#
2d7e6a83 |
|
22-Jan-2018 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Always fall back to default platform-data 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>
|
#
6e5ab19d |
|
20-Jan-2018 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Check battery current for status when supplied 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>
|
#
4f1e0cb7 |
|
29-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Fix compiler warning 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>
|
#
a865a155 |
|
14-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Fix ACPI interrupt issues 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>
|
#
e2116202 |
|
14-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for ACPI enumeration 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>
|
#
adb69a3c |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the SCOPE property 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>
|
#
6d6b61ea |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the CHARGE_NOW property 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>
|
#
2e015412 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the CHARGE_FULL_DESIGN property 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>
|
#
d7d15fc6 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: mAh readings depend on r_sns value 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>
|
#
7bfc9397 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the VOLT_MIN property 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>
|
#
ef7fcdae |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the TECHNOLOGY attribute 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>
|
#
dcdddda8 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add external_power_changed callback 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>
|
#
a9df22c0 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add support for the STATUS property 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>
|
#
91736213 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Add default platform_data fallback data 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>
|
#
2814913c |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17047_battery: The temp alert values are 8-bit 2's complement 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>
|
#
c67c0693 |
|
14-Apr-2017 |
Hans de Goede <hdegoede@redhat.com> |
power: supply: max17042_battery: Use sign_extend32 instead of DIY code 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>
|
#
8c0984e5 |
|
17-Jun-2016 |
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>
|