linux-kernel - Re: [PATCH 1/2] regulator: core: add support to get VSEL register from hw 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]

Date:	Fri, 29 May 2015 10:49:41 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	lgirdwood@...il.com, linux-kernel@...r.kernel.org,
	cfreeman@...dia.com, abrestic@...omium.org, afrid@...dia.com
Subject: Re: [PATCH 1/2] regulator: core: add support to get VSEL register
 from hw driver

On Fri, May 29, 2015 at 11:21:36AM +0530, Laxman Dewangan wrote:

> In our system, CPU-DFLL is another HW module which controls the CPU voltage
> based on CPU frequency request. It issues the i2c command to the device for
> voltage change when frequency get change. For this reason, CPU-DFLL need the
> VSEL register address. The CPU DVFS SW driver controls the DVS input pin to
> control sleep entry/exit and VOUT0 for voltage change. So on this case, we
> really donot need to change the VSEL register address for active state
> voltage change and use the DVS for sleep entry/exit.

Sure, that's the normal use case for this stuff.

> The problem will be there when external controller use the DVS pin for DVFS
> and need two register address here. In this case, I think external
> controller need to get information from different mechanism rather than via
> regulator driver to avoid complication on regulator driver/framework.

Probably, it's definitely getting complicated (though in this case where
we only need one register we ought to be more able to manage it, not
that I have bright ideas right now).

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)