| 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
| ||
|
Message-ID: <ef4409b2-abd8-0eac-f66e-6858c3358cc1@gmail.com>
Date: Tue, 7 Mar 2023 16:10:20 +0200
From: Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To: Pavel Machek <pavel@....cz>,
kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org, tony@...mide.com, sre@...nel.org,
nekit1000@...il.com, mpartap@....net, merlijn@...zup.org,
martin_rysavy@...trum.cz, phone-devel@...r.kernel.org,
maemo-leste@...ts.dyne.org
Subject: Re: Motorola Droid 4 -- Stopping charger when battery is full
Hi,
On 7.03.23 г. 14:36 ч., Pavel Machek wrote:
> Hi!
>
> I complained that "battery life is very poor" with leste. It seems to
> be combination of several factors.
>
> 1) I was using very old battery
>
> 2) My charger is detected as "USB", not as "AC"
>
And this is because there is no working charger detection in the driver,
so initial current limit is hard-coded to 500mA.
I was on it, but had to suspend, partially because of
https://lore.kernel.org/lkml/1668430562-27114-1-git-send-email-ivo.g.dimitrov.75@gmail.com/#r
, which I will have to fix by other means.
OTOH, I have cpcap-extcon driver around which does charger detection and
sends the appropriate events, along with cpcap-charger patches that
properly limit the charger current, however, until the issue in charger
framework is fixed those are of no use.
Didn't have enough spare time lately to resume the work :(
> 3) Charger was cycling on/off, which was annoying and I often ending
> up dissconnecting the charger
>
> 4) It probably has a bit higher power consuption than original android
>
> 5) Android is more aggressive, charges to 4.35V, and allows deeper
> discharge
>
We can't charge to 4.35 without knowing the type of the battery,
unfortunately
https://lore.kernel.org/all/1667332425-12536-1-git-send-email-ivo.g.dimitrov.75@gmail.com/T/#t
didn't make it, for reasons unknown to me.
Yes, we have that in leste kernel, but I am getting sick of supporting
out-of-tree patches, so I don't really want to build userspace on kernel
features that are not upstream, if possible.
Also, some guys have concerns about charging (and keeping it charged)
@4.35, because of the possibly reduced battery life.
> According to my measurements "CPCAP_REG_CRM_FET_OVRD |
> CPCAP_REG_CRM_FET_CTRL" results in battery discharding and 0A drawn
> frmo the USB. "CPCAP_REG_CRM_FET_OVRD" is phone powered from USB,
> with battery more or less disconnected (<12mA), which is what we want
> in battery full situation.
>
What will happen if phone needs to draw more than N mA (N is the set
charger current limit)?
> Second problem was that phone never really stayed in "battery full",
> immediately exiting it.
>
> This should solve both issues (plus it enables a lot of
> debugging).
>
Thanks and regards,
Ivo
> Best regards,
> Pavel
>
> Signed-off-by: Pavel Machek <pavel@....cz>
>
> diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c
> index 8bd1abe246cc..af268fc87fbf 100644
> --- a/drivers/power/supply/cpcap-charger.c
> +++ b/drivers/power/supply/cpcap-charger.c
> @@ -10,6 +10,7 @@
> * Copyright (C) 2009-2010 Motorola, Inc.
> */
>
> +#define DEBUG
> #include <linux/atomic.h>
> #include <linux/init.h>
> #include <linux/module.h>
> @@ -410,8 +411,7 @@ static int cpcap_charger_disable(struct cpcap_charger_ddata *ddata)
> int error;
>
> error = regmap_update_bits(ddata->reg, CPCAP_REG_CRM, 0x3fff,
> - CPCAP_REG_CRM_FET_OVRD |
> - CPCAP_REG_CRM_FET_CTRL);
> + CPCAP_REG_CRM_FET_OVRD);
> if (error)
> dev_err(ddata->dev, "%s failed with %i\n", __func__, error);
>
> @@ -686,8 +686,11 @@ static void cpcap_usb_detect(struct work_struct *work)
> if (error)
> return;
>
> + dev_dbg(ddata->dev, "%d %d %d %d\n", s.chrg_det, s.chrgcurr1, s.chrgcurr2, s.vbusvld);
> +
> /* Just init the state if a charger is connected with no chrg_det set */
> if (!s.chrg_det && s.chrgcurr1 && s.vbusvld) {
> + printk("Just init -- not chrg_det\n");
> cpcap_charger_update_state(ddata,
> POWER_SUPPLY_STATUS_NOT_CHARGING);
>
> @@ -699,6 +702,7 @@ static void cpcap_usb_detect(struct work_struct *work)
> * charged to 4.35V by Android. Try again in 10 minutes.
> */
> if (cpcap_charger_get_charge_voltage(ddata) > ddata->voltage) {
> + printk("Battery overcharged, wait\n");
> cpcap_charger_disconnect(ddata,
> POWER_SUPPLY_STATUS_NOT_CHARGING,
> HZ * 60 * 10);
> @@ -713,14 +717,24 @@ static void cpcap_usb_detect(struct work_struct *work)
> break;
> new_state = POWER_SUPPLY_STATUS_FULL;
>
> + printk("No current -> we are done\n");
> +
> if (s.chrgcurr1 && s.vbusvld) {
> cpcap_charger_disconnect(ddata, new_state, HZ * 5);
> return;
> }
> break;
> case POWER_SUPPLY_STATUS_FULL:
> + if (s.vbusvld) {
> + printk("Full, stay full\n");
> + schedule_delayed_work(&ddata->detect_work, HZ * 10);
> + return;
> + }
> if (!s.chrgcurr2)
> break;
> +
> + printk("Full but we need to do something\n");
> +
> if (s.vbusvld)
> new_state = POWER_SUPPLY_STATUS_NOT_CHARGING;
> else
> @@ -762,6 +776,7 @@ static void cpcap_usb_detect(struct work_struct *work)
> if (!delayed_work_pending(&ddata->ramp_work))
> schedule_delayed_work(&ddata->ramp_work, HZ/20);
> } else {
> + printk("No feeding bus, disabling\n");
> ddata->set_current = 0;
> error = cpcap_charger_disable(ddata);
> if (error)
>
Powered by blists - more mailing lists