linux-kernel - [RFC PATCH 1/4] regulator: core: Ensure the cached state matches the hardware state in regulator_set_voltage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240605074936.578687-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Date: Wed,  5 Jun 2024 08:49:33 +0100
From: Prabhakar <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert+renesas@...der.be>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Magnus Damm <magnus.damm@...il.com>
Cc: linux-mmc@...r.kernel.org,
	devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org,
	Prabhakar <prabhakar.csengg@...il.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Biju Das <biju.das.jz@...renesas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: [RFC PATCH 1/4] regulator: core: Ensure the cached state matches the hardware state in regulator_set_voltage_unlocked()

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>

Ensure that the cached state matches the hardware setting before
considering it a no-op in regulator_set_voltage_unlocked().

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
---
Driver code flow:
1> set regulator to 1.8V (BIT0 = 1)
2> Regulator cached state now will be 1.8V
3> Now for some reason driver issues a reset to the IP block
   which resets the registers to default value. In this process
   the regulator is set to 3.3V (BIT0 = 0)
4> Now the driver requests the regulator core to set 1.8V
5> Due to below check of cached state we return back with success
   resulting undesired behaviour.
   
Hence an additional check is introduced to make sure the cache state
is matching with the HW.
---
 drivers/regulator/core.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5794f4e9dd52..65ee54b13428 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3765,10 +3765,13 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
 
 	/* If we're setting the same range as last time the change
 	 * should be a noop (some cpufreq implementations use the same
-	 * voltage for multiple frequencies, for example).
+	 * voltage for multiple frequencies, for example). Also make sure
+	 * state is the same in HW.
 	 */
-	if (voltage->min_uV == min_uV && voltage->max_uV == max_uV)
-		goto out;
+	if (voltage->min_uV == min_uV && voltage->max_uV == max_uV) {
+		if (regulator_get_voltage_rdev(rdev) == min_uV)
+			goto out;
+	}
 
 	/* If we're trying to set a range that overlaps the current voltage,
 	 * return successfully even though the regulator does not support
-- 
2.34.1