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 9:27 AM, Warner Losh <imp@xxxxxxxxxx> wrote:
>
>> On Sep 4, 2015, at 4:21 AM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
>>
>>>>>> We could do it by parsing the node name e.g. fdma0-audio, or by adding
>>>>>> a "instance" DT property to the node?
>>>>>
>>>>> Generally we try to avoid caring about node names. Having some index
>>>>> or numbering also comes up which we also try to avoid. Generally, if
>>>>> you care about which instance you use for something, then there is
>>>>> some property you care about and should add.
>>>>
>>>> Right, the alternative is a property like the ones already used.
>>>> However, as these are becoming more prevalent I suggested
>>>> standardising the property to avoid all these vendor specific firmware
>>>> properties cluttering up the place.
>>>
>>> I agree a proliferation of vendor specific firmware properties isn't
>>> s good way forward.
>>>
>>>>  firmware = "firmwarename.fw";
>>>> OR
>>>>  firmware-name = "firmwarename.fw";
>>>>
>>>> ... seems appropriate.
>>>
>>> Either of those is fine with me.
>>
>> Just need a DT nod and I'll happily code it up.
>
> From a FreeBSD perspective, having a filename for the firmware to
> load for this node is fine. It doesn’t impose a substantial burden on
> the OS so long as the choices of where that file lives is up to the OS
> and not encoded in the property. A note saying ‘this firmware should
> be loaded’ seems a reasonable description of the hardware since
> the DT tells us many things about the device, and those things may
> well be dependent on which firmware is loaded. Having an explicit
> name is good since it helps insulate from DT and doesn’t force vendors
> to do silly renames. It also allows for multiple devices of the same
> type to have different firmware loaded.
>
> 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.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 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