On Thu, 24 Oct 2013 04:36:30 -0500, Kumar Gala <galak@xxxxxxxxxxxxxx> wrote:
>
> On Oct 24, 2013, at 4:21 AM, Hiroshi Doyu wrote:
>
> > Hi Grant,
> >
> > Grant Likely <grant.likely@xxxxxxxxxx> wrote @ Thu, 24 Oct 2013 10:55:31 +0200:
> > ....
> >>> diff --git a/include/linux/of.h b/include/linux/of.h
> >>> index f95aee3..638a88a 100644
> >>> --- a/include/linux/of.h
> >>> +++ b/include/linux/of.h
> >>> @@ -60,6 +60,7 @@ struct device_node {
> >>> struct kref kref;
> >>> unsigned long _flags;
> >>> void *data;
> >>> + struct device *dev; /* Set only after populated */
> >>
> >> Is this being used merely to indicate that a device has been processed
> >> by of_platform_device_create()? Or do you intend to dereference this
> >> pointer? I've avoided putting the struct device in to the device_node
> >> structure up to this point simply becuase there aren't any good clues
> >> for what /kind/ of device it actually points to. I worry that bad
> >> assumptions will get made when other subsystems try to use the
> >> same pointer. ie. if one subsystem creates its own device and sets this
> >> pointer, and then of_platform_device_create() comes along behind, sees
> >> that it is already created, and then returns a platform_device pointer
> >> *for something that isn't a struct platform_device*. This is very bad.
> >>
> >> Instead of using a pointer to the struct device, would a flag be
> >> sufficient for your purposes? Would it be fine to return NULL if the
> >> device has already been created?
> >
> > Yes, a flag would be enough for this purpose.
> >
> > This patch is a part of HACK to control device instanciation order. We
> > have an IOMMU device(platform) which needs to be instanciated earlier
> > than other (platform)devices so that IOMMU driver would configure them
> > as IOMMU'able device.
> >
> > Is there any better way to control device instanciation order from DT?
>
> I was also thinking being able to call of_platform_populate multiple times and have explicit lists to control device init order might be a workable solution. So might be worth continuing down this path to make device nodes that have already be created.
Does that actually solve the problem though? If the multiple calls to
of_platform_populate are all before the driver initcall, then the order
of probing is most likely going to be more influenced by kernel link
order.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
