On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi <ti...@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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
