linux-kernel - Re: [PATCH V4 1/5] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024

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: <20160127072430.GD3368@x1>
Date:	Wed, 27 Jan 2016 07:24:30 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linus.walleij@...aro.org, gnurou@...il.com, broonie@...nel.org,
	a.zummo@...ertech.it, alexandre.belloni@...e-electrons.com,
	lgirdwood@...il.com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	rtc-linux@...glegroups.com, swarren@...dia.com, treding@...dia.com,
	k.kozlowski@...sung.com, vreddytalla@...dia.com
Subject: Re: [PATCH V4 1/5] DT: mfd: add device-tree binding doc fro PMIC
 max77620/max20024

On Tue, 26 Jan 2016, Laxman Dewangan wrote:

> 
> On Tuesday 26 January 2016 08:28 PM, Lee Jones wrote:
> >On Mon, 25 Jan 2016, Laxman Dewangan wrote:
> >
> >>Hmm. I describe the boolean and tristate only. Do I need to define
> >>type for integer,string also?
> >I wouldn't describe any of them.  It's normally pretty obvious which
> >properties are boolean by the lack of required cell description.
> >
> 
> Rob suggested to use the type also for Boolean and tristate. I think
> it is good to have for all places that what type of values are
> valid.

It's fine, and some people do describe them.  I've just never seen the
point, especially if you have a nice example of their use in the
document.  But if you insist, please ensure you are consistent, so
*all* bools need to be described.  That is not currently the case.

> >>>>+The property for fps child nodes as:
> >>>>+Required properties:
> >>>>+	-reg: FPS number like 0, 1, 2 for FPS0, FPS1 and FPS2 respectively.
> >>>I'm surprised Rob Acked this.  We don't usually do device numbers in DT.
> >>What is best way to make the child node for FPS and differentiate FPS0,1, 2?
> >>What is your suggestion here?
> >There are lots of ways you can solve this and so many examples of
> >others doing so.  I suggest you have a look at some DTS files and
> >figure it out.  One possible solution is to use different compatible
> >strings.
> Here, I think I can go similar to regulators where child node name
> identifies the regulators.
> 
>     fps-config {
>         fps0 {
>             maxim,fps-time-period-us = <1280>;
>             maxim,fps-enable-input = <FPS_EN_SRC_EN0>;
>         };
> 
>         fps1 {
>             maxim,fps-time-period-us = <2560>;
>             maxim,fps-enable-input = <FPS_EN_SRC_EN1>;
>         };
> 
>         fps2 {
>             maxim,fps-time-period-us = <640>;
>             maxim,fps-enable-input = <FPS_EN_SRC_SW>;
>         };
>     };
> 
> So node name gives the FPS name.

That is also an acceptable means to solve the issue.

As I said, there are many ways to skin a cat.

> >>>+Pinmux and GPIO:
> >>>+===============
> >>>I think this whole section needs moving to ../pinctrl and needs to be
> >>>reviewed by Linus W.
> >>Is this mean I need to create DT binding doc for the each subsystem
> >>differently?
> >>Actually during AS3722, I had different understanding to have single file.
> >Yes, that way you have each of the the subsystem experts review your
> >documentation.  You can then link to them from this document.
> OK, I will add different dt binding doc in respective driver and
> squash that with respected submodule drivers.
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog