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: <20151209185606.GE5727@sirena.org.uk>
Date:	Wed, 9 Dec 2015 18:56:06 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Tim Bird <tim.bird@...ymobile.com>
Cc:	Rob Herring <robh@...nel.org>,
	"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>,
	Andersson, Björn 
	<Bjorn.Andersson@...ymobile.com>,
	"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 09, 2015 at 09:42:09AM -0800, Tim Bird wrote:
> On 12/09/2015 06:36 AM, Rob Herring wrote:

> > You need a regulator-name property. Also, should should define valid
> > values for regulator-min-microvolt and regulator-max-microvolt.

> All of those are listed as optional properties in
> Documentation/devicetree/bindings/regulator/regulator.txt.

I have to say I'm also a bit confused about why a binding using a
regulator would need to do anything other than reference that document
except in cases where using some functionality enabled by the generic
bindings is a key part of the functionality of the device (which do tend
to be rare).

> The regulator-name seems redundant, since the name of the DT
> node becomes the regulator name in the Linux system.  This is

The purpose of the regulator-name property is to allow you to put in a
descriptive name for the supply which would normally correspond to the
name the supply is given on the schematic and may not fit into the DT
conventions.  It is entirely optional but strongly recommended to aid
people in understanding how both the DT and the running kernel relate to
the schematic.

> not currently used anywhere, as the node is "connected up" via
> phandle, which uses the label.  That is, there's no code in
> the kernel that looks up this regulator by name, although it
> does get a name.

The name is purely for use by humans in logs and/or userspace, it is not
used in the kernel.

> As for the microvolt references, I'm a little stumped what
> to do with those.  I could use regulator-min-microvolt of 0
> and a regulator-max-microvolt of 500000, but that's not
> exactly right.

You should only specify voltages if the intention is to either allow
consumers to vary voltages at runtime or have the kernel set a specific
voltage for the regulator (eg, if the hardware defaults are wrong).

> This is actually representing a voltage switch, which is being
> represented in the regulator framework in Linux, because it
> seems to fit there best.  It has regulators it's related
> to, which should be adjusted when this one is.  However, it
> intrinsically does not have a voltage of it's own, so it's a
> bit of a weird case.  And the voltage can either be going
> "out" or "in".

If you want consumers of the supply to be able to vary the voltage you
need to permit that on the child supply as well as the parent supply so
we know we can pass requests up.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)