linux-kernel - Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

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: <20090822141646.GA5812@sirena.org.uk>
Date:	Sat, 22 Aug 2009 15:16:47 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Felipe Balbi <me@...ipebalbi.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Mike Rapoport <mike@...pulab.co.il>,
	linux-kernel@...r.kernel.org
Subject: Re: Smart Battery System Design (was: Re: Question about
 userspace-consumer)

On Fri, Aug 21, 2009 at 04:01:26PM +0200, Pavel Machek wrote:
> On Sat 2009-08-22 11:16:42, Mark Brown wrote:

> > Like you say this is a very old design but even there I'm fairly
> > surprised it's causing issues when charging from a wall supply.  If
> > you're charging from USB then there is obviously a constraint on the
> > power draw but normally a modern system has sufficiently low power draw
> > when idle that it's not actually a big deal - runtime power management
> > facilities have improved greatly.

> Well... all the hardware I have here (zaurus, openmoko, htc dream) has
> issues with power consumption while charging... so I do not think
> runtime pm is solved problem.

The Zaurus and OpenMoko aren't exactly modern designs.  The Dream does
surprise me, though.  I can't find any references to issues with this -
any pointers?  If the phone were actually in use I'd expect it to have
trouble charging off USB but sitting idle it's a lot more surprising,
especially running Android.

> While crashes during suspend/resume are common on pcs, embedded
> systens do better. And crashes during runtime happen, too.

Not really; the situation is similar in both cases - if your hardware is
well supported then everything will generally run smoothly.  If your
hardware is not so well supported then things get more interesting.
It's probably fair to say that it's easier to fix embedded systems that
don't work (and as a result to find existing ones that work well) but
it's not massively different, especially if you're working with things
like reference hardware for new devices.

> First, I can't imagine system where you can damage the battery by just
> crashing sw. 4.2 per cell voltage limit is just too easy to do in
> hw. Maybe if you crash the sw then bring the machine outside while its
> stil on charger and theres 110F outside...

Remember that the goal here is to pull the charging algorithm out of the
charger where it currently is and base it on data supplied by the
battery instead.  If SBS is implemented in software it's not clear that
the charger is going to be able to do anything for itself except
possibly shut off if it or the battery goes over temperature (since SBS
does require NTC those should both be possible).

> And yes it should have safety features, and if they are not there its
> broken hw.

That's not unambiguously clear.  Even with current charger designs some
of the safety comes from appropriate configuration being provided to the
hardware by software - things like the maximum charging current which
the design can sustain.  The unavoidable safety limits provided by the
components tend to be high and while they should prevent catastrophic
issues you normally don't want to be relying on them during normal
operation.
--
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/