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: <20120109071128.GA22134@opensource.wolfsonmicro.com>
Date:	Sun, 8 Jan 2012 23:11:29 -0800
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	Laxman Dewangan <ldewangan.com@...dia.com>,
	"lrg@...mlogic.co.uk" <lrg@...mlogic.co.uk>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH V1] TPS62360: Add tps62360 regulator driver

On Mon, Jan 09, 2012 at 12:34:25PM +0530, Laxman Dewangan wrote:

> In my design, the voltage vary from 900mV to the 1300mV in increment of
> 50mV. In this case, the voltage change request is 900, 950, 1000, 1050,
> 1100, 1150, 1200, 1250, 1300.
> I would like to have entry like
> 900-950->vsel0
> 950-1000>vsel1,
> 1000-1050->vsel2
> 1050-1100->vsel3
> 1100-1150->vsel0
> 1150-1200->vsel1
> 1200-1250->vsel2
> 1250->1300->vsel3

Why?  I'm not sure I understand this.  You're asking the regulator to
output ranges not voltages and you're setting multiple overlapping
ranges for each VSEL.

> Based on voltage increment requirements for a given application, this
> table can be tune more. Now if client request for voltage setting for
> range of 1000-1050, I will select the VSET1 for configuration, similarly
> for 1100-1150, VSET0 will be the configuration register.

This just seems like it makes the driver configuration much more
complex and restricts the ability of the system to adapt itself to
what's happening at runtime.

What I'd expect to see is nothing but the GPIOs and their default state
(since sadly we can't read back from output GPIOs with gpiolib) being
specified.
--
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