Re: st_fdma: Firmware filename in DT?

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

 




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