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: <Pine.LNX.4.64.1211200840590.21420@axis700.grange>
Date:	Tue, 20 Nov 2012 08:55:47 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
cc:	Laxman Dewangan <ldewangan@...dia.com>, lrg@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: max8973: add regulator driver support

On Tue, 20 Nov 2012, Mark Brown wrote:

> On Mon, Nov 19, 2012 at 11:52:42AM +0100, Guennadi Liakhovetski wrote:
> 
> > Thanks for submitting this driver! The notion of DVS regulators was new to 
> > me, so, I checked http://www.ti.com/lit/an/sbva020/sbva020.pdf for a short 
> > description. After that I had a look at a couple of existing DVS regulator 
> 
> Do you just mean regulators that have a quick voltage change ability/

Yes, regulators with an input pin, that can be used to switch output 
voltage on one of outputs.

> > drivers in the tree. Well, I came to two conclusions so far: (1) The 
> > current regulator API is not very well suitable for such regulators. I 
> > would imagine, one would need two methods: for setting the "normal" and 
> > the DVS voltage. Instead of this drivers are trying to be smart at 
> > guessing, which voltage the user is trying to set now... (2) Drivers do 
> > this in different ways and at least out of the 2 drivers I looked at both 
> > have bugs and different ones at that. I'll send a separate email, 
> > describing what I found suspicious in them.
> 
> The thing I'd like to see factored out here is the LRU mechanism,
> otherwise I think the situation is pretty good.  Some of the older
> devices should use a different scheme to modern ones as the hardware
> they have to interoperate is different.

So, do you consider the LRU algorithm to be the preferred way to configure 
such regulators? I realise that in practice it will work well in most 
cases, usually users do only want to preconfigure such a regulator to 2 
fixed voltages and switch between them at runtime, right? OTOH, do you 
think it is too unlikely, that someone will want to switch, say, between 3 
voltages: X-Y-Z-X-Y-Z-X...? In this case the LRU will just lead to 
constantly reprogramming the regulator. Whereas if the user had a way to 
say "configure context A to X," "B to Y," and then only reprogram B 
between voltages Y and Z, we'd save 1/3 of re-configuration accesses? 
Maybe even in some such case, quickly switching to voltage X is more 
important than to voltage Y or Z.

> > Of course, all the above was just my DVS-newbie impression, which can very 
> > well be absolutely wrong.
> > 
> > > 
> > > Add regulator driver for this device.
> 
> *ALWAYS* delete irrelevant text when replying.

Not sure what you mean, sorry. If you mean all the text, that followed the 
above line, then it wasn't all irrelevant, there were more comments down 
there. OTOH, if you just meant, that I could have deleted even more text, 
than what I've done, then right, sorry, there's always a balance between 
deleting too little and too much, and the decision is subjective. I 
usually tend to keep somewhat more, tnan most would consider required, I 
think, it is easier to hit "Page Down" a couple more times, than to have 
to guess what the missing context was. But I'll try to reduce unneeded 
context next time.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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