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. > Personally, my vote lies with direct-inclusion. However, if > indirection is used, then I think it would be wise to define where > data-only nodes like this should live. Under /chosen perhaps? I personally don't care that much; /chosen is okay with me, but .... > It > wouldn't be good to place it somewhere where it will be confused for > an actual device node. ... what's wrong with the root node? -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
