Re: [PATCH] regulator: Support different config and dev of_nodes in regulator_register

[Mark Brown]

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.

Attachment: signature.asc
Description: Digital signature