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:	Tue, 11 Nov 2014 21:42:19 +0100
From:	Pavel Machek <pavel@....cz>
To:	"Tc, Jenny" <jenny.tc@...el.com>
Cc:	"jonghwa3.lee@...sung.com" <jonghwa3.lee@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"sre@...nel.org" <sre@...nel.org>,
	"dbaryshkov@...il.com" <dbaryshkov@...il.com>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"anton@...msg.org" <anton@...msg.org>
Subject: Re: [PATCH 2/3] power: core: Add variables related temperature to
 power_supply_info.

On Tue 2014-11-11 04:56:31, Tc, Jenny wrote:
> > > The CC,CV and restart threshold would vary based on the battery temperature
> > > So I would suggest to have temperature zone table as part  of battery info
> > > along with other attributes.
> > >
> > > int iterm; //charge termination current (used to stop charging)
> > > int temp_zone_count; // number of temperature zone tables present
> > > struct batt_temp_mon_table temp_mon_tbl[MAX_TEMP_MON_TABLE];
> > //temperature zone table array
> > >
> > > struct  batt_temp_mon_table {
> > > 	 short int temp_max;
> > > 	 short int cc;
> > > 	 short int cv;
> > > 	 short int vbat_vchk_drop_uv;
> > > 	 short int temp_min;
> > > };
> > >
> > 
> > 
> > IMO, throttling cc/cv according the temperature can be done via thermal fw
> > interface. However voltage drop and charging termination current can be added here.
> 
> The CC/CV for each battery temperature zone is defined as part of battery spec. This is
> as per the JEITA/PSE standards. So IMO, this is a battery charging information
> (charging object) rather than a thermal throttling information.
> 
> Also the battery information may not fit into a standard format. Different standards have
> different format for charging object. So I would suggest to make it flexible enough to
> support different charging object format. For example MIPI BIF charging object format
> (https://members.mipi.org/wg/BIF/document/11518) and MIPI BIF Rule based charging algorithm
> (http://mipi.org/sites/default/files/mipi_BIF_rule-based-charging_white-paper_1.pdf)
> has different charging object format. This is why the patch  https://lkml.org/lkml/2014/8/13/355
> has option to support different charging objects and different charging algorithms.

Yes, and this is also why your patches are not being
merged. Overengineered, too complex. Citing standards will not improve
the patches.

And yes, adding cc/cv to the thermal interface seems like a good idea
to me.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ