[PATCH 1/3] mfd: allow mfd_cell association with device tree node

[Mark Brown]

On Mon, Oct 03, 2011 at 11:39:47AM +0100, Daniel Drake wrote:
> On Mon, Oct 3, 2011 at 11:28 AM, Mark Brown

> > I'd really expect that if we're adding stuff to the framework then it
> > should be suitable for random drivers to use.

> It is suitable. If other drivers would otherwise run into the data
> reuse problem you have described, they can use the kmemdup solution
> you have described.

This seems the wrong way round - we're working

> > To be honest I don't
> > really understand why you're changing the framework at all here, the
> > child driver is entirely specific to the parent as far as I can see.

> Because I'm trying to get devicetree-driven HDD LED support driven,
> and Grant stated that doing it this way is a hard rule:

> "What is a hard rule is that the code creating the children needs to
> know what the binding is and populate the child's of_node
> appropriately."

> I also confirmed that extending the mfd_cell layer is exactly what
> Grant was suggesting:
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/008480.html

That's in the context of adding a binding for the vx855 GPIO module
that's distinct from the binding for the rest of the chip.  It's not
massively clear to me that this is a good idea.

> So I seem to be stuck between two people giving me conflicting
> requirements for merge of my work (which commenced in July, and has
> already seen several discussions and rounds of patches). Any help
> appreciated - I'm just trying to make a HDD LED blink.

It seems to me like either the IP block is heavily dependant on the core
and shouldn't be split out in the device tree at all (but should instead
be part of the core node) or the IP block is very isolated from the core
(in which case we should just be able to instantiate the device from the
device tree without using explict code in the core driver).

This all feels like there's some abstraction violation going on.