On Friday 04 September 2015, Warner Losh wrote:
> > On Sep 4, 2015, at 7:04 AM, Arnd Bergmann <a...@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.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
