linux-kernel - Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding

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: <CAL_JsqKV=AucyZvFaxsSrZ5Hn718ZMKDfd8pqLHFT27RbE7VMA@mail.gmail.com>
Date:	Wed, 9 Dec 2015 15:08:51 -0600
From:	Rob Herring <robh@...nel.org>
To:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
Cc:	"Bird, Tim" <Tim.Bird@...ymobile.com>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"sre@...nel.org" <sre@...nel.org>,
	"dbaryshkov@...il.com" <dbaryshkov@...il.com>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"agross@...eaurora.org" <agross@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tbird20d@...il.com" <tbird20d@...il.com>,
	"Cavin, Courtney" <Courtney.Cavin@...ymobile.com>
Subject: Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding

On Wed, Dec 9, 2015 at 1:59 PM, Bjorn Andersson
<bjorn.andersson@...ymobile.com> wrote:
> On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote:
>
>> On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird <tim.bird@...ymobile.com> wrote:
>> > On 12/08/2015 08:11 PM, Rob Herring wrote:
>> >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote:
>> >>> Add a binding for the regulator which controls the OTG chargepath switch.
>> >>> The OTG switch gets its power from pm8941_5vs1, and that should be
>> >>> expressed as a usb-otg-in-supply property in the DT node for the
>> >>> charger driver.  The regulator name is "otg".
>>
>> [...]
>>
>> >>> +child nodes:
>> >>> +- otg:
>> >>> +  Usage: optional
>> >>> +  Description: This node defines a regulator used to control the direction
>> >>> +               of VBUS voltage - specifically: whether to supply voltage
>> >>> +               to VBUS for host mode operation of the OTG port, or allow
>> >>> +               input voltage from external VBUS for charging.  In the
>> >>> +               hardware, the supply for this regulator comes from
>> >>> +               usb-otg-in-supply.
>> >>
>> >> Doesn't this regulator need to have a name defined?
>> >
>> > I'm not sure what you mean.  The regulator name is "otg", defined by the DT node
>> > name. The code requires that the DT node name be "otg", and defines a regulator
>> > with the same name.
>> >
>> > As far as I know, you have to define a DT label for the node, in order
>> > to reference this regulator with a phandle.  Is that what you are referring to?
>> > I usually use "chg_otg" as the label.  Are you asking that this be reflected
>> > in the example?
>>
>> You need a regulator-name property. Also, should should define valid
>> values for regulator-min-microvolt and regulator-max-microvolt.
>>
>
> The regulator has a name, derived from the node name, and this is
> significant. If the developer wants an additional human readable name
> for some reason they can use the optional regulator-name property.
>
> The regulator is a simple switch and as such inherits voltage properties
> from its supply. It should therefor not have any specified voltage
> range.
>
>> Thinking about this some more, the node name should be generic, so
>> just "regulator". The label does not need to be generic.
>>
>
> The name of the node is significant, as it's used for matching the
> regulator to an implementation.

Ah yes, you are right. I forget what an oddball the regulator binding is.

And if voltage switches don't need min and max properties, then it is
fine as is. Still, the empty node with no properties seems odd to me.

Rob
--
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/