linux-kernel - Re: [PATCH v3 1/4] hwmon: Driver for SMM665 Six-Channel Active DC Output Controller/Monitor

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: <52840892-BE40-44D3-9454-407B074481CC@opensource.wolfsonmicro.com>
Date:	Sun, 27 Jun 2010 20:54:06 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Guenter Roeck <guenter.roeck@...csson.com>
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	Jean Delvare <khali@...ux-fr.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Ira W. Snyder" <iws@...o.caltech.edu>,
	Hans de Goede <hdegoede@...hat.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Jonathan Cameron <kernel@...23.retrosnub.co.uk>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v3 1/4] hwmon: Driver for SMM665 Six-Channel Active DC Output Controller/Monitor

On 27 Jun 2010, at 16:10, Guenter Roeck wrote:

> On Sun, Jun 27, 2010 at 06:20:59AM -0400, Mark Brown wrote:

>> A bit late to the game here but this looks like the chip has some
>> regulator control functionality as well as monitoring functionality (and
>> the product page on the Summit web site suggests so also).  This means
>> that when fully supported in software the driver would cross multiple
>> subsystems so it might make sense to start off with a MFD rather than
>> direct I2C control?  
>> 
>> If the non-monitoring functionality can't be controlled from software
>> this isn't an issue.
> 
> I thought about that when I started working on the driver, but concluded that 
> it does not really make sense.
> 
> The chip is commonly used to control all supply voltages on a board.
> Changing those voltages is not a good idea. For that reason, the chip can be 

There's rather a lot of systems out there doing DVFS or using things like MMC
cards which would disagree with the idea that it's a bad idea to change supply
voltages at runtime. Even for fixed voltage supplies enabling and disabling at
runtime is useful to save power. I think it's fair to say that the overall trend is
towards more dynamic power management.

> set into read-only mode, where changing the voltages is no longer possible
> after initial programming.

This tends to be done through paranoia more than anything else - people get
very worried about things like accidental writes to their PMICs.

> While it is theoretically possible that someone might use the device to control
> not only fixed but also dynamic voltages, I think that is highly unlikely, given
> the risk involved in blowing up the board. Thus, moving the driver to mfd would 
> effectively serve no real purpose other than to cause confusion and add unnecessary

Pretty much any current generation CPU can use dynamic voltage configuration
for DVFS.--
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/