On Thu, Mar 25, 2010 at 10:59:01AM -0600, Grant Likely wrote:
> On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi <ti...@freescale.com> wrote:
> > Grant Likely wrote:
> >> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley <w...@firmworks.com> wrote:
> >>> It seems to me that there are plausible use cases for both
> >>> direct-inclusion
> >>> and indirection. I don't see any real problems with either, so I would
> >>> vote
> >>> for specifying both alternatives.
> >>
> >> Ugh. Then this one driver would need to implement both binding for
> >> little, if any, actual benefit.
> >
> > Although I agree that I don't like supporting both bindings, we could
> > encapsulate the locating of the firmware node in a function. The function
> > will first look for a child firmware node, and if it doesn't find it, look
> > for a fsl,firmware property. It will return a pointer to the firmware node
> > regardless.
> >
> >> I'm sure we can come to an agreement
> >> on one method if the firmware absolutely has to be in the tree.
> >
> > If we have to pick one, then I think the only viable choice is have a
> > separate firmware node and a phandle pointer to it. Otherwise, I just
> > don't see how we can handle multiple devices needing the same firmware.
>
> Wait for David to weigh in on this one before making a decision. He
> knows the dtb format best.
I'll do that when I can. Right now I'm in the middle of intense
bringup work so I won't have time for this for a while.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
