binding for nvec mfd device

[Thierry Reding]

On Fri, Jun 28, 2013 at 09:13:38AM -0600, Stephen Warren wrote:
> On 06/27/2013 12:26 PM, Marc Dietrich wrote:
[...]
> > Another question is how the children will get their platform data. I guess 
> > they will just walk the device tree of their parent node and search for it, 
> > but maybe there is a better way?
> 
> In option (a), there will be a separate struct device for each child
> node, instantiated directly from the child DT node. Hence, the driver
> (chosen from the compatible value just like any other) would simply
> parse dev.of_node just like any other driver. The only difference would
> be that the driver would have to go to the parent node, and search for a
> driver for it, and ask that driver for any "supporting resources", such
> as a device handle that allowed you to all APIs to send/receive bytes
> over the protocol. Perhaps the parent device might just pre-create
> regmaps for all the child devices if that abstraction works. That would
> save the child devices even having to look for the parent device.

I've often seen a much easier method employed and something similar is
also done in host1x/tegra-drm. Child devices directly pass dev->parent
to some API provided by the parent. The API then takes care of checking
and extracting the driver-specific data of the parent from the struct
device before performing the operation. Or you could provide an API to
cast from a struct device to the parent's type.

So in the specific case of nvec this would translate to either making
the nvec_write_{sync,async}() functions take a struct device * instead
of the struct nvec_chip as first parameter, then do something like:

	struct nvec_chip *nvec = dev_get_drvdata(dev);

Or provide a function such as this:

	struct nvec_chip *nvec_chip_from_device(struct device *dev)
	{
		/* perhaps do some validation */
		return dev_get_drvdata(dev);
	}

which can be called from child drivers before calling nvec_write_sync()
or nvec_write_async().

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130628/60d20956/attachment.sig>