LKML Archive on
help / color / mirror / Atom feed
From: Russ Weight <>
To: Luis Chamberlain <>
Cc: "" <>,
	"Moritz Fischer" <>, "Wu, Hao" <>,
	"Xu, Yilun" <>,
	"Gerlach, Matthew" <>,
	Tom Rix <>,
	"" <>
Subject: New firmware-load case for the firmware subsystem?
Date: Wed, 4 Aug 2021 17:23:14 -0700	[thread overview]
Message-ID: <> (raw)

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

                 reply	other threads:[~2021-08-05  0:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: New firmware-load case for the firmware subsystem?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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