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: <20090810215800.GB4528@sirena.org.uk>
Date:	Mon, 10 Aug 2009 22:58:01 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Felipe Balbi <me@...ipebalbi.com>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	Mike Rapoport <mike@...pulab.co.il>,
	linux-kernel@...r.kernel.org
Subject: Re: Question about userspace-consumer

On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:

> I was reading userspace-consumer file ad was wondering whether would be
> possible to use that in order to implement what SBS-IF [1] proposes
> using sbs-enabled devices.

Looking at that I'm not sure why you wish to push this into user space?

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

> 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'd like to preserve the bulk switch if possible - part of the thinking
was that things with more complex needs may well find it easier and/or
more robust to have custom kernel stubs which mapped one or more
regulators into the interfaces they needed.  That was more for things
like working out which of multiple supplies is which, though.

The existing virtual consumer, while intended as a test harness
originally and rather clunky as-is, is much closer to your needs.  It is
the way it is partly as a sign that you really shouldn't be using it in
production (which seems to be working!).

> Anyways, how do you guys feel about it ?

Like I say, from a quick read through of the specs I'm not sure that I'd
push this into user space but I've not thought about this deeply and may
be missing something.
--
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/