Re: st_fdma: Firmware filename in DT?

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



On Fri, Sep 4, 2015 at 8:26 AM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> On Fri, 04 Sep 2015, Arnd Bergmann 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.
>>
>> 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.
>
> It depends what you mean by "basing the firmware name on the
> \"compatible\" property" here.  If you mean actually renaming the
> firmware binary file to match a driver's compatible string, that's
> absolutely out of the question.  Firmwares are not only OS agnostic,
> but are also independent of any H/W description language a particular
> OS or platform might be using.  Using DT'isums to rename these
> binaries is not logical.
>
> However, if you mean simply match on compatible string and supply the
> name from within the driver, that's closer to the mark (as then we can
> at least keep it in-house [kernel]), but it's still not particularly
> practical for the aforementioned reasons mentioned by Peter earlier.
>
> Why not just create a new 'firmware' property?  Simples! [0]

Someone give me some evidence that other OS's use or will use the same
names. Does *BSD use linux-firmware would be enough. With the
complaints I get that bindings are just Linux driver properties, I'm
not inclined to take this. Having a filename does imply the OS has a
filesystem and drivers can access the filesystem which may not always
be true.

Rob
--
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



[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux