> 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 >> 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. > 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). Warner
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
