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

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

On Thu, Mar 25, 2010 at 2:04 PM, Timur Tabi <timur@freescale.com> wrote:
> Scott Wood wrote:
>
>> I don't know that it's strictly necessary in this case -- =A0it looks li=
ke
>> there is a magic number in the firmware blob -- but I don't understand
>> the objection as a matter of principle. =A0These device tree discussions
>> have a tendency to get awfully bikesheddy.
>
> I don't want this discussion, and any binding definitions that come from =
it, to be limited to the specifics of a QE firmware. =A0I want to make sure=
 that any binding that we come up with can be easily extended to any kind o=
f firmware, including firmware that has no headers.
>
> Many companies will distribute their firmware as a generic sequence of by=
tes (no header), and a simple code fragment that demonstrates uploading the=
 binary to the hardware. =A0The license for these files sometimes precludes=
 the option of wrapping that microcode inside or with another binary. =A0Th=
at is, if you want to distribute this firmware, it must be distributed as-i=
s.
>
> Example:
>
> Freescale buys a chip from some vendor and puts the chip on a reference b=
oard. =A0The chip requires some microcode to be uploaded, and the vendor di=
stributes some binary blob and a code snippet. =A0Freescale embeds the code=
 snippet in Linux, and puts the microcode somewhere in flash. =A0The licens=
e for the microcode says, "thou shalt not merge this microcode with any oth=
er binary". =A0Freescale decides, for whatever reason, that putting a heade=
r around the microcode and putting *that* in flash is a violation of the li=
cense, but having U-Boot dynamically embed it into a DTB isn't. =A0Ok, mayb=
e that's a bit ridiculous, but just humor me. =A0In this case, it would use=
ful to have the microcode in its own node with properties describing the mi=
crocode.
>
> Anyway, I may have gone off in the weeds with this discussion.

No, this isn't off in the weeds.  I concede the point of needing to
store firmware in a separate node, but I still don't agree with the
argument that it needs to be anything more than an anonymous named
blob.  The fact that another node references it implicitly defines the
format the blob needs to be in.  If the blob format changes, then in
practice the existing binding is no longer compatible because older
drivers just won't work.  It probably doesn't justify creation of a
new compatible value, but I would handle firmware in a different
format with a different property name to reference it.

g.