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: <20151210142712.GM5727@sirena.org.uk>
Date:	Thu, 10 Dec 2015 14:27:12 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Sebastian Reichel <sre@...nel.org>
Cc:	Tim Bird <tim.bird@...ymobile.com>, 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>,
	"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 11:20:45PM +0100, Sebastian Reichel wrote:
> On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote:

> > There are other switches in the charger block that are not
> > exposed yet.  This one handles the the OTG (vbus) charge pathway.
> > Others handle other charge pathways (some of which are used on phones
> > and some are not - they're used, e.g., on the dragonboard).  I'd
> > rather not give it a generic name, because eventually the driver
> > should expose those other switches as something as well.

> otg_regulator: regulator@0 { }
> other_regulator: regulator@1 { }

No, if this is a device with multiple regulators we have a standard way
of exposing that - have a regulators subnode with a collection of named
regulator subnodes in that.  There's support for parsing this in the
framework.

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