[...] > > 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 > > 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. firmware = "firmwarename.fw"; OR firmware-name = "firmwarename.fw"; ... seems appropriate. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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
