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@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".
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.
--
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
