linux-kernel - [PATCH 07/11] power: supply: qcom

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20250619-smb2-smb5-support-v1-7-ac5dec51b6e1@linaro.org>
Date: Thu, 19 Jun 2025 16:55:15 +0200
From: Casey Connolly <casey.connolly@...aro.org>
To: Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>, 
 Krzysztof Kozlowski <krzk+dt@...nel.org>, 
 Conor Dooley <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>, 
 Konrad Dybcio <konradybcio@...nel.org>, Kees Cook <kees@...nel.org>, 
 "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org, 
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Sebastian Reichel <sebastian.reichel@...labora.com>, 
 linux-hardening@...r.kernel.org, Casey Connolly <casey.connolly@...aro.org>
Subject: [PATCH 07/11] power: supply: qcom_smbx: bump up the max current

I set a super conservative current limit since we lack many of the
safety features (thermal monitoring, etc) that these drivers really
need. However now we have a better understanding of the hardware, it's
fine to bump this limit up a bit, devices can additionally set the max
current via devicetree instead.

Since this is common to smb2 and smb5, move this write out of the init
sequence and into probe proper.

Signed-off-by: Casey Connolly <casey.connolly@...aro.org>
---
 drivers/power/supply/qcom_smbx.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/power/supply/qcom_smbx.c b/drivers/power/supply/qcom_smbx.c
index 7fc232fa7260a7422ac12a48686cd7d396edd9a4..d1607674d291d6ef5762d35acd3330e2116f41a3 100644
--- a/drivers/power/supply/qcom_smbx.c
+++ b/drivers/power/supply/qcom_smbx.c
@@ -875,16 +875,8 @@ static const struct smb_init_register smb_init_seq[] = {
 	 */
 	{ .addr = PRE_CHARGE_CURRENT_CFG,
 	  .mask = PRE_CHARGE_CURRENT_SETTING_MASK,
 	  .val = 500000 / CURRENT_SCALE_FACTOR },
-	/*
-	 * This overrides all of the current limit options exposed to userspace
-	 * and prevents the device from pulling more than ~1A. This is done
-	 * to minimise potential fire hazard risks.
-	 */
-	{ .addr = FAST_CHARGE_CURRENT_CFG,
-	  .mask = FAST_CHARGE_CURRENT_SETTING_MASK,
-	  .val = 1000000 / CURRENT_SCALE_FACTOR },
 };

 static int smb_init_hw(struct smb_chip *chip)
 {
@@ -1029,8 +1021,22 @@ static int smb_probe(struct platform_device *pdev)
 		return dev_err_probe(chip->dev, rc, "Couldn't set wake irq\n");

 	platform_set_drvdata(pdev, chip);

+	/*
+	 * This overrides all of the other current limits and is expected
+	 * to be used for setting limits based on temperature. We set some
+	 * relatively safe default value while still allowing a comfortably
+	 * fast charging rate. Once temperature monitoring is hooked up we
+	 * would expect this to be changed dynamically based on temperature
+	 * reporting.
+	 */
+	rc = regmap_write(chip->regmap, chip->base + FAST_CHARGE_CURRENT_CFG,
+			  1950000 / CURRENT_SCALE_FACTOR);
+	if (rc < 0)
+		return dev_err_probe(chip->dev, rc,
+				     "Couldn't write fast charge current cfg");
+
 	/* Initialise charger state */
 	schedule_delayed_work(&chip->status_change_work, 0);

 	return 0;

-- 
2.49.0