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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Jun 2009 15:28:00 -0400
From:	"Richard A. Smith" <richard@...top.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Andres Salomon <dilinger@...labora.co.uk>, cbou@...l.ru,
	dwmw2@...radead.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Fox <pgf@...top.org>, dsaxena@...top.org
Subject: Re: [PATCH 3/5] power_supply: add a TRICKLE_CHARGING status, and
 add it to the olpc driver

Mark Brown wrote:

> On Mon, Jun 22, 2009 at 11:46:07PM -0400, Andres Salomon wrote:
> 
>> The hardware has an extra bit that specifies that the battery is trickle
>> charging, so when determining if the battery is present/charging the TRICKLE
>> bit needs to be checked as well.  Because battery diagnostics might want to
>> know whether trickle charging is happening or not, and also because trickle
>> charging falls somewhere between charging and not charging (read: Richard got
>> mad at me when I tried to set CHARGING when in trickle charge.  He gets so
>> angry sometimes), we add a new TRICKLE status to sysfs.
> 
> To avoid confusing usere applications might it be better to add another
> piece of information with detail on the charger status rather than a new
> state?  The fact that the new state name shares a prefix with the
> regular charging state does help here but you might still confuse things
> and it makes the name of the new state in sysfs a bit awkward.
> 
> I'd also be tempted to do this the other way around and add a fast
> charge status; certainly in embedded cases trickle charging is more of a
> default state since it requires less incoming power (important if you're
> using USB) and there's less risk of damage to the battery.

On the OLPC the trickle charging really is a trickle rather than just a
slower charge rate.  To fully charge a XO battery at trickle would take
about 150 hours.

Trickle is enabled when the battery voltage has dropped outside of the
normal charging envelope.  In that zone the battery voltage curve is
very non-linear so even small currents will make the voltage rise
quickly.  Once the voltage hits the safe zone regular the normal
charging rate is enabled.

I don't have any strong feelings about what nomenclature we use to
describe it.  I just want it to be a separate identifiable state (or
status).  In (OLPCs) normal charging/discharging cycle the trickle zone 
should not be reached so its an indication that you are outside the 
envelope.  If it shows up repeatedly then its an indication that 
something is amiss.

My front line for diagnosing battery problem out in the field is a small 
script that logs various bits of info from the battery system every 10 
seconds.  If its run on a charge/recharge cycle then it gives a pretty 
good picture of whats going on with the battery.

I would prefer that the stuff returned from sysfs is unique, short yet 
descriptive.  It helps if I don't have to grovel around in multiple 
locations and do boolean logic to come up with what state of the 
charging profile is active.

That makes it easy to describe how to use the info in the diagnostic 
documentation we give to deployments and keep my simple script simple.

It also aids in my processing programs that loop over my (growing) 
collection of log files looking for trends and other statistical items.

-- 
Richard Smith  <richard@...top.org>
One Laptop Per Child

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