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. >> 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? Take things to a logical extreme and see what it looks like. Instead of one QE blob, assume that you need to provide 100 firmware blobs for various devices (yes, that number is ridiculous, but that's kind of the point). Essentially what I mean is make the assumption that the problem you have is not unique, that other drivers also need firmware. Should it be organized? Does it make sense to have one node in the root for each firmware blob? Does it make sense for each of those nodes to have a 'compatible' property which makes it look like a physical device? Here's a counter proposal off the top of my head: For indirect firmware, create a /chosen/firmware node. Don't add a compatible property, compatible is for devices and this node is for blob data. Put each firmware blob into a separate property, and make the names reasonable (ie. mpc<blah>-qe-firmware). Have the QE reference the firmware blob by property name. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
