Hi Lee, On Fri, 04 Sep 2015, Lee Jones wrote: > [...] > > > > If yes, is it worth having a generic binding? > > > > If we decide it is a good idea, then yes. It doesn't look that hard to > > arrive at something common. > > > > Strictly speaking, the firmware name is just an agreed upon name > > between the kernel and userspace. So why tie that into DT? Would other > > OS's use it or want something different? What if we started including > > paths in the names like <soc>/<firmware file>? Now we are imposing a > > directory structure on the OS filesystem. > > In Linux we have a standard place for firmwares, so the path should > not be required. I certainly agree that DT is no place for absolute > paths or OS'isums. > > [...] > > > > Presumably the alternative would be to add a whole bunch of compatibles > > > in the driver for each SoC, where the only difference from a > > > functional point of view would be to help build the correct string for > > > the firmware filename. However I'm also then wondering what the best way > > > would be to find out the instance name of the IP. > > > > If the name/path is Linux specific, then that is probably what we should do. > > > > You could perhaps make a policy that firmware files be named by > > compatible string. So rather than translating from matching compatible > > to an arbitrary file name, you enforce file name is "<vendor>,<ip > > block>.fw" or something. I know we don't have policy in the kernel, > > but we already have it with hardcoded file names and search paths. > > 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. 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 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. Presumably to test this driver you have to rename the firmwares locally on your machine? > > > > We could do it by parsing the node name e.g. fdma0-audio, or by adding > > > a "instance" DT property to the node? > > > > Generally we try to avoid caring about node names. Having some index > > or numbering also comes up which we also try to avoid. Generally, if > > you care about which instance you use for something, then there is > > some property you care about and should add. > > Right, the alternative is a property like the ones already used. > However, as these are becoming more prevalent I suggested > standardising the property to avoid all these vendor specific firmware > properties cluttering up the place. I agree a proliferation of vendor specific firmware properties isn't s good way forward. > > firmware = "firmwarename.fw"; > OR > firmware-name = "firmwarename.fw"; > > ... seems appropriate. Either of those is fine with me. regards, Peter. -- 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
