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 04:56:31 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	"jonghwa3.lee@...sung.com" <jonghwa3.lee@...sung.com>
CC:	"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>,
	"pavel@....cz" <pavel@....cz>
Subject: RE: [PATCH 2/3] power: core: Add variables related temperature to
 power_supply_info.

> > 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.

-Jenny

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ