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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 26 Jun 2012 00:57:03 +0000 (GMT)
From:	MyungJoo Ham <>
To:	"Tc, Jenny" <>
Cc:	"" <>,
	"Anton Vorontsov (" <>,
	"Anton Vorontsov (" 
	"Pallala, Ramakrishna" <>,
	최찬우 <>,
	박경민 <>
Subject: Re: Charger Manager Proposal.

> MyungJoo,
> I would like to align with the charger-manager activities and would like to propose few changes for charger-manager. The changes I would like to have in the charger manager is 
> 	* Manage charging based on a battery profile - Each battery  can have a different  profile and the charging should be done based on this profile. So there should be a mechanism inside the charger-manager to read the battery profile. To start with we can make it available as platform data for the charger-manager.

Yes, each instance of charger-manager devices represents a battery (or a set of batteries controlled as a single battery.) Thus, the profile can be described in struct charger_desc. What do you need additionally there?

> 	* The charge parameters (CC and CV) needs to be changed as per the batter profile. The battery profile will have a different CC and CV for different  temperature zone. So charger-manager needs to listen  battery Temperature change events (using power_supply_changed events from FG?)  and modify the CC and CV.

Then, my suggestion is that
Plan A.
  1. Add a pair of CC and CV regulators at struct charger_desc, independently defined in struct charger_desc from charger_desc.charger_regulators as charger_regulators are to enable/disable chargers attached to the battery described by struct charger_desc.
  2. Add an array of { temperature (min), CC-value, CV-value, hysterisis-temp } with temperature = - MAX for "default" value.
Plan B.
  1. Add an array of { temperature (min), callback, hysterisis-temp}

If CC/CV values are the only ones to be controlled by temperature, Plan A is fine. However, if we are going to need more, Plan B may be more appropriate.

> 	* It's good to have a hybrid (Software and Hardware mode) full detection logic. This give more flexibility to define the charge full detection thresholds. So charger-manager can listen to charge-full detection from charger-hardware and can start a thread to verify the thresholds from software. 

You can do this with cm_notify_event() and fullbatt_vchk() though we may need more parameters to control the behavior of fullbatt_vchk().

> 	* Need to have a maintenance upper voltage threshold. The upper threshold needs to be less than the Battery FULL voltage threshold and this can part of battery profile. This approach helps to increase the battery life.

Could you please elaborate this one more? What do you do with "upper threshold"?

> I would like to start implementing these features for charger manager. But I would like to align with your planned charger-manager activities so that we don't end up in duplicating the effort. Please let me know your suggestions on this.
> -jtc

Another update or modification on-going is:
	- Integrating with extcon subsystem
	- Add current-limit for each charger
You can see the according patches at

Thanks. And sorry for late reply; we had the office moved which cut the internetaccess for a while.


Powered by blists - more mailing lists