LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* New firmware-load case for the firmware subsystem?
@ 2021-08-05 0:23 Russ Weight
0 siblings, 0 replies; only message in thread
From: Russ Weight @ 2021-08-05 0:23 UTC (permalink / raw)
To: Luis Chamberlain
Cc: linux-kernel, Moritz Fischer, Wu, Hao, Xu, Yilun, Gerlach,
Matthew, Tom Rix, lgoncalv
I have been working on a driver to allow updates to an Intel FPGA PCIe card.
In a recent email exchange, it was suggested that I investigate whether
this functionality could be provided in the existing firmware subsystem. I
have been looking at the firmware subsystem. I don't think there is much
overlap between what I need to do and what is already provided. I would
appreciate your thoughts on the following.
For background information, this is the email thread I referred to:
and this is the last submission of the driver in it's current form:
In a nutshell, these are features that I believe are not currently in the
the firmware subsystem.
(1) Updates don't take place during driver probe / initialization. The
updates need to be applied while the FPGA device is up and fully
functional. FPGA image updates and firmware updates are stored to FLASH
and do not take affect until the card is rebooted.
(2) Need an API to allow the user to initiate the update and specify
the image file. The images are signed/authenticated files that are
authenticated by the device using installed keys. Some image types
are expected to be provided by the end-user. For example, the image
file may contain a new Root Hash Entry for Partial Reconfigurations
(which are under control of the end-user).
(3) We have one update case that can take up to 45 minutes. In order to be
able to provide some sort of progress indication to the user, we would
like to do the update in the context of a kernel worker thread, with
progress status available through a user API.
I think I have the following options:
(1) Continue to develop an FPGA-specific image update driver
(2) Consider a more generic firmware update mechanism that others
may be able to use.
(3) Consider integrating this functionality into the existing firmware
Do you see any opportunity to share code? Do you think this functionality
would fit in the existing firmware subsystem?
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-08-05 0:23 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-05 0:23 New firmware-load case for the firmware subsystem? Russ Weight
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).