linux-kernel - Re: [PATCH V1] TPS62360: Add tps62360 regulator driver

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