On 04/09/15 11:21, Lee Jones wrote:
Absolutely not. Firmwares have no direct link to DT or platforms that
run DT specifically. They are carried by most platforms these days.
Insisting on firmwares using a DT compatible string format is way off.
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.
Hmnnn... That default looks really inappropriate for the ST platforms!
Different generations of the hardware have co-processors with similar
roles (and hence all with names like st231-gp0) but its very rare for
the co-processors to have the same firmware binary.
Thus if the default were applied naively we will end up with a bizarre
situation where the kernel is multi-platform but because the kernel does
not select a unique name for the different firmwares, it becomes
needlessly difficult for the userspace to support multiple platforms.
If there was a generic firmware property for this kind of situation it
is fairly natural to note in the bindings docs the importance of
uniqueness through the generations regarding of the choice of name.
There are other ways a driver can generate a unique name as the
generations of chip develop (compatible strings actually very good for
this) but I don't see it fitting quite so naturally into the binding
docs where it can help future adventurers.
I guess I should also comment about this on the ST remoteproc thread.
I'm curious though as to how the ST remoteproc driver then loads the firmware,
as that name doesn't look like a video or audio firmware filename that I've
seen shipped from ST. IIRC Usually it is named something like
vid_firmware-stih407.elf or audio_firmware-bd-stih407.elf
This driver came direct from ST. I'm using their conventions as a
default, although I would be happy to conduct some investigation into
how this works for releases and suggest a better interface. The only
reason I mentioned it here was because this is how others are using
other SS which are similar in some way. Same for the Firmware SS I
guess.
In my unbiased PoV, I'd much prefer the name was derived from a
predefined propertly.
IMO we should be treating the firmware as a blackbox, and for me that also
includes the filename it is shipped with. Linux drivers making up their own
firmware names based on the name of their subsystem doesn't seem like a
good way forward to me.
I guess the driver author was just using the fall-back convention for
testing. I'm pretty sure RemoteProc isn't being shipped in products
yet.
Both for fdma and co-processors, it is important that the kernel (or
kernel informed by DT properties/compatible strings) is "assertive"
enough to choose names that are sufficiently unique.
That is far more important than honoring vendor filenames.
Vendor filenames could easily be both too simple ("firmware.bin") or too
detailed ("fdma-foo+bar-v1.8_20140811.fw"; the DT should not be encoding
the version number of a firmware loaded from userspace since its not a
fixed property of the platform).
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
