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

[Timur Tabi <timur@freescale.com>]

Grant Likely wrote:

> 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.

Perhaps.  I left the door open to have additional firmware-specific properties in the firmware node that the driver can use to interpret the firmware blob.  Not everyone can have a nice, complete header for the firmware.  Sometimes the firmware is distributed as just raw microcode words, without any header or anything like that.

> 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.

Yes, the QE firmware format does include a bunch of information, but who says that will always be the case?  And what happens if we want to extend this binding to include non-QE firmware?  What happens if, down the road, we need to add properties to help us interpret the firmware?

In other words, we can't depend on the contains of the firmware blob to tell the driver everything he needs to know.

> 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.

Eh, I don't know.  Maybe if you bought me dinner first, you could talk me into it.

-- 
Timur Tabi
Linux kernel developer at Freescale