linux-kernel - Re: [PATCH] regulator: Support different config and dev of_nodes in regulator

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: <20150205192740.GL21293@sirena.org.uk>
Date:	Thu, 5 Feb 2015 19:27:40 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Tim Bird <tim.bird@...ymobile.com>
Cc:	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Andersson, Björn" 
	<Bjorn.Andersson@...ymobile.com>
Subject: Re: [PATCH] regulator: Support different config and dev of_nodes in
 regulator_register

On Thu, Feb 05, 2015 at 10:37:12AM -0800, Tim Bird wrote:
> On 02/05/2015 09:43 AM, Mark Brown wrote:

> >> Sorry - what is the "Linux MFD structure"?

> > The way we split things up into subsystems via drivers/mfd.  Our set of
> > subsystems is neither fixed nor authorative.

> I'm not doing anything in drivers/mfd?  Should I be?
> The charger driver is currently in drivers/power, but should it be
> moved to drivers/mfd if it's going to expose regulators as
> well as power supplies?  I'm sorry, but I'm not following
> your point here.  I associated this regulator with the charger

Possibly not.  My reply was explaining the sorts of breakage that
allowing the DT node to be overridden is usually intended to support,
the sort of thoughtless bindings for MFDs that I'm describing is one
typical example.

> So you're saying I should have a "regulators" child node of the charger
> node, and then define the chg_otg and boost regulators under that, each
> with it's own compatible string, so that the DT code can instantiate

No, absolutely not - you should not need to put compatible strings for
individual regulators within a single device in the device tree.  Please
take a look at how other devices do this - there are plenty of bindings
for existing devices in tree with matching code in the kernel.

> Or is this instantiation something I do manually in the charger probe
> routine?  (That's what I'm doing now, but open coding each regulator
> individually.)

Given the way you're talking separately about there being a charger
driver and a regulator driver here it sounds like you should be creating
a MFD.  The MFD subsystem exists to provide a way of mapping a single
physical device into multiple kernel subsystems which sounds like it
will be what you're trying to do here.

> Can you recommend a driver to look at that does (properly) what
> you're describing?

Most of drivers/mfd is PMICs doing this, anything recently added should
be reasonable to look at.  Most of the Maxim or Wolfson devices for
example.

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