DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 655A4606A31A
From: joonhoekim <26rote@gmail.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Joonhoe Kim <26rote@gmail.com>,
	sre@kernel.org,
	kamal.wadhwa@oss.qualcomm.com,
	anjelique.melendez@oss.qualcomm.com,
	dhruvin.rajpura@oss.qualcomm.com,
	andersson@kernel.org,
	dmitry.baryshkov@oss.qualcomm.com,
	linux-arm-msm@vger.kernel.org,
	linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] power: supply: qcom_battmgr: expose the charge current limit
Date: Tue, 20 Oct 2026 22:23:48 +0900
Message-ID: <20261020132350.953-1-26rote@gmail.com>
In-Reply-To: <4ec618a6-052b-47de-8418-e0e319af10ce@oss.qualcomm.com>
References: <20261016124806.1789-1-26rote@gmail.com> <20261016124806.1789-2-26rote@gmail.com> <4ec618a6-052b-47de-8418-e0e319af10ce@oss.qualcomm.com>
Precedence: list
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Joonhoe Kim <26rote@gmail.com>

On 10/20/26 11:55 AM, Konrad Dybcio wrote:
>> +	mutex_lock(&battmgr->lock);
>
> guard(mutex)(&battmgr->lock)

Will do.

>> +	if (!ret) {
>
> LLM suggests to add:
>
> -	if (!ret) {
> +	if (!ret && !battmgr->info.charge_ctrl_limit_max)
> +		ret = -ENODATA;
> +	if (!ret) {
>
> to prevent a possible zero-maximum value coming from the FW
> from messing with us here

Agreed. This firmware reports a maximum of 12.4 A, but a zero maximum
would clamp every write to 0, and a limit of 0 stops charging here until
the end threshold is moved below the capacity and back. Returning
-ENODATA is better than that.

Both in v2. I'll wait until Jingyi has had a chance to check the sign
in 1/2, then resend the two together.

Thanks,
Joonhoe Kim