linux-kernel - Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

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:	Wed, 30 Mar 2016 18:59:07 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Bjorn Andersson <bjorn@...o.se>
CC:	Mark Brown <broonie@...nel.org>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	"Bjorn Andersson" <bjorn.andersson@...ymobile.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gandhar Dighe <gdighe@...dia.com>,
	"Stuart Yates" <syates@...dia.com>
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based
 on platform behavior


On Saturday 19 March 2016 02:05 PM, Laxman Dewangan wrote:
>
> On Saturday 19 March 2016 10:01 AM, Bjorn Andersson wrote:
>> On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan 
>> <ldewangan@...dia.com> wrote:
>>>
>>>
>> Generally the device driver should describe the PMIC and the device
>> tree should describe the board. So the Maxim's numbers should (if
>> specified at all) go into the driver and the measures/calculated
>> characteristics for your board should be specified in the dt.
>>
>> The ramp properties in the generic regulator binding is used to inform
>> the OS about the board's ramp properties.
>>
>>
>> If I understand you correctly the Maxim PMIC can be configured to
>> drive the change at different speed, this should be configured through
>> a Maxim specific property. It should not reuse the generic properties
>> for ramp delays.
>>
>
> Ramp delay configurations are seen on other vendor's PMIC devices also.
> Therefore, I like o me generic property rather than specific to Maxim. 
> Parsing can be done in the core framework and applied during setting 
> machine constraints.

Any comment on this approach?

Like to add property as "regulator-device-ramp-delay" which will be used 
for PMIC configuration and regulator-ramp-delay will be used for delay 
calculation. This is case when advertised ramp delay does not match with 
the platform measured ramp delay.

If regulator-device-ramp-delay is not provided from platform then 
regulator-ramp-delay will be used for PMIC configuration as well as for 
the delay calculation. This is case when advertised ramp delay match 
with the platform measured ramp delay.