Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Hermes Zhang <Hermes.Zhang@axis.com>
To:     =?iso-8859-1?Q?Pali_Roh=E1r?= <pali@kernel.org>,
        Hermes Zhang <Hermes.Zhang@axis.com>
CC:     "lars@metafoo.de" <lars@metafoo.de>,
        Sebastian Reichel <sre@kernel.org>, kernel <kernel@axis.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] power: supply: bq27xxx: Return the value instead of
 -ENODATA
Thread-Topic: [PATCH] power: supply: bq27xxx: Return the value instead of
 -ENODATA
Thread-Index: AQHXJjT9YXVQp+YZmUqmV5QFL6HFrQ==
Date:   Thu, 1 Apr 2021 01:51:28 +0000
Message-ID: <3acaabf2ec63418891e3f698c16b9a21@XBOX01.axis.com>
References: <20210331135141.8063-1-chenhui.zhang@axis.com>
 <20210331140238.jl3qprpqhqave4bf@pali>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

On 3/31/21 10:02 PM, Pali Roh=E1r wrote:=0A=
> @@ -1655,9 +1655,6 @@ static int bq27xxx_battery_read_time(struct bq27xxx=
_device_info *di, u8 reg)=0A=
>  		return tval;=0A=
>  	}=0A=
>  =0A=
> -	if (tval =3D=3D 65535)=0A=
> -		return -ENODATA;=0A=
> -=0A=
>  	return tval * 60;=0A=
> I'm not sure if this is correct change. If value 65535 is special which=
=0A=
> indicates that data are not available then driver should not return=0A=
> (converted) value 65535*60. If -ENODATA is there to indicate that data=0A=
> are not available then -ENODATA should not be used.=0A=
>=0A=
> And if there is application which does not handle -ENODATA for state=0A=
> when data are not available then it is a bug in application.=0A=
=0A=
Yeah, I just have a feeling return -ENODATA for time_to_full/empty is=0A=
not good here. Because:=0A=
=0A=
1. From chip datasheet, it mentioned return 65535 when it's not=0A=
available (e.g. read time_to_full when discharging), but the driver=0A=
changes behavior here.=0A=
=0A=
2. There is other case will return -ENODATA (e.g. the gauge not=0A=
calibrated), so it will confuse application which is real failure.=0A=
=0A=
Could we change the value in minute instead of seconds in=0A=
bq27xxx_battery_read_time(), so that means driver do nothing but only=0A=
pass the value from the chip?=0A=
=0A=
=0A=
Best Regards,=0A=
=0A=
Hermes=0A=
=0A=
=0A=