[PATCH] powerpc/fsl: add device tree binding for QE firmware

[Grant Likely]

On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi <timur at freescale.com> wrote:
> Grant Likely wrote:
>> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley <wmb at 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.