All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sre@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Pavel Machek <pavel@denx.de>, Qiwu Huang <yanziily@gmail.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	jiangfei1@xiaomi.com, Qiwu Huang <huangqiwu@xiaomi.com>
Subject: Re: [PATCH v4 1/4] power: supply: core: add quick charge type property
Date: Mon, 3 Aug 2020 13:49:50 +0200	[thread overview]
Message-ID: <20200803114950.oyb3gzyiccybah3u@earth.universe> (raw)
In-Reply-To: <20200802165738.GA293244@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

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@xiaomi.com>
> > > > > 
> > > > > Reports the kind of quick charge type based on
> > > > > different adapter power.
> > > > > 
> > > > > Signed-off-by: Qiwu Huang <huangqiwu@xiaomi.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@xiaomi.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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-08-03 11:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20  5:47 [PATCH v4 0/4] add some power supply properties about wireless/wired charging Qiwu Huang
2020-07-20  5:47 ` [PATCH v4 1/4] power: supply: core: add quick charge type property Qiwu Huang
2020-08-02 12:00   ` Pavel Machek
2020-08-02 12:37     ` Greg KH
2020-08-02 14:28       ` Pavel Machek
2020-08-02 16:57         ` Greg KH
2020-08-03 11:49           ` Sebastian Reichel [this message]
2020-08-03 11:56             ` Greg KH
2020-08-04  2:11               ` ivan
2020-08-04  7:49                 ` Greg KH
2020-07-20  5:47 ` [PATCH v4 2/4] power: supply: core: add wireless charger adapter " Qiwu Huang
2020-07-20  5:47 ` [PATCH v4 3/4] power: supply: core: add wireless signal strength property Qiwu Huang
2020-07-20  5:47 ` [PATCH v4 4/4] power: supply: core: property to control reverse charge Qiwu Huang
2020-07-20  8:21 ` [PATCH v4 0/4] add some power supply properties about wireless/wired charging Greg KH
2020-07-21  3:12   ` ivan

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=20200803114950.oyb3gzyiccybah3u@earth.universe \
    --to=sre@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=huangqiwu@xiaomi.com \
    --cc=jiangfei1@xiaomi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@denx.de \
    --cc=yanziily@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.