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.1211200921190.21420@axis700.grange>
Date:	Tue, 20 Nov 2012 09:23:41 +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 Tue, Nov 20, 2012 at 08:55:47AM +0100, Guennadi Liakhovetski wrote:
> > On Tue, 20 Nov 2012, Mark Brown wrote:
> 
> > > 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 
> 
> Well, there's not really many other options.
> 
> > 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.
> 
> Modern devices tend to use multiple GPIOs for this control for a jolly
> good reason.  If you've only got two levels then the wm831x algorithm is
> probably the most sensible.

Ok, I see, but other my comments still hold.

> > > > > 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 
> 
> I actually thought you'd just quoted the entire mail and just deleted
> the rest after a couple of screenfuls so a bit of both.  
> 
> > 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.
> 
> The extra content is profoundly unhelpful to people reading on phones,
> and to people on slow connections (I spend an awful lot of time in
> hotels with dodgy internet access for example).  It also (as happened to
> me) makes it hard to find new comments in the middle of reams of stuff
> you're paging down through.

Understand.

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