linux-kernel - Re: [RFC PATCH v1 1/3] regulator: helpers: consider constriants in list_voltage_linear

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: <57501E3C.3060308@linaro.org>
Date:	Thu, 2 Jun 2016 12:53:32 +0100
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	bjorn.andersson@...aro.org, linux-kernel@...r.kernel.org,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-arm-msm@...r.kernel.org
Subject: Re: [RFC PATCH v1 1/3] regulator: helpers: consider constriants in
 list_voltage_linear_range



On 02/06/16 12:05, Mark Brown wrote:
> On Thu, Jun 02, 2016 at 11:23:14AM +0100, Srinivas Kandagatla wrote:
>> Regulator drivers can have linear range which is according to the
>> regualtor hardware spec, however the board level device tree files
>> can restrict this range by adding constriants.
>> These constriants are not considered in the exsiting code, which
>> gives false supported voltage range to the consumers.
>
> ...
>
>> For now I have added this support for regulator_list_voltage_linear_range()
>> If it makes sense we can extend this to other list voltage helpers too.
>
> Why are you making this change?  The obvious problem here is that drivers
> should not be looking at constraints - it would be silly to duplicate
> constraint enforcing code in individual drivers and would lead to
> inconsistent performance of constraints.  This is why we do this in the
> core, in _regulator_list_voltage(),
Yep, you are right, I should have looked into _regulator_list_voltage() 
in more carefully, it already has this check in place.

--srini