Re: st_fdma: Firmware filename in DT?

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 5268 bytes --]

On Sat, Sep 5, 2015 at 2:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Friday 04 September 2015, Warner Losh wrote:
> > > On Sep 4, 2015, at 7:04 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > 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>
> > Warner
> >
> >
>
> > >> 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.
> >
> > Encoding the driver name is not OS independent. It fosters the
> > impression that DT isn’t OS independent, but rather some silly
> > Linux toy and hurts wider adaptation.
>
> I meant encoding the driver name in the path for the firmware file,
> e.g.
>
>          $DRIVER/$COMPATIBLE.bin
>
> where $DRIVER is the name of the driver, and $COMPATIBLE is the name
> from the compatible string.
>
> > > 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.
> >
> > I think this is a horrible policy. It is an ugly kludge that is fragile
> to change.
> > While it sounds cool, I don’t think it is really a viable one. It
> requires
> > different compatibility names for different bits of hardware that might
> otherwise
> > be the same just to get different firmware. Sometimes this may be OK,
> > but it does seem needlessly limiting for systems that may have firmware
> > “images” that are loaded into one hardware block, but actually control
> > other blocks indirectly (where the different compat strings would be).
>
> The idea is that the compatible string here not only encodes the hardware
> but also how it is getting used. This is the same as what we do with other
> programmable hardware, such as PHY controllers that can be either PCIe
> or USB3 depending on some setting. The driver would match on the more
> generic
> property that identifies the hardware, while the firmware can match on the
> more specific one, if any, or be provided by the user. As an example,
> you can have
>
>         compatible = "fwmaker,firmwaretype",
> "hardwaremaker,thisdevice-instance2",
>                 "hardwaremaker,thisdevice-version-3.1",
> "hardwaremaker,thisdevice";
>
> So the driver matches on the one of the last two strings (as any other
> driver),
> and the firmware can match on the same string, or the user can provide an
> image
> in the file system based on the instance (if there are multiple ones), or
> the
> boot loader can predefine which function should get loaded into this one,
> based
> on how the hardware is physically wired up.
>
> The file name for loading the firmware can still get constructed from
> additional
> properties, e.g. the instance can be appended by the driver instead of
> coming
> from compatible if that makes more sense
>

I understood what you were proposing. It wasn't a lack of understanding
that lead me to the opinion that it was a horrible policy. Despite your
lengthy explanation, you did nothing to address the very simple and common
use case of having identical hardware that none-the-less needs different
firmware which was my basis of the horrible brand I put on this policy.

Also, firmware comes from vendors generally named something other
than FDT compat strings. Renaming firmware generally is also a
horrible policy that most shops frown on. It hampers traceability from
a deployed system back to the sources, for one and introduces one
more place for an 'oops' rename to go undetected until the firmware
is deployed.

So there needs to be a standardized way to augment local policy
to say 'the firmware you need for this node so that the system behaves
as expect in the DT is Y.'

Warner

[-- Attachment #2: Type: text/html, Size: 6463 bytes --]