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] [day] [month] [year] [list]
Message-ID: <CAK9yfHyrKR27Z=S4ZuS5ZuJKjiVxFQXe4=izXyJMRs8c+-PuMg@mail.gmail.com>
Date:	Thu, 13 Feb 2014 11:47:19 +0530
From:	Sachin Kamat <sachin.kamat@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"sbkim73@...sung.com" <sbkim73@...sung.com>,
	"lee.jones@...aro.org" <lee.jones@...aro.org>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCH v2 3/3] Documentation: mfd: Add binding document for S2MPA01

Hi Mark,

On 12 February 2014 23:40, Mark Rutland <mark.rutland@....com> wrote:
> Hi Sachin,
>
> Apologies for the delay on this.

No problem :). Thank you for your review. Please see my comments inline.

>
> On Thu, Jan 09, 2014 at 11:22:34AM +0000, Sachin Kamat wrote:
>> Added initial binding documentation for S2MPA01 MFD.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@...aro.org>
>> ---
>> * Re-organised as suggested by Mark Rutland.
>> ---
>>  Documentation/devicetree/bindings/mfd/s2mpa01.txt |   86 +++++++++++++++++++++
>>  1 file changed, 86 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
>> new file mode 100644
>> index 000000000000..70879b92b24b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
>> @@ -0,0 +1,86 @@
>> +
>> +* Samsung S2MPA01 Voltage and Current Regulator
>> +
>> +The Samsung S2MPA01 is a multi-function device which includes high
>> +efficiency buck converters including Dual-Phase buck converter, various LDOs,
>> +and an RTC. It is interfaced to the host controller using an I2C interface.
>> +Each sub-block is addressed by the host system using different I2C slave
>> +addresses.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,s2mpa01-pmic".
>> +- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
>
> Is the slave address not per-instance in I2C? If not why must is be 0x66?

Mark Brown already replied to this. Thanks Mark.

>
>> +
>> +Optional properties:
>> +- interrupt-parent: Specifies the phandle of the interrupt controller to which
>> +  the interrupts from s2mpa01 are delivered to.
>> +- interrupts: Interrupt specifier for interrupt source (connected to SoC).
>
> The part in brackets can go. Assuming this is a single interrupt:

OK.

>
> - interrupts: An interrupt-specifier for the sole interrupt generated by
>   the device.
>
> If the interrupt has a name it would be nice to mention that. If there
> are more than one you should describe them.
>
>> +
>> +Optional nodes:
>> +- regulators: The regulators of s2mpa01 that have to be instantiated should be
>> +  included in a sub-node named 'regulators'. Regulator nodes and constraints
>> +  included in this sub-node use the standard regulator bindings which are
>> +  documented elsewhere.
>> +
>> +Properties for BUCK regulator nodes:
>> + regulator-ramp-delay for BUCKs = [6250/12500(default)/25000/50000] uV/us
>
> This could be made easier to read:
>
> - regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
>   (default), 250000, or 50000. May be 0 for disabling the ramp delay on
>   BUCK{1,2,3,4}.

Yes. Will update.

>
>> +
>> + BUCK[1/2/3/4] supports disabling ramp delay on hardware, so explictly
>> + regulator-ramp-delay = <0> can be used for them to disable ramp delay.
>> + In the absence of the regulator-ramp-delay property, the default ramp
>> + delay will be used.
>
> Can be folded into the above, as in my example.

Right.

>
>> +
>> +  NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
>> +  for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
>
> Missing '=' before <value>?

Yes. Thanks for pointing out.

>
>> +  Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
>> +  BUCK[2, 4], and BUCK[8, 9, 10]
>
> The following BUCKs share ramp settings:
> * 1 and 6
> * 2 and 4
> * 8, 9, and 10

OK.
-- 
With warm regards,
Sachin
--
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