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:	Mon, 14 Jul 2014 11:24:35 +0200
From:	Thierry Reding <>
To:	Mark Brown <>
Cc:	Tuomas Tynkkynen <>,
	Andrew Bresticker <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	Prashant Gaikwad <>,
	Mike Turquette <>,
	Stephen Warren <>,
	Viresh Kumar <>,
	Peter De Schrijver <>,
	"Rafael J. Wysocki" <>
Subject: Re: [PATCH 01/13] clk: tegra: Add binding for the Tegra124 DFLL

On Mon, Jul 14, 2014 at 10:12:33AM +0100, Mark Brown wrote:
> On Mon, Jul 14, 2014 at 10:38:56AM +0200, Thierry Reding wrote:
> > On Fri, Jul 11, 2014 at 08:21:27PM +0300, Tuomas Tynkkynen wrote:
> > > I don't think we can assume that each selector maps to a concrete register
> > > value, though I'm not sure. include/linux/regulator/driver.h documents for
> > > @list_voltage "Selectors range from zero to one less
> > > regulator_desc.n_voltages." but maybe the consumer API could take different
> > > values.
> > I don't think the regulator API makes any guarantees that the selector
> > corresponds to a register value. Adding Mark Brown, maybe he can help
> > figure out the best way to do this.
> The selector value is opaque, it's entirely up to the driver to define
> it.  If you could tell me what "this" is I might be able to advise on
> how to do it.

Tegra124 (and later, also some earlier variants) have this DFLL clock
that can program a PMIC automatically depending on the CPU frequency.
This DT binding did propose putting this into device tree as a table of
<frequency value> pairs where the frequency corresponds to the CPU
frequency and the value is the register value to be programmed into the
PMIC by the DFLL hardware (there are two additional properties to define
the slave address and the register offset).

Andrew proposed that this table could instead be built by using
regulator_list_voltage() instead. However, due to the fact that the DFLL
hardware needs to know the immediate value to write into a register, the
requirement would be for a 1:1 mapping between selector and register
value. Given that the API needs to cover the general case I don't see
how it could practically ensure this.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists