LKML Archive on
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

Hi Luis,

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?

- Russ

^ 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).