linux-kernel - 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: <1249986616.5807.28.camel@odin>
Date:	Tue, 11 Aug 2009 11:30:16 +0100
From:	Liam Girdwood <lrg@...mlogic.co.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Felipe Balbi <me@...ipebalbi.com>
Cc:	Mike Rapoport <mike@...pulab.co.il>, linux-kernel@...r.kernel.org
Subject: Re: Question about userspace-consumer

On Tue, 2009-08-11 at 10:40 +0100, Mark Brown wrote:
> On Tue, Aug 11, 2009 at 08:44:42AM +0300, Felipe Balbi wrote:
> > On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
> 
> > > Looking at that I'm not sure why you wish to push this into user space?
> 
> > we need some daemon monitoring battery statuses and taking actions on
> > that. Imagine, for example, usb charging where we can:
> 
> > a. charge up to 100mA when unconfigured
> > b. charge up to 500mA when configured
> > c. charge up to 2.5A when with dedicated charger
> > d. charge up to 2.5mA when bus is suspended
> 
> It's more complex than that - those are the limits at the USB port that
> define the power that can be drawn by the system.  The actual power
> available to the battery subsytem will be less since the rest of the
> system needs to be powered.  In many cases even with 500mA available
> the battery will need to be used to provide additional power in order to
> keep the system operational rather than being charged.
> 
> For USB powered operation at least some of the management here would
> usually be implemented in hardware to provide the responsiveness
> required.  Waiting for software to get involved would often allow the
> main system supply to collapse.
> 
> > handling all of those cases on kernel space seems a little bit odd,
> > especially because we still need to take care of state-of-charge,
> > pack temperature, time-to-charge, etc etc etc.
> 
> > a big looping polling for that stuff in kernel space didn't seem ok to
> > me.
> 
> No matter what you're still going to need at least some of the code
> in-kernel in order to handle the monitoring daemon exiting.  For
> example, if the battery is in fast charge then something will need to
> back the charger off at least as the charge completes (if not
> immediately user space exits) otherwise the battery or entire system is
> likely to be damaged.
> 
> Like I say some user space control does seem reasonable but I'd not
> expect an entirely user space implementation.

I agree, I think this probably deserves both user and kernel space
components although the dividing line between them is a little uncertain
atm. 

Generally, I'd expect the kernel side to provide a guaranteed *safe*
environment for charging wrt system stability and battery status. A
simple state machine would probably suffice.

I think userspace is where we would manage policy. We would also store
past battery history in order to better manage future charging and
charge level estimation. 

Liam

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