linux-kernel - RE: RE: Charger Manager Proposal.

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] [day] [month] [year] [list]

Date:	Thu, 19 Jul 2012 11:28:06 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	Anton Vorontsov <cbouatmailru@...il.com>
CC:	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>,
	"cw00.choi@...sung.com" <cw00.choi@...sung.com>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>
Subject: RE: RE: Charger Manager Proposal.

Anton,


> Hm. So Myungjoo thinks that some of the features are compatible. Which do
> you guys think are not compatible? Is this because charger manager does
> everything using a regulator framework? That is, quoting you:
> 
>   "The challenge I see in implementing the above requirements in charger
>    manager is, some of the above requirements are not supported by
>    the regulator framework."
> 
> So, maybe the part of the solution would be enhancing the regulators
> framework?..

I think modifying the regulator framework will not give a cleaner solution. The charger has more properties than  that can be handled by a regulator framework (Like controlling the charger path, CC and CV etc. ). Also wanted to make the charger algorithm event based. So keeping it with power_supply subsystem gives more flexibility to handle events. For example battery temperature change, voltage change, charger/battery status change etc  can be easily hooked to the power_supply_changed_work.

> 
> > The outcome of all the above changes would be that, a set of charging
> algorithms would be available in the mainline and chargers can make use of
> the algorithms without making much modifications to the charger driver
> code. Also this would give a standard framework for monitoring and
> controlling battery charging.
> 
> The idea of plug-in charging algorithms sounds great. So that we could
> choose the algo based on the battery type, charger type etc.
> This is awesome. But do you think you really need a new subsystem for that?
> And if so, will it complement charger manager, compete or substitute it?

The idea is to enhance the power_supply subsystem to plugin charging algorithms. It is not a substitute solution for charger-manager. 
> 
> I would have no problem with complementary subsystem, or just
> evolutionary/incrementally changing the charger-manger (this is surely
> preferred). If you think there is no way for incrementally modifying charger-
> manager for your needs, and you want a "from scratch" solution, this is also
> doable but following requirements are must-have:
> 
> 1. You can prove (on technical merits) that your new charger manager
>    is a complete superset of the old one, and adds some vital features
>    not available before (and these would be hard to implement in
>    terms of the old subsystem);
> 2. You'll have a defined roadmap to convert all charger-manager
>    users to a new subsystem (preferably w/ patches ready).
> 

The new solution is not intended to replace the charger-manager framework. So I think the charger-manager users can continue to use the charger-manager without any change.

> From the past experience, I can tell you that modifying an existing subsystem
> is a much easier way. :-) And the biggest advantage of the current code is
> that it is already well-tested, and incremental changes are easy to bisect.
> 

I agree to your point. We wanted to make use of the power_supply subsystem features as much as possible rather than having a completely new subsystem.

Thanks
-jtc