Re: st_fdma: Firmware filename in DT?

On Friday 04 September 2015, Rob Herring wrote:

On Fri, Sep 4, 2015 at 9:27 AM, Warner Losh [off-list ref] wrote:

quoted

quoted

On Sep 4, 2015, at 4:21 AM, Lee Jones [off-list ref] wrote:

quoted

quoted

quoted

quoted

We could do it by parsing the node name e.g. fdma0-audio, or by adding

FreeBSD would generally put these things in /boot/firmware and
it has a generalized mechanism to load the firmware at run time
that’s based on this. While the path names are flexible, having
the firmware live in a central place is useful from an automation
point of view. Having just a name, and not a full path, enables
this policy, while still allowing others to have other policies.

Linux distributions would be free to do whatever they wanted
and implement other policies than FreeBSD.

So a property like this, with the semantics discussed, seems to
meet the OS independent test.

Good. I'll await a binding to review...

I would suggest "firmware-names" to be consistent with other naming
convention and because their can be more than one (either at the same
time or as fallback). It also leaves "firmware" available if we want
to have phandle's to firmware embedded in the DT at some point later.

Having list of strings would certainly make this more flexible than
just a single string, for the same reason as taking the list of
compatible values as the base, so +1 for "firmware-names" over "firmware".

If we decide to create a proper binding for standardizing this, we
might also want to standardize inline firmware blobs. I've worked
with systems in the past that wanted to include a device firmware blob
in their system firmware, and that blob was not freely distributable
While nondistributable device firmware is not something we want to encourage,
people are going to do it anyway and standardizing the method may be better
than not.

See drivers/net/ethernet/toshiba/spider_net.c for a particular example
I was thinking of. In this case, the system firmware can provide a blob
to the kernel driver in a propery, but the driver will first look at
the local file system for an updated image.

	Arnd.