linux-kernel - Re: [PATCH 0/13] Updated V4

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]

Message-ID: <20080508063538.GC6105@prithivi.gnumonks.org>
Date:	Thu, 8 May 2008 08:35:38 +0200
From:	Harald Welte <laforge@...monks.org>
To:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	arm kernel <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH 0/13] Updated V4  - Regulator Framework

On Fri, May 02, 2008 at 04:40:41PM +0100, Liam Girdwood wrote:
> This is an updated version of the kernel voltage & current regulator
> framework based on comments received from version 3 of the patch series.
> 
> The regulator framework is designed to provide a standard kernel
> interface to control voltage and current regulators on SoC based
> systems.

Dear Liam,

I have reviewed your regulator framework from the point of view of the
Openmoko GTA01 and GTA02 devices, based on members of the NXP PCF506xx
PMU(PMIC) devices (for which I wrote the drivers). 

I believe it would fit quite nice onto this PMIC family from a different
manufacturer.

There is one aspects of the PCF506xx that I think the current regulator
framework doesn't (yet) cover.  I'm not sure if it was worth to add
support for this, but let me explain:

The PCF506xx have a concept of global power management states,
particularly important are the ON and STANDBY states in this context.
Every regulator has a property whether it is enabled in none, one or
both of the global power management states.

Do you think it would be worth to export something like this in the
generic API, too?  It's probably quite hard, since there are devices
that actually use the PCF506xx STANDBY state during suspend-to-ram, but
other devices leave the PCF506xx in the ON state and just disable the
individual regulators using I2C register writes.

I think there's probably no clean way how to integrate this, since the
question remains: who makes the decision (and manages the contraints) of
when to transition into the STANDBY state.   Nevertheless a read-only
sysfs attribute might still be interesting.

Cheers,
-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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