On Friday 04 September 2015, Lee Jones wrote: > On Fri, 04 Sep 2015, Arnd Bergmann 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 > > > 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. > > It depends what you mean by "basing the firmware name on the > \"compatible\" property" here. If you mean actually renaming the > firmware binary file to match a driver's compatible string, that's > absolutely out of the question. Firmwares are not only OS agnostic, > but are also independent of any H/W description language a particular > OS or platform might be using. Using DT'isums to rename these > binaries is not logical. > I was thinking of naming the firmware and the compatible string the same, and often enough that makes sense when both names are picked by the same person. However, you make a good point that there are cases where the firmware file already has a name based on some other decision process and there may be good reasons not to rename the file. In that case a driver writer can do a lookup table from one to the other. The downside of a lookup table of course is that you have to modify the driver for each new firmware, but then again a lot of drivers already require that, and others can come up with a policy that lets you do a programmatic mapping from one to the other by picking clever compatible strings. > However, if you mean simply match on compatible string and supply the > name from within the driver, that's closer to the mark (as then we can > at least keep it in-house [kernel]), but it's still not particularly > practical for the aforementioned reasons mentioned by Peter earlier. > > Why not just create a new 'firmware' property? Simples! [0] > > [0] http://www.oxforddictionaries.com/definition/english/simples My main thought was that loading a different firmware practically always means that the device behaves in a (sometimes more, sometimes less) different way, and we want to reflect that with a different compatible string. Having a 1:1 relation between the two strings enforces this. Arnd -- 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
