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
Attachment:
pgptep3L2uORc.pgp
Description: PGP signature
