linux-kernel - RE: [PATCH v2] charger_manager: update charge profile upon temperature zone change

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]

Message-ID: <20ADAB092842284E95860F279283C56421CF0A@BGSMSX101.gar.corp.intel.com>
Date:	Wed, 9 May 2012 06:19:47 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Anton Vorontsov <cbouatmailru@...il.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	??? <cw00.choi@...sung.com>
Subject: RE: [PATCH v2] charger_manager: update charge profile upon
 temperature zone change


> > > This patch allows the Charger-Manager to adjust the charging
> > > parameters upon events like VBUS rise or drop and allows batteries
> > > to have multiple charge profiles for different temperature zones.
> > >
> > > Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@...el.com>
> >
> > I don't see how the parameters are changed when update_charger is true.
> My initial thought was to keep these details hide from CM.
> 
> > Are you intending to do it at userspace after getting uevent_notify()?
> > (I don't think it's good)
> No, we will do it from driver only.
> 
> > If the intension is to update some of the charger-manager internal
> > parameters (struct charger_manager's struct charger_desc) according to
> > the temperature, we'd need a more general method that can also update
> values in the charger-manager context.
> >
> > For example, instead of simply putting a callback to determine whether
> > an update is required or not, a table of (including hysterisis)
> > temperatures and values to be updated (or callbacks to update
> > charger_desc based on the temperature) might be a starting point. You
> may also need to consider using notifier chain w/ temperatures.
> >
> Yes I agree, I will submit another patch with these changes.
> 
> As part of charge enablement we generally program charge current, charge
> voltage into the charger chip.
> 
> We can pass the charging parameters CC and CV in two ways.
> 1. Add these params in charger_desc struct and the  charger regulator can get
> these params using container_of() call? but becomes complex.
> 
> 2. use regulator_set_voltage()/regulator_set_current_limit() functions to set
> the CV and CC params.
> but not suitable as is, we have add support in regulator framework
> 

regulator_ops has support for set_current_limit and set_voltage. Can we use the same for setting CC and CV?

> 3. use regulator_get_drvdata()/regulator_set_drvdata() to set CC & CV
> params. These functions allow us to add more params in future if required.
> 
> I am thinking of using option 3.
> 
> Let me know your feedback.
> 
> Thanks,
> Ram
> 
> N떑꿩?툤y鉉싕b쾊Ф푤v??頻{.n?돴쪐{콗喩zX㎍.썳變
> }찠꼿쟺?j:+v돣?쳭喩zZ+?zf＂톒쉱?넮녬i鎬z?췿ⅱ?솳鈺??刪
> .f뷌^j푹y쬶끷@A첺뛴
> 
> 0띠h??i