Re: st_fdma: Firmware filename in DT?

[Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On 05/09/15 10:25, Arnd Bergmann wrote:
> On Friday 04 September 2015, Rob Herring wrote:
>> On Fri, Sep 4, 2015 at 9:27 AM, Warner Losh <imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On Sep 4, 2015, at 4:21 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>>>>> We could do it by parsing the node name e.g. fdma0-audio, or by adding
>>> FreeBSD would generally put these things in /boot/firmware and
>>> it has a generalized mechanism to load the firmware at run time
>>> that’s based on this. While the path names are flexible, having
>>> the firmware live in a central place is useful from an automation
>>> point of view. Having just a name, and not a full path, enables
>>> this policy, while still allowing others to have other policies.
>>>
>>> Linux distributions would be free to do whatever they wanted
>>> and implement other policies than FreeBSD.
>>>
>>> So a property like this, with the semantics discussed, seems to
>>> meet the OS independent test.
>>
>> Good. I'll await a binding to review...
>>
>> I would suggest "firmware-names" to be consistent with other naming
>> convention and because their can be more than one (either at the same
>> time or as fallback). It also leaves "firmware" available if we want
>> to have phandle's to firmware embedded in the DT at some point later.
>
> Having list of strings would certainly make this more flexible than
> just a single string, for the same reason as taking the list of
> compatible values as the base, so +1 for "firmware-names" over "firmware".

I was recently thinking about how DT filenames would interact with 
incompatible ABI changes to the firmware's register and/or wire protocol.

Just for example we start with f/ware ABI A and we create a mainline 
kernel X that supported it.

Vendor now releases a new firmware with ABI B and we update the mainline 
driver to support ABI A (to avoid breaking old userspaces) and B, 
eventually releasing kernel Y.

The question now is how kernels X and Y should use the DT to generate 
the filename. It is very desirable that kernels X and Y use *different* 
filenames because otherwise a single userspace could not support the new 
feature *and* boot with both X and Y.

Having lists of firmwares can certainly help solve this (providing the 
list can be used to allow a driver to select for an ABI is supports). 
However I afraid I find this example argues against having filenames in 
DT at all because it seems odd to me that, for kernel and userspace to 
adopt ABI B that must wait until the DT is updated to include support 
for ABI B. The hardware didn't change...


Daniel.