Grant Likely wrote:
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.
Compatible is for matching. Who cares what category the thing being
matched is in? What is the definition of a device, and why does it matter?
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.
One could also say, if your hardware can't be probed at runtime, you've
got bigger problems. :-)
What's wrong with an indication of what type of "thing" a node is
supposed to be? There could be multiple microcode formats, for example.
I don't know that it's strictly necessary in this case -- it looks like
there is a magic number in the firmware blob -- but I don't understand
the objection as a matter of principle. These device tree discussions
have a tendency to get awfully bikesheddy.
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.
There is a forward compatibility issue, in that we'll have to update the
code with every new mpc<blah> (or p<blah>rev<n>) that comes along.
Or are we supposed to pick some random chip to request the firmware for,
like with compatibles? What would be the point? This isn't being used
to bind a driver.
It is a way for your driver
node to state, "I want *that exact* firmware blob".
The driver wants the firmware blob that the device tree provides. The
device tree knows better than the driver, being that the device tree is
the describer of the hardware.
You could make
the property name "george"
If "george" is fine, then so is "fsl,firmware". Maybe "fsl,qe-firmware".
and it would still be completely clear (if
a little weird) because all the references are contained within the
tree.
How are the references contained within the tree? The driver has to
know which property to read.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
