#
814755c4 |
|
31-Jul-2023 |
Svyatoslav Ryhel <clamor95@gmail.com> |
power: max17040: get thermal data from adc if available Since fuel gauge does not support thermal monitoring, some vendors may couple this fuel gauge with thermal/adc sensor to monitor battery cell exact temperature. Add this feature by adding optional iio thermal channel. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Iskren Chernev <me@iskren.info> Link: https://lore.kernel.org/r/20230731073613.10394-4-clamor95@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
f4b782af |
|
31-Jul-2023 |
Svyatoslav Ryhel <clamor95@gmail.com> |
power: max17040: pass status property from supplier Optionally pass status property from supplier if has support for it. If cell is online assume it is present as well. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Iskren Chernev <me@iskren.info> Link: https://lore.kernel.org/r/20230731073613.10394-3-clamor95@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
2ce8284c |
|
18-Jul-2023 |
Rob Herring <robh@kernel.org> |
power: Explicitly include correct DT includes The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> 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>
|
#
a07fca69 |
|
18-Nov-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
power: supply: max17040: 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> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
1d422ecf |
|
08-Oct-2021 |
Yang Yingliang <yangyingliang@huawei.com> |
power: supply: max17040: fix null-ptr-deref in max17040_probe() Add check the return value of devm_regmap_init_i2c(), otherwise later access may cause null-ptr-deref as follows: KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367] RIP: 0010:regmap_read+0x33/0x170 Call Trace: max17040_probe+0x61b/0xff0 [max17040_battery] ? write_comp_data+0x2a/0x90 ? max17040_set_property+0x1d0/0x1d0 [max17040_battery] ? tracer_hardirqs_on+0x33/0x520 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? _raw_spin_unlock_irqrestore+0x4b/0x60 ? trace_hardirqs_on+0x63/0x2d0 ? write_comp_data+0x2a/0x90 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? max17040_set_property+0x1d0/0x1d0 [max17040_battery] i2c_device_probe+0xa31/0xbe0 Fixes: 6455a8a84bdf ("power: supply: max17040: Use regmap i2c") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
cd70c85c |
|
06-May-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17040: drop unused platform data support There are no platforms using the driver with platform data (no board files with the driver), so the dead code can be dropped. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
ce0ae832 |
|
06-May-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17040: simplify POWER_SUPPLY_PROP_ONLINE The driver was reporting POWER_SUPPLY_PROP_ONLINE via platform data functions or '1' if no platform data was provided. Since there are no platforms using the driver with platform data (no board files with the driver), the online property can be simplified to always return '1'. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
c603bec3 |
|
06-May-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17040: remove non-working POWER_SUPPLY_PROP_STATUS The driver was reporting POWER_SUPPLY_PROP_STATUS via platform data functions. Without platform data, the max17040_get_status() functions returns early with POWER_SUPPLY_STATUS_UNKNOWN. Since there are no platforms using the driver with platform data (no board files with the driver), the status property was always unknown. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
8bb2314f |
|
26-May-2021 |
Krzysztof Kozlowski <krzk@kernel.org> |
power: supply: max17040: 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 14577/77836 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Iskren Chernev <iskren.chernev@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
6dfbb2ce |
|
19-Apr-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17040: remove unneeded double cast There is no need for double explicit cast from of_device_get_match_data() (uintptr_t and then to target enum) because implicit conversion from uintptr_t to enum is straightforward (uintptr_t is a integer type). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
a837f35c |
|
19-Apr-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
power: supply: max17040: handle device_property_read_u8_array() failure The device_property_read_u8_array() call should not fail because it is preceded with device_property_count_u8() and check for number of readable u8 values. However the code is more obvious and easier to read if the return value of device_property_read_u8_array() is checked. Otherwise reader needs to investigate whether really there is no risk of using random stack values of 'rcomp' variable. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
7f977e64 |
|
05-Oct-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Fix ptr to enum cast clang complains about casting pointers to smaller enum types. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
ee2d433c |
|
22-Sep-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Support soc alert max17048 and max17049 support SOC alerts (interrupts when battery capacity changes by +/- 1%). At the moment the driver polls for changes every second. Using the alerts removes the need for polling. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Tested-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
1779c6e3 |
|
22-Sep-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Support setting rcomp The Maxim ModelGauge family supports fine-tuning by setting a compensation value (named rcomp in the docs). The value is affected by battery chemistry and ambient temperature. Add support for reading maxim,rcomp from DT and configuring the device with the supplied value. Temperature adjustment is not implemented at the moment, because there is no provision for receiving the ambient temperature at the moment. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Tested-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
4f7f8e87 |
|
22-Sep-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Support compatible devices The max17040 fuel gauge is part of a family of 8 chips that have very similar mode of operations and registers. This change adds: - compatible strings for all supported devices and handling for the minor differences between them; - handling for devices reporting double capacity via maxim,double-soc; The datasheets of the supported devices are linked [0] [1] [2] [3]. [0] https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf [1] https://datasheets.maximintegrated.com/en/ds/MAX17043-MAX17044.pdf [2] https://datasheets.maximintegrated.com/en/ds/MAX17048-MAX17049.pdf [3] https://datasheets.maximintegrated.com/en/ds/MAX17058-MAX17059.pdf Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Tested-by: Jonathan Bakker <xc-racer2@live.ca> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
6455a8a8 |
|
22-Sep-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Use regmap i2c Rewrite i2c operations from i2c client read/write to regmap i2c. As a result, most private functions now accept the private driver data instead of an i2c client pointer. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Tested-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
e55a5061 |
|
22-Sep-2020 |
Iskren Chernev <iskren.chernev@gmail.com> |
power: supply: max17040: Use devm_ to automate remove Two actions were performed during remove - power supply dereg and delayed work cleanup. Power supply dereg can be handled by using the devm_ version of the registration function. Work cleanup can be added as a devm_action. If probe fails after psy registration it will now be cleaned up properly. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Tested-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
2f38dc4d |
|
05-Jul-2020 |
Matheus Castello <matheus@castello.eng.br> |
power: supply: max17040: Add POWER_SUPPLY_PROP_CAPACITY_ALERT_MIN Adds the property POWER_SUPPLY_PROP_CAPACITY_ALERT_MIN to export the chip->low_soc_alert and add the property as writeable, implementing max17040_prop_writeable and max17040_set_property, so with that the user space can readjust the alerts. Signed-off-by: Matheus Castello <matheus@castello.eng.br> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
0383024f |
|
04-May-2020 |
Jonathan Bakker <xc-racer2@live.ca> |
power: supply: max17040: Correct voltage reading According to the datasheet available at (1), the bottom four bits are always zero and the actual voltage is 1.25x this value in mV. Since the kernel API specifies that voltages should be in uV, it should report 1250x the shifted value. 1) https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
e29242ad |
|
10-Jan-2020 |
Marek Szyprowski <m.szyprowski@samsung.com> |
power: supply: max17040: Correct IRQ wake handling Don't disable IRQ wake feature without prior enabling it. This fixes following warning observed on Exynos3250-based Rinato board: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1288 at kernel/irq/manage.c:724 irq_set_irq_wake+0xfc/0x134 Unbalanced IRQ 83 wake disable Modules linked in: CPU: 0 PID: 1288 Comm: rtcwake Not tainted 5.5.0-rc5-next-20200110-00031-g6289fffbb3f5 #7266 Hardware name: Samsung Exynos (Flattened Device Tree) [<c0112e48>] (unwind_backtrace) from [<c010e090>] (show_stack+0x10/0x14) [<c010e090>] (show_stack) from [<c0b25b28>] (dump_stack+0xa4/0xd0) [<c0b25b28>] (dump_stack) from [<c0128088>] (__warn+0xf4/0x10c) [<c0128088>] (__warn) from [<c0128114>] (warn_slowpath_fmt+0x74/0xb8) [<c0128114>] (warn_slowpath_fmt) from [<c019e9a0>] (irq_set_irq_wake+0xfc/0x134) [<c019e9a0>] (irq_set_irq_wake) from [<c0772708>] (max17040_suspend+0x50/0x58) [<c0772708>] (max17040_suspend) from [<c05f55ac>] (dpm_run_callback+0xb4/0x400) [<c05f55ac>] (dpm_run_callback) from [<c05f5e38>] (__device_suspend+0x140/0x814) [<c05f5e38>] (__device_suspend) from [<c05f9548>] (dpm_suspend+0x16c/0x564) [<c05f9548>] (dpm_suspend) from [<c05fa2e4>] (dpm_suspend_start+0x90/0x98) [<c05fa2e4>] (dpm_suspend_start) from [<c01977f4>] (suspend_devices_and_enter+0xec/0xc0c) [<c01977f4>] (suspend_devices_and_enter) from [<c019862c>] (pm_suspend+0x318/0x3e8) [<c019862c>] (pm_suspend) from [<c01963cc>] (state_store+0x68/0xc8) [<c01963cc>] (state_store) from [<c03531a4>] (kernfs_fop_write+0x10c/0x220) [<c03531a4>] (kernfs_fop_write) from [<c02b44c4>] (__vfs_write+0x2c/0x1c4) [<c02b44c4>] (__vfs_write) from [<c02b7288>] (vfs_write+0xa4/0x180) [<c02b7288>] (vfs_write) from [<c02b74d0>] (ksys_write+0x58/0xcc) [<c02b74d0>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xd6e83fa8 to 0xd6e83ff0) ... irq event stamp: 18028 hardirqs last enabled at (18027): [<c014b99c>] cancel_delayed_work+0x84/0xf8 hardirqs last disabled at (18028): [<c0b49b1c>] _raw_spin_lock_irqsave+0x1c/0x58 softirqs last enabled at (17876): [<c01026d8>] __do_softirq+0x4f0/0x5e4 softirqs last disabled at (17869): [<c0130d34>] irq_exit+0x16c/0x170 ---[ end trace 0728005730004e60 ]--- Fixes: 2e17ed94de68 ("power: supply: max17040: Add IRQ handler for low SOC alert") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
a08990ea |
|
04-Dec-2019 |
Matheus Castello <matheus@castello.eng.br> |
power: supply: max17040: Send uevent in SOC and status change Notify core through power_supply_changed() in case of changes in state of charge and power supply status. This is useful for user-space to efficiently update current battery level. Signed-off-by: Matheus Castello <matheus@castello.eng.br> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
cccdd0ca |
|
04-Dec-2019 |
Matheus Castello <matheus@castello.eng.br> |
power: supply: max17040: Config alert SOC low level threshold from FDT For configuration of fuel gauge alert for a low level state of charge interrupt we add a function to config level threshold and a device tree binding property to set it in flatned device tree node. Now we can use "maxim,alert-low-soc-level" property with the values from 1% up to 32% to configure alert interrupt threshold. Signed-off-by: Matheus Castello <matheus@castello.eng.br> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
2e17ed94 |
|
04-Dec-2019 |
Matheus Castello <matheus@castello.eng.br> |
power: supply: max17040: Add IRQ handler for low SOC alert According datasheet max17040 has a pin for alert host for low SOC. This pin can be used as external interrupt, so we need to check for interrupts assigned for device and handle it. In handler we are checking and storing fuel gauge registers values and send an uevent to notificate user space, so user space can decide save work or turn off since the alert demonstrate that the battery may no have the power to keep the system turned on for much longer. Signed-off-by: Matheus Castello <matheus@castello.eng.br> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
4e9c406d |
|
07-Jun-2019 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
power: supply: max17040_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>
|
#
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>
|
#
da28122c |
|
14-Mar-2017 |
Javier Martinez Canillas <javier@osg.samsung.com> |
power: supply: max17040: Add OF device ID table 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>
|
#
14d60bdd |
|
21-Sep-2016 |
Liu Xiang <liuxiang_1999@126.com> |
power: supply: max17040: Change register transaction length from 8 bits to 16 bits 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>
|
#
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>
|