On 07/09/15 13:33, Arnd Bergmann wrote:
On Monday 07 September 2015 11:30:11 Daniel Thompson wrote:
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.
Generally speaking, the kernel should shield user space from ABI
differences in the firmware and still provide the same user space ABI
(possibly emulated, when the newer firmware removes features of the
old one). Can you think of a case where a device firmware directly
defines the user ABI without having kernel visible changes?
I don't mean that the firmware ABI is exposed to userspace.
I mean if you use the same filename for both ABIs (in /lib/firmware)
then kernel X with lose functionality if it is booted with a userspace
that has updated to the new firmware (maybe even crash if I can't detect
at runtime the version of the firmware is has loaded). That sort of
thing is the pain for distros which support booting with multiple
kernels (apt-get/dnf simply won't know when it is safe to update the
firmware binary).
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...
This is not what I was thinking of for a list of file names: I would not
want a case where the kernel might pick between multiple incompatible
files without knowing what they are, especially if the differences
are ABI relevant.
Nor me.
Personally I prefer an "assertive" driver that imposes a filename for
the firmwares it needs. Thus if there is an ABI change the driver writer
can load a completely different firmware file without needing a DT
update. That said I'm not especially invested either way.
However whatever solution is reached I would quite like to be able to
boot kernels from either side of an ABI break from a single userspace
(and get the new features when the kernel supports them).
However, being very specific would let users intentionally install a
firmware that is only used on a particular instance of a device that
they want to behave differently, while the generic firmware would come
preinstalled with the normal linux-firmware package.
Not sure I follow this. You mean embedding filenames in DT makes it easy
to something like a vendor/reverse-engineering mode.
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
