linux-kernel - Re: [RFD] voltage/current regulator consumer interface

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: <49EDD2A7.9090300@compulab.co.il>
Date:	Tue, 21 Apr 2009 17:05:27 +0300
From:	Mike Rapoport <mike@...pulab.co.il>
To:	James Kosin <jkosin@...a.intcomgrp.com>
CC:	linux-kernel@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [RFD] voltage/current regulator consumer interface

James Kosin wrote:
> Mike Rapoport wrote:
>> James Kosin wrote:
>>> 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.
>> Suppose you have a handheld device with GPS transceiver. You would like to give
>> user the ability to switch the transceiver on and off.
>>
> 
> Then the GPS drivers should be made aware and let the drivers handle the
> on/off interface.  If a user is allowed to turn interfaces on/off at
> will with this then drivers could suffer from (shock)...  ie: you could
> turn off your hard-drive in a middle of a write by the driver corrupting
> data, if handled in the driver it could finish the write before turning
> off the drive.  I know this is a far stretch from a GPS were the device
> is only READ only.

The point is there's no GPS driver... GPS transceivers are usually connected to
a serial line and the applications access the GPS data through ttySX. The case
when there is a kernel driver for device connected to a regulator is completely
different. It is then the driver responsibility to decide when to power on/off
the device.

> I do agree it could be useful, but we need to be careful on how much
> control the user has over the drivers and system.  To an extreme, a user
> could be able to turn off CPU cores outside of the drivers control
> causing serious pipeline hazards that would need to be handled at the
> driver level.  This would not be an issue for GPS were the data is read
> only and the missing data is really not that important to the system
> operation and continued use.
> 
> James
> 

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