mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Sebastian Reichel <sre@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Subbaraman Narayanamurthy
	<subbaraman.narayanamurthy@oss.qualcomm.com>,
	David Collins <david.collins@oss.qualcomm.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, kernel@oss.qualcomm.com,
	devicetree@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 5/8] power: supply: qcom_battmgr: Add charge control support
Date: Fri, 30 May 2025 17:37:58 +0800	[thread overview]
Message-ID: <3df56548-49ea-498c-9ee3-b7e1d2d85d2e@oss.qualcomm.com> (raw)
In-Reply-To: <8b396edf-e344-47e9-b497-3f7fb35783ed@linaro.org>

Thanks for reviewing the change!

On 5/30/2025 4:48 PM, Bryan O'Donoghue wrote:
> On 30/05/2025 08:35, Fenglin Wu via B4 Relay wrote:
>> From: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>>
>> Add charge control support for SM8550 and X1E80100. It's supported
>> with below two power supply properties:
>>
>> charge_control_end_threshold: SOC threshold at which the charging
>> should be terminated.
>>
>> charge_control_start_threshold: SOC threshold at which the charging
>> should be resumed.
>
> Maybe this is very obvious to battery charger experts but what does 
> SOC mean here ?
>
> Reading your patch you pass a "int soc" and compare it to a threshold 
> value, without 'soc' having an obvious meaning.
>
> Its a threshold right ? Why not just call it threshold ?
>
"SOC" stands for battery State of Charge, I will rephrase the commit 
text for better explanation.
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>> ---
>>   drivers/power/supply/qcom_battmgr.c | 256 
>> ++++++++++++++++++++++++++++++++++--
>>   1 file changed, 248 insertions(+), 8 deletions(-)
>>
>> -    if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
>> +    if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
>> +            battmgr->variant == QCOM_BATTMGR_X1E80100)
>
> Please run your series through checkpatch
>
I actually did that before sending the patches out. I run checkpatch 
with below two commands and I saw no issues:

git format -1 xxxx --stdtout | ./script/checkpatch.pl -

b4 prep --check

Can you let me know what specific command that you ran with it?

> 0004-power-supply-qcom_battmgr-Add-state_of_health-proper.patch has no 
> obvious style problems and is ready for submission.
> CHECK: Alignment should match open parenthesis
> #95: FILE: drivers/power/supply/qcom_battmgr.c:521:
> +    if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> +            battmgr->variant == QCOM_BATTMGR_X1E80100)
>
>>
>> +static int qcom_battmgr_set_charge_start_threshold(struct 
>> qcom_battmgr *battmgr, int soc)
>> +{
>> +    u32 target_soc, delta_soc;
>> +    int ret;
>> +
>> +    if (soc < CHARGE_CTRL_START_THR_MIN ||
>> +            soc > CHARGE_CTRL_START_THR_MAX) {
>> +        dev_err(battmgr->dev, "charge control start threshold exceed 
>> range: [%u - %u]\n",
>> +                CHARGE_CTRL_START_THR_MIN, CHARGE_CTRL_START_THR_MAX);
>> +        return -EINVAL;
>> +    }
>
> 'soc' is what - a threshold as far as I can tell.

I will update it with a more meaningful name

>>
>>       if (opcode == BATTMGR_NOTIFICATION)
>>           qcom_battmgr_notification(battmgr, data, len);
>> -    else if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
>> +    else if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
>> +            battmgr->variant == QCOM_BATTMGR_X1E80100)
>>           qcom_battmgr_sc8280xp_callback(battmgr, data, len);
>>       else
>>           qcom_battmgr_sm8350_callback(battmgr, data, len);
>> @@ -1333,7 +1560,8 @@ static void qcom_battmgr_pdr_notify(void *priv, 
>> int state)
>>   static const struct of_device_id qcom_battmgr_of_variants[] = {
>>       { .compatible = "qcom,sc8180x-pmic-glink", .data = (void 
>> *)QCOM_BATTMGR_SC8280XP },
>>       { .compatible = "qcom,sc8280xp-pmic-glink", .data = (void 
>> *)QCOM_BATTMGR_SC8280XP },
>> -    { .compatible = "qcom,x1e80100-pmic-glink", .data = (void 
>> *)QCOM_BATTMGR_SC8280XP },
>> +    { .compatible = "qcom,x1e80100-pmic-glink", .data = (void 
>> *)QCOM_BATTMGR_X1E80100 },
>> +    { .compatible = "qcom,sm8550-pmic-glink", .data = (void 
>> *)QCOM_BATTMGR_SM8550 },
>
> Please separate compat string addition from functional changes.
>
The compatible string "qcom,sm8550-pmic-glink" has been present in the 
binding for a while and it was added as a fallback of "qcom,pmic-glink". 
The battmgr function has been also supported well on SM8550 for a while. 
The change here is only specifying a different match data for SM8550 so 
the driver can handle some new features differently. Does it also need 
to add it in a separate change? If so,  this change would be split into 
following 3 patches I think:

1) add QCOM_BATTMGR_SM8550/X1E80100 variants definition in 
qcom_battmgr_variant.

2) add compatible string with corresponding match data for SM8550.

3) add the charge control function support.

>>       /* Unmatched devices falls back to QCOM_BATTMGR_SM8350 */
>>       {}
>>   };
>>
>>
>> -- 
>> 2.34.1
>>
>>
>>
>

  reply	other threads:[~2025-05-30  9:38 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30  7:35 [PATCH v2 0/8] power: supply: Add several features support in qcom-battmgr driver Fenglin Wu via B4 Relay
2025-05-30  7:35 ` [PATCH v2 1/8] power: supply: core: Add resistance power supply property Fenglin Wu via B4 Relay
2025-06-22  1:26   ` Sebastian Reichel
2025-06-30  8:28     ` Fenglin Wu
2025-07-07  0:15       ` Sebastian Reichel
2025-07-25  8:33         ` Fenglin Wu
2025-05-30  7:35 ` [PATCH v2 2/8] power: supply: core: Add state_of_health " Fenglin Wu via B4 Relay
2025-06-02  6:17   ` Dmitry Baryshkov
2025-06-03  4:50     ` Fenglin Wu
2025-06-03 10:35       ` Dmitry Baryshkov
2025-06-05  6:08         ` Fenglin Wu
2025-06-05  6:34           ` Dmitry Baryshkov
2025-06-22  1:17             ` Sebastian Reichel
2025-07-25  8:17               ` Fenglin Wu
2025-05-30  7:35 ` [PATCH v2 3/8] power: supply: qcom_battmgr: Add resistance " Fenglin Wu via B4 Relay
2025-06-02  6:17   ` Dmitry Baryshkov
2025-05-30  7:35 ` [PATCH v2 4/8] power: supply: qcom_battmgr: Add state_of_health property Fenglin Wu via B4 Relay
2025-05-30  7:35 ` [PATCH v2 5/8] power: supply: qcom_battmgr: Add charge control support Fenglin Wu via B4 Relay
2025-05-30  8:48   ` Bryan O'Donoghue
2025-05-30  9:37     ` Fenglin Wu [this message]
2025-05-30 10:11       ` Bryan O'Donoghue
2025-06-03  5:43         ` Fenglin Wu
2025-05-31 10:36   ` György Kurucz
2025-06-03  5:48     ` Fenglin Wu
2025-06-03 10:37       ` Dmitry Baryshkov
2025-06-07  9:46         ` Konrad Dybcio
2025-06-09  2:39           ` Fenglin Wu
2025-06-09  7:17             ` Dmitry Baryshkov
2025-06-10 12:19               ` Konrad Dybcio
2025-05-30  7:35 ` [PATCH v2 6/8] dt-bindings: soc: qcom: pmic-glink: Move X1E80100 out of fallbacks Fenglin Wu via B4 Relay
2025-06-02  6:38   ` Dmitry Baryshkov
2025-06-02  7:40   ` Krzysztof Kozlowski
2025-06-03  6:42     ` Fenglin Wu
2025-06-03  6:47       ` Krzysztof Kozlowski
2025-06-03  6:59         ` Fenglin Wu
2025-06-03  7:06           ` Krzysztof Kozlowski
2025-06-03  7:41             ` Fenglin Wu
2025-06-03  9:34               ` Krzysztof Kozlowski
2025-06-04  9:40                 ` Fenglin Wu
2025-06-10 12:22                   ` Konrad Dybcio
2025-05-30  7:35 ` [PATCH v2 7/8] usb: typec: ucsi_glink: Add UCSI quirk for X1E80100 platform Fenglin Wu via B4 Relay
2025-05-30  8:35   ` Bryan O'Donoghue
2025-05-30  7:35 ` [PATCH v2 8/8] arm64: dts: qcom: x1*: Remove qcom,sm8550-pmic-glink fallback Fenglin Wu via B4 Relay
2025-06-02  7:41   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3df56548-49ea-498c-9ee3-b7e1d2d85d2e@oss.qualcomm.com \
    --to=fenglin.wu@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=david.collins@oss.qualcomm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=kernel@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    --cc=subbaraman.narayanamurthy@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®