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: <20120813173847.GH13446@opensource.wolfsonmicro.com>
Date:	Mon, 13 Aug 2012 18:38:47 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Matt Sealey <matt@...esi-usa.com>
Cc:	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>,
	Steev Klimaszewski <steev@...esi-usa.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device
 tree

On Mon, Aug 13, 2012 at 10:42:58AM -0500, Matt Sealey wrote:
> On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown

> > This and many of your other regulators have voltage ranges specified but
> > no consumers which doesn't make sense.  It looks awfully like you've
> > just typed in the maximum range supported by the regulator which is most
> > likely broken.

> Okay I have a question about this; some of the regulators (SW1
> especially) are obviously consumed by the CPU core complex so that
> when DVFS gives us a hint we can clock down and reduce voltage. How on
> earth do we implement that?

> We can drop the maximum range to be better for the CPU (1.3V is too
> high, I think this is legacy from when we may have had a sorted 1GHz
> MX51 coming out) but I can't find any source for where this is hooked
> in.

DVFS doesn't use the device model in Linux (yet!) so there's no device
node and it's all a bit messy.  Shawn Guo is working on some generic DT
bindings for it which should solve that problem but for now in the
specific case of CPU bindings it's OK to not have an consumer, it's
understandable what's going on there.
--
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