On Friday 04 September 2015, Warner Losh wrote: > > On Sep 4, 2015, at 7:04 AM, Arnd Bergmann <arnd@xxxxxxxx> 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> > Warner > > > >> 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. > > Encoding the driver name is not OS independent. It fosters the > impression that DT isn’t OS independent, but rather some silly > Linux toy and hurts wider adaptation. I meant encoding the driver name in the path for the firmware file, e.g. $DRIVER/$COMPATIBLE.bin where $DRIVER is the name of the driver, and $COMPATIBLE is the name from the compatible string. > > 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. > > I think this is a horrible policy. It is an ugly kludge that is fragile to change. > While it sounds cool, I don’t think it is really a viable one. It requires > different compatibility names for different bits of hardware that might otherwise > be the same just to get different firmware. Sometimes this may be OK, > but it does seem needlessly limiting for systems that may have firmware > “images” that are loaded into one hardware block, but actually control > other blocks indirectly (where the different compat strings would be). The idea is that the compatible string here not only encodes the hardware but also how it is getting used. This is the same as what we do with other programmable hardware, such as PHY controllers that can be either PCIe or USB3 depending on some setting. The driver would match on the more generic property that identifies the hardware, while the firmware can match on the more specific one, if any, or be provided by the user. As an example, you can have compatible = "fwmaker,firmwaretype", "hardwaremaker,thisdevice-instance2", "hardwaremaker,thisdevice-version-3.1", "hardwaremaker,thisdevice"; So the driver matches on the one of the last two strings (as any other driver), and the firmware can match on the same string, or the user can provide an image in the file system based on the instance (if there are multiple ones), or the boot loader can predefine which function should get loaded into this one, based on how the hardware is physically wired up. The file name for loading the firmware can still get constructed from additional properties, e.g. the instance can be appended by the driver instead of coming from compatible if that makes more sense. 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
