Re: st_fdma: Firmware filename in DT?

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Friday 04 September 2015, Rob Herring wrote:
> On Fri, Sep 4, 2015 at 9:27 AM, Warner Losh <imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> wrote:
> >> On Sep 4, 2015, at 4:21 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >>>>>> 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.