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: <54D3B858.9060103@sonymobile.com>
Date:	Thu, 5 Feb 2015 10:37:12 -0800
From:	Tim Bird <tim.bird@...ymobile.com>
To:	Mark Brown <broonie@...nel.org>
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 02/05/2015 09:43 AM, Mark Brown wrote:
> On Thu, Feb 05, 2015 at 09:33:31AM -0800, Tim Bird wrote:
>> On 02/04/2015 05:59 PM, Mark Brown wrote:
> 
>>> This is explicitly not supported; such bindings are invariably attempts
>>> to encode the Linux MFD structure into the device tree (which isn't a
>>> wonderful idea as the way we split things into subsystems can and does
>>> change) or...
> 
>> 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
driver because that's where the hardware for it is.  I'm not really
familiar with the complete driver sub-system layout of Linux.
This was not a (conscious) attempt to encode anything about Linux
into the device tree.  I'm just trying to get the dang supply
to hook up to the regulator node.

> 
>> Well, the above DT node is not complete.  Let me give some more
>> context.  I eventually want to have the charger driver support 2
>> regulators - one for the OTG vbus output (shown above) and one
>> for a boost hardware device, which controls voltage for this and
>> other parts of the system.  These are both for IP blocks that are
>> in the register range of this charger hardware (and hence belong, IMHO
>> in this driver).  I can easily move the otg-supply to the charger DT node,
>> as you request, but what do I do about other regulator attributes,
>> if I need to specify them for both the chg_otg and boost regulators
>> provided by this driver? How would this be handled?  I can't put them
>> all in the charger DT node.
> 
> This just sounds like a standard multi-regulator PMIC - usually the
> nodes for all the regulators end up getting stuffed in a node (typically
> called regulators) which the core can then interate over for you.  I'm
> just not seeing what's unusual about this device, sorry.

Thanks for helping me out here...  I apologize if these are newbie
questions as I haven't worked with regulators before.

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
all the proper device nodes, of_nodes, regulator attributes, etc.
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.)

How does the core know to iterate over regulators?  Is this something
automatic in the DT code, or something I have to trigger from the
charger probe routine?

As an aside, will each regulator have to have it's own probe routine,
and be capable of probe-deferring?  That is, if I separate the charger
probe from the regulator probes, it seems like I'll have to worry
about probe ordering, as well as manually establishing the linkage
between all these device nodes somehow during probing so the charger
enable/disable routines will be able to get access to the charger
register space.

Is there any way, if I'm open-coding a regulator, to just specify the
supply after it's instantiated?

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

Thanks. (And thanks for your patience),
 -- Tim

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