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]
Date:	Sun, 27 Jun 2010 08:10:47 -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 06:20:59AM -0400, Mark Brown wrote:
> On Thu, Jun 24, 2010 at 03:00:58PM -0700, Guenter Roeck wrote:
> > This driver adds support for the monitoring features of the Summit
> > Microelectronics SMM665 Six-Channel Active DC Output Controller/Monitor.
> 
> 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 
set into read-only mode, where changing the voltages is no longer possible
after initial programming.

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
complexity.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ