Re: st_fdma: Firmware filename in DT?

[Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Thu, 10 Sep 2015, Peter Griffin wrote:
> On Mon, 07 Sep 2015, Daniel Thompson wrote:
> > 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 a really good point and one I'd not considered.
> 
> > >
> > >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).
> 
> So to summarise, I think given Daniels good points about ABI
> compatability, and also David and Arnd PoV, it would be best to leave
> the generation of the firmware filename to the individual driver and
> not put the filename in DT.

<hijacking>

That doesn't work for middle-layer drivers such as Remoteproc, where
it doesn't have its own associated firmwares.  Remoteproc's job is
simply to load the firmware.  It doesn't care which version of the ABI
that particular binary uses, and has no reason to.  Ideally, I guess
the Remoteproc client should be providing the firmware name, but why
should the client care who or what was used to load the firmware?

</hijacking>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog