Re: st_fdma: Firmware filename in DT?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux