From: Hans de Goede <hansg@kernel.org>
To: Derek Ross <derekross@gmail.com>, Sebastian Reichel <sre@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>,
kernel@puri.sm, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] power: supply: max17042_battery: infer the status when no supplier is described
Date: Mon, 19 Oct 2026 16:37:14 +0200 [thread overview]
Message-ID: <b48284b4-68d1-493c-a34b-20306c564cae@kernel.org> (raw)
In-Reply-To: <20261019143307.2109629-1-derekross@gmail.com>
Hi,
On 19-Oct-26 4:33 PM, Derek Ross wrote:
> When no power supply is described as supplying the battery,
> power_supply_am_i_supplied() returns -ENODEV and the driver reports
> POWER_SUPPLY_STATUS_UNKNOWN, even though the gauge measures the battery
> current itself.
>
> That is the case on the Pixel 7 Pro, where the charger is left running
> by the bootloader and no charger driver is bound yet. The battery read
> "Unknown" while taking in 1.2 A, so the desktop showed no charging
> indicator and upower treated the phone as discharging: at its critical
> percentage it put a charging phone to sleep.
>
> When no supplier is described and current sense is enabled, take the
> status from the measured current: charging while current flows into the
> battery, full when the gauge reports end of charge and no current flows,
> discharging otherwise. A described supplier keeps the existing logic, and
> without current sense the status stays unknown.
>
> Signed-off-by: Derek Ross <derekross@gmail.com>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Regards,
Hans
> ---
> drivers/power/supply/max17042_battery.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/supply/max17042_battery.c b/drivers/power/supply/max17042_battery.c
> index 8138b52e05e1..c437d80700a6 100644
> --- a/drivers/power/supply/max17042_battery.c
> +++ b/drivers/power/supply/max17042_battery.c
> @@ -148,18 +148,26 @@ static int max17042_get_status(struct max17042_chip *chip, int *status)
> {
> int ret, charge_full, charge_now;
> int current_now;
> + bool supplied, full;
> u32 data;
>
> ret = power_supply_am_i_supplied(chip->battery);
> - if (ret < 0) {
> - *status = POWER_SUPPLY_STATUS_UNKNOWN;
> - return 0;
> - }
> if (ret == 0) {
> *status = POWER_SUPPLY_STATUS_DISCHARGING;
> return 0;
> }
>
> + /*
> + * A negative value means no supplier is described, e.g. a charger the
> + * bootloader left running that no driver owns. The gauge's own current
> + * sense still tells which way charge flows, so use it when it's there.
> + */
> + supplied = ret > 0;
> + if (!supplied && !chip->enable_current_sense) {
> + *status = POWER_SUPPLY_STATUS_UNKNOWN;
> + return 0;
> + }
> +
> /*
> * The MAX170xx has builtin end-of-charge detection and will update
> * FullCAP to match RepCap when it detects end of charging.
> @@ -178,7 +186,8 @@ static int max17042_get_status(struct max17042_chip *chip, int *status)
> if (ret < 0)
> return ret;
>
> - if ((charge_full - charge_now) <= MAX17042_FULL_THRESHOLD) {
> + full = (charge_full - charge_now) <= MAX17042_FULL_THRESHOLD;
> + if (supplied && full) {
> *status = POWER_SUPPLY_STATUS_FULL;
> return 0;
> }
> @@ -200,6 +209,8 @@ static int max17042_get_status(struct max17042_chip *chip, int *status)
>
> if (current_now > 0)
> *status = POWER_SUPPLY_STATUS_CHARGING;
> + else if (full && current_now == 0)
> + *status = POWER_SUPPLY_STATUS_FULL;
> else
> *status = POWER_SUPPLY_STATUS_DISCHARGING;
>
prev parent reply other threads:[~2026-10-19 14:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:33 Derek Ross
2026-10-19 14:37 ` Hans de Goede [this message]
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=b48284b4-68d1-493c-a34b-20306c564cae@kernel.org \
--to=hansg@kernel.org \
--cc=derekross@gmail.com \
--cc=kernel@puri.sm \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=sebastian.krzyszkowiak@puri.sm \
--cc=sre@kernel.org \
/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®