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] [day] [month] [year] [list]

Message-ID: <20100627220709.GA7072@ericsson.com>
Date:	Sun, 27 Jun 2010 15:07:09 -0700
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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 Sun, Jun 27, 2010 at 03:54:06PM -0400, Mark Brown wrote:
> 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.
> 
Ok, I'll accept that.

Even then, I think it would make more sense to stick with the current approach.
If someone wants to extend the driver at some point in the future to support
regulator functionality, it would be straightforward to create the necessary
mfd framework for the chip at that time. After all, the hwmon driver and with it
most of the current code would still be required.

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