Re: st_fdma: Firmware filename in DT?

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

On Friday 04 September 2015, Lee Jones wrote:
> > > If we flip it the other way round, some subsystems derive the firmware
> > > name from the 'node name'.  For instance, our zeroth General Purpose
> > > Co-Processor RemoteProc driver has a corresponding node called
> > > 'st231-gp0@40000000'.  RemoteProc adds an 'rproc-' prefix and a '-fw'
> > > suffix and et voilà, we load file:
> > > 
> > >   lib/firmware/rproc-st231-gp0-fw
> > 
> > IMO deriving from the node name seems fragile. Also imposing a linux'ism
> > "rproc" prefix on the firmware name doesn't seem correct as the firmwares
> > can be shared across OS's. Although this is how remoteproc subsys core
> > is currently working. It seems a generic DT firmware binding would actually
> > be most useful for the remoteproc subsystem.
> 
> The "rproc-%s-fw", where %s == driver name, is only a fall-back.  The
> RProc driver is welcome to supply a different firmware name if it
> desires.  This is where I think a generic 'firmware' property would be
> of use.

The firmware file name is agreed on between the device driver and the
file system, so encoding the linux driver name in it seems appropriate.

Generally speaking, I'd say a good policy would be to try basing
the firmware name on the "compatible" property strings. That property
already contains a hierarchical list of models, which makes it particularly
easy to have firmware files for specific models or those that are shared
across multiple variations if necessary. Just ask for the most specific
compatible string first and try the more specific compatible strings
(with an appropriate prefix and/or postfix added by the driver) until
a file is found.

	Arnd