linux-kernel - Re: [PATCH v1 2/2] power: supply: sbs-battery: Fall back to Li-ion battery type for bq20z75

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 May 2021 17:31:36 +0200
From:   Sebastian Reichel <sebastian.reichel@...labora.com>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Antoni Aloy Torrens <aaloytorrens@...il.com>,
        Nikola Milosavljević <mnidza@...look.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] power: supply: sbs-battery: Fall back to Li-ion
 battery type for bq20z75

Hi,

On Tue, May 11, 2021 at 01:08:27AM +0300, Dmitry Osipenko wrote:
> The older bq20z75 controller doesn't support reporting the battery type
> and the type is Li-ion in this case.
> 
> Tested-by: Antoni Aloy Torrens <aaloytorrens@...il.com> # TF101
> Tested-by: Nikola Milosavljević <mnidza@...look.com> # TF101
> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> ---

If it does not support reporting the battery type you should get an
error from sbs_get_battery_string_property. Obviously a string has
been returned, or you would not end up that far in the code. What
string do you see?

Considering BQ20Z65 and BQ20Z75 also support Li-Po I don't think
it's a good idea to fall back to Li-Ion. Kernel should never lie
about this, since I know some people use userspace based charging
setup and the charge limits are different for Li-Ion and Li-Po. When
reaching this place we do not know 100%, that it is a Li-ion, so
returning UNKNOWN is the safe option.

If you know, that your device (TF101) only supports Li-Ion
batteries, we can add a device specific override. But is this worth
the added maintenance burden? What is your plan for using this
information?

-- Sebastian

>  drivers/power/supply/sbs-battery.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
> index b71fbf543428..fec6c139d4ff 100644
> --- a/drivers/power/supply/sbs-battery.c
> +++ b/drivers/power/supply/sbs-battery.c
> @@ -813,9 +813,17 @@ static int sbs_get_chemistry(struct i2c_client *client,
>  	else
>  		val->intval = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
>  
> -	if (val->intval == POWER_SUPPLY_TECHNOLOGY_UNKNOWN)
> +	if (val->intval == POWER_SUPPLY_TECHNOLOGY_UNKNOWN) {
> +		struct sbs_info *chip = i2c_get_clientdata(client);
> +
>  		dev_warn_once(&client->dev, "Unknown chemistry: %s\n", chemistry);
>  
> +		if (chip->flags & SBS_FLAGS_TI_BQ20ZX5) {
> +			dev_warn_once(&client->dev, "Falling back to Li-ion\n");
> +			val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
> +		}
> +	}
> +
>  	return 0;
>  }
>  
> -- 
> 2.30.2
> 

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)