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: <4A815F64.8000105@compulab.co.il>
Date:	Tue, 11 Aug 2009 15:09:08 +0300
From:	Mike Rapoport <mike@...pulab.co.il>
To:	me@...ipebalbi.com
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: Question about userspace-consumer

Felipe Balbi wrote:
> On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
>> On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:
>>
>> The existing drivers for this sort of functionality are all regular
>> kernel drivers (in drivers/power and to a lesser extent drivers/hwmon)
>> and it looks like it'd be at least as much work to rearrange the power
>> supply stuff to support userspace drivers.  My initial expectation would
> 
> power supply already does what it needs, no ? It exports battery
> figures (state-of-charge, time-to-charge, temperature, etc etc) via
> sysfs to userland, where our "charging daemon" could read those values
> from.
> 
>> be for a generic driver with some policy exposed to user space and some
>> configuration exposed for architecture code (especially for setting up
>> multi-battery board layouts and things).  That's not a terribly informed
>> opinion, though.

+1

>>> For doing that, probably userspace-consumer would have to be able to
>>> set_voltage/get_voltage, set/get_current_limit and so on. So I was
>>> thinking on changing userspace-consumer to use regulator_get() instead
>>> of regulator_bulk_get() and make each instance of userspace-consumer to
>>> talk to only and only one regulator.

I don't think that a battery charger should identify itself like a regulator
device. It seems to me that charger driver belongs completely to the power
supply subsystem and if there's a need to add policy enforcement functionality,
it should be added to the power supply subsystem.
Moreover, extending userspace-consumer driver for battery charger needs is too
dangerous. You have to ensure that *all* critical conditions are handled
in-kernel, no matter what userspace policy is.

> I think kernel should, as long as possible, only provide functionalities
> for userland to take decisions and actions, no ?
> 
> Handling policy in kernel space I find it a little odd, specially
> because different manufacturers might have different charging algorithms
> they want to implement.

It depends on how do you define policy. If the policy includes e.g. over-charge
and over-temperature than it should be handled in-kernel.

> that said, power supply framework and regulator framework seem to be
> well enough for implementing the basic support for SBS-enabled charging
> scheme.

As far as I understood SBS scheme, the host has very little impact on the
charging process. Most of the charging is handled by Smart Battery and Smart
Battery Charger without any host intervention.


-- 
Sincerely yours,
Mike.

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