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-next>] [day] [month] [year] [list]
Date:	Mon, 20 Apr 2009 11:38:49 -0400
From:	James Kosin <jkosin@...a.intcomgrp.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [RFD] voltage/current regulator consumer interface

Mike Rapoport wrote:
> Hi,
> 
> Recently there was a brief discussion on linux-arm-kernel list [1] about
> controlling voltage regulator state in cases when there is no consumer device
> for a particular regulator.
> 
> I have some thoughts but I'd like to know people opinion before I start
> implementation.
> 
> Problem
> -------
> The regulator framework API provides ability to control the state of
> voltage/current regulators from within the kernel. Usually the regulator
> supplies power to a device and device driver or some hooks to the platform code
> from the device driver manipulate the regulator state. However, the regulator
> framework does not have userspace ABI that allows regulator state modifications.
> Lack of this ABI prevents fine-grained control for power consumption of devices
> such as GPS trancievers and GSM modems. Moreover, in SoC based systems it is
> possible to switch on/off power to entire subsystem when it is not used.
> 


I'd also ask the question, Why?
If exposing to user space it leaves the possibility of damaging hardware
or completely frying a board.

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