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]

Message-ID: <96C9D994977DD0439FB6D3FE3B13DD907DBD3AA0E4@BGMAIL01.nvidia.com>
Date:	Sun, 8 Jan 2012 13:12:47 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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 Sunday, January 08, 2012 12:41 AM +5:30, Mark Brown Wrote

> > In the platform data, I will take 4 sets of regulator_init_data
> > corresponding to VSEL0/1. If client is not interested in all and tied
> > to fixed high/low, he will just pass NULL to unused index and proper
> > information to used option.
> 
> Taking multiple different regulator_init_data is definitely not what we
> want, there's a whole bunch of information in there, not just the
> voltages.  You should just use platform data to specify the GPIOs (and
> a set of voltages if you go with that approach).

How do you pass the voltages along with gpios? If I understand correctly
then it may be wither in range form or discrete form.
Like in range form 500-700 for VSEL:00, 710-800 VSEL:01 etc.
In discrete form VSEL00:500, 540, 550..
For, VSEL01, VSEL00:510, 900,

In range form, the disadvantages is that, most of time, the voltage
requirement is surrounding operating voltage and so it will use only
one combination of VSEL in most of time and will not get the benefit.
The discrete form have long list of voltage and filling table is pain.
Also need to maintain the big list of lookuptable to select voltage
configuration register.

If above is not correct then can you please help on understanding how
the information will be pass from platform data?

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