linux-kernel - Re: [PATCH v4 1/4] power: supply: core: add quick charge type property

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:   Mon, 3 Aug 2020 13:49:50 +0200
From:   Sebastian Reichel <sre@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Pavel Machek <pavel@...x.de>, Qiwu Huang <yanziily@...il.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        jiangfei1@...omi.com, Qiwu Huang <huangqiwu@...omi.com>
Subject: Re: [PATCH v4 1/4] power: supply: core: add quick charge type
 property

Hi,

On Sun, Aug 02, 2020 at 06:57:38PM +0200, Greg KH wrote:
> On Sun, Aug 02, 2020 at 04:28:25PM +0200, Pavel Machek wrote:
> > On Sun 2020-08-02 14:37:42, Greg KH wrote:
> > > On Sun, Aug 02, 2020 at 02:00:15PM +0200, Pavel Machek wrote:
> > > > On Mon 2020-07-20 13:47:14, Qiwu Huang wrote:
> > > > > From: Qiwu Huang <huangqiwu@...omi.com>
> > > > > 
> > > > > Reports the kind of quick charge type based on
> > > > > different adapter power.
> > > > > 
> > > > > Signed-off-by: Qiwu Huang <huangqiwu@...omi.com>
> > > > > ---
> > > > >  Documentation/ABI/testing/sysfs-class-power | 21 +++++++++++++++++++++
> > > > >  drivers/power/supply/power_supply_sysfs.c   |  1 +
> > > > >  include/linux/power_supply.h                | 10 ++++++++++
> > > > >  3 files changed, 32 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> > > > > index 216d61a22f1e..dd3773dcf16a 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-class-power
> > > > > +++ b/Documentation/ABI/testing/sysfs-class-power
> > > > > @@ -708,3 +708,24 @@ Description:
> > > > >  
> > > > >  		Access: Read
> > > > >  		Valid values: 1-31
> > > > > +
> > > > > +What:		/sys/class/power_supply/<supply_name>/quick_charge_type
> > > > > +Date:		Jul 2020
> > > > > +Contact:	Fei Jiang <jiangfei1@...omi.com>
> > > > > +		Description:
> > > > > +		Reports the kind of quick charge type based on different adapter power.
> > > > > +		Different quick charge type represent different charging power.
> > > > > +		QUICK_CHARGE_NORMAL : Charging Power <= 10W
> > > > > +		QUICK_CHARGE_FAST : 10W < Charging Power <= 20W
> > > > > +		QUICK_CHARGE_FLASH : 20W < Charging Power <= 30W
> > > > > +		QUICK_CHARGE_TURBE : 30W < Charging Power <= 50W
> > > > > +		QUICK_CHARGE_SUPER : Charging Power > 50W
> > > > > +
> > > > > +		Access: Read-Only
> > > > > +		Valid values:
> > > > > +			0: QUICK_CHARGE_NORMAL,
> > > > > +			1: QUICK_CHARGE_FAST,
> > > > > +			2: QUICK_CHARGE_FLASH,
> > > > > +			3: QUICK_CHARGE_TURBE,
> > > > > +			4: QUICK_CHARGE_SUPER.
> > > > 
> > > > NAK.
> > > > 
> > > > Just expose value in watts or something... People are talking about > 100W charging, no
> > > > need to go with fast/turbe/super/hyper/nonsense.
> > > > 
> > > > BTW fast charge is already "well defined", and what you call Normal is usually fast charge.
> > > 
> > > I think these names come from the Qi charging spec, right?  So lets use
> > > what is given to us.
> > 
> > There are other standards, and this should better be generic.
> 
> What standard?  Why not go with this one, it's documented and out there
> and being used.

Well there is Power Delivery from USB Standard, Quick Charge from
Qualcomm, Super Charge from Huawei, Dash/Warp Charge from OnePlus,
Pump Express from Mediatek and the Qi stuff for wireless charging.
Possibly a few more, that I'm not aware of. Quickly charging devices
is a huge mess :(

The naming suggests that this is for Qualcomm's "Quick Charge"?

> > Simply expose value in watts.
> 
> What if you do not know the watts, you just know these ranges.

In general those chargers often do not know the exact watts/amps
and that information can only be gained from the battery fuel
gauge (which usually has a coulomb counter). Exposing the charger
class means there is a way to debug problems, so it makes sense
IMHO. But the classification is quite different between the vendor's
proprietary quick charge algorithms, so we need to be careful with
the naming. It should be clear which property should be used
for given hardware.

More importantely I prefer not to merge new APIs without any users
(i.e. a driver making use of those values). Having a reference
driver means, that there is an example how to use the values
correctly and proves it is actually needed upstream. Right now
this looks like "let's modify the upstream kernel, so that we can
easily maintain our out of tree driver".

-- Sebastian

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