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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Apr 2009 10:31:34 -0400
From:	James Kosin <jkosin@...a.intcomgrp.com>
To:	Mike Rapoport <mike@...pulab.co.il>
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

Mike Rapoport wrote:
> 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
>>
> 
Ok.  You have a valid point.

What about a GPS driver that can use the RS232 interface as the
transport.  Much like the IDE over Parallel Port in older kernels did.
This way the driver would still be responsible and not have to
completely expose the regulator control.

James


Download attachment "signature.asc" of type "application/pgp-signature" (259 bytes)