Patch "power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense" has been added to the 6.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense

to the 6.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     power-supply-max17042_battery-fix-soc-threshold-calc.patch
and it can be found in the queue-6.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 0abf3d2ce807b38191ade28e63fa585f4c32f5fd
Author: Artur Weber <aweber.kernel@xxxxxxxxx>
Date:   Sat Aug 17 12:51:14 2024 +0200

    power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense
    
    [ Upstream commit 3a3acf839b2cedf092bdd1ff65b0e9895df1656b ]
    
    Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for
    capacity when no rsns") made it so that capacity on systems without
    current sensing would be read from VFSOC instead of RepSOC. However,
    the SOC threshold calculation still read RepSOC to get the SOC
    regardless of the current sensing option state.
    
    Fix this by applying the same conditional to determine which register
    should be read.
    
    This also seems to be the intended behavior as per the datasheet - SOC
    alert config value in MiscCFG on setups without current sensing is set
    to a value of 0b11, indicating SOC alerts being generated based on
    VFSOC, instead of 0b00 which indicates SOC alerts being generated based
    on RepSOC.
    
    This fixes an issue on the Galaxy S3/Midas boards, where the alert
    interrupt would be constantly retriggered, causing high CPU usage
    on idle (around ~12%-15%).
    
    Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC")
    Signed-off-by: Artur Weber <aweber.kernel@xxxxxxxxx>
    Reviewed-by: Henrik Grimler <henrik@xxxxxxxxxx>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@xxxxxxxxx
    Signed-off-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/power/supply/max17042_battery.c b/drivers/power/supply/max17042_battery.c
index e7d37e422c3f6..496c3e1f2ee6d 100644
--- a/drivers/power/supply/max17042_battery.c
+++ b/drivers/power/supply/max17042_battery.c
@@ -853,7 +853,10 @@ static void max17042_set_soc_threshold(struct max17042_chip *chip, u16 off)
 	/* program interrupt thresholds such that we should
 	 * get interrupt for every 'off' perc change in the soc
 	 */
-	regmap_read(map, MAX17042_RepSOC, &soc);
+	if (chip->pdata->enable_current_sense)
+		regmap_read(map, MAX17042_RepSOC, &soc);
+	else
+		regmap_read(map, MAX17042_VFSOC, &soc);
 	soc >>= 8;
 	soc_tr = (soc + off) << 8;
 	if (off < soc)




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux