On Fri, Sep 4, 2015 at 8:26 AM, Lee Jones <lee.jones@xxxxxxxxxx> 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. > > 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] Someone give me some evidence that other OS's use or will use the same names. Does *BSD use linux-firmware would be enough. With the complaints I get that bindings are just Linux driver properties, I'm not inclined to take this. Having a filename does imply the OS has a filesystem and drivers can access the filesystem which may not always be true. Rob -- 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
