On Friday 04 September 2015, Rob Herring wrote: > 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 > > 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". If we decide to create a proper binding for standardizing this, we might also want to standardize inline firmware blobs. I've worked with systems in the past that wanted to include a device firmware blob in their system firmware, and that blob was not freely distributable While nondistributable device firmware is not something we want to encourage, people are going to do it anyway and standardizing the method may be better than not. See drivers/net/ethernet/toshiba/spider_net.c for a particular example I was thinking of. In this case, the system firmware can provide a blob to the kernel driver in a propery, but the driver will first look at the local file system for an updated image. Arnd. -- 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
