On Thu, 24 Oct 2013 04:36:30 -0500, Kumar Gala <ga...@codeaurora.org> wrote:
>
> On Oct 24, 2013, at 4:21 AM, Hiroshi Doyu wrote:
>
> > Hi Grant,
> >
> > Grant Likely <grant.lik...@linaro.org> 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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
