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

[Grant Likely <grant.likely@secretlab.ca>]

On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>> For indirect firmware, create a /chosen/firmware node.  Don't add a
>> compatible property,
>
> Oh, I don't like that idea at all.  The compatible property is useful for me to know *how* to parse the binary blob.

Compatible is for devices.  This is not a device.  Drivers cannot bind
against it.  Use a different mechanism if you have metadata about the
blob.  If your driver doesn't know how to validate its own firmware
blobs, then you've got bigger problems.

>> compatible is for devices and this node is for
>> blob data.
>
> But the blob has a format.  For QE firmware, for example, it's this:
>
> struct qe_firmware {
[...]
> } __attribute__ ((packed));

So?  If your data has a structure that the device tree cares about,
the break it out into the device tree nodes/properties structure.  If
it is a blob, then only the driver cares.  The format of the blob
doesn't have any bearing on how it is encapsulated into the tree.

>>  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.
>
> I don't like the idea of using the property name as a pseudo-compatible string.

It's a name, not a pseudo compatible string, and your device node will
explicitly reference it by name.  There is not backwards compatibility
or fuzzy binding issues at play here.  It is a way for your driver
node to state, "I want *that exact* firmware blob".  You could make
the property name "george" and it would still be completely clear (if
a little weird) because all the references are contained within the
tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.