> Subject: [PATCH v1 00/12] Intel FPGA Security Manager Class Driver > > > These patches depend on the patchset: "add regmap-spi-avmm & Intel > Max10 BMC chip support" which is currently under review. > > -------------------------------------------------- > > This patchset introduces the Intel Security Manager class driver > for managing secure updates on Intel FPGA Cards. It also provides > the n3000bmc-secure mfd sub-driver for the MAX10 BMC for the n3000 > Programmable Acceleration Cards (PAC). The n3000bmc-secure driver > is implemented using the Intel Security Manager class driver.
So this patchset contains two parts (1) adding a new class driver for Intel FPGA secure update. (2) a new driver which uses (1) to implement secure update for n3000 PAC. And only part (2) depends on "Intel MAX10 BMC chip support" patchset. (Maybe you can provide a link to that thread). Is my understanding correct? If yes, is it possible to reorder these patches? At least there is no dependency on the class driver patches, right? > > The Intel Security Manager class driver provides a common API for > user-space tools to manage updates for Secure FPGA devices. Device > drivers that instantiate the Intel Security Manager class driver will > interact with the HW secure update engine in order to transfer > new FPGA and BMC images to FLASH so that they will be automatically > loaded when the FPGA card reboots. > > The API consists of sysfs nodes and supports the following functions: > > (1) Instantiate and monitor a secure update > (2) Display security information including: Root Entry Hashes (REH), > Cancelled Code Signing Keys (CSK), and flash update counts for > both BMC and FPGA images. > > Secure updates make use of the request_firmware framework, which > requires that image files are accessible under /lib/firmware. A request > for a secure update returns immediately, while the update itself > proceeds in the context of a kernel worker thread. Sysfs files provide > a means for monitoring the progress of a secure update and for > retrieving error information in the event of a failure. Maybe you can explain a little more on why we need to have this done via a class driver not just some internal code in max10 driver? This class driver will be reused in different cases? And why adding a new class driver not just reuse or extend fpga manager (existing fpga mgr is used to update fpga too). > > The n3000bmc-secure driver instantiates the Intel Security Manager > class driver and provides the callback functions required to support > secure updates on Intel n3000 PAC devices. > > Russ Weight (12): > fpga: fpga security manager class driver Intel FPGA Security Manager? > fpga: create intel max10 bmc security engine > fpga: expose max10 flash update counts in sysfs > fpga: expose max10 canceled keys in sysfs > fpga: enable secure updates > fpga: add max10 secure update functions > fpga: expose sec-mgr update status > fpga: expose sec-mgr update errors > fpga: expose sec-mgr update size > fpga: enable sec-mgr update cancel > fpga: expose hardware error info in sysfs For these patches, is it possible to have a better title for these patches. Then it will be easier to know which component this patch is going to modify. e.g. fpga: ifpga-sec-mgr: xxxxxx Thanks Hao > fpga: add max10 get_hw_errinfo callback func > > .../ABI/testing/sysfs-class-ifpga-sec-mgr | 151 ++++ > MAINTAINERS | 8 + > drivers/fpga/Kconfig | 20 + > drivers/fpga/Makefile | 6 + > drivers/fpga/ifpga-sec-mgr.c | 669 ++++++++++++++++++ > drivers/fpga/intel-m10-bmc-secure.c | 557 +++++++++++++++ > include/linux/fpga/ifpga-sec-mgr.h | 201 ++++++ > include/linux/mfd/intel-m10-bmc.h | 116 +++ > 8 files changed, 1728 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr > create mode 100644 drivers/fpga/ifpga-sec-mgr.c > create mode 100644 drivers/fpga/intel-m10-bmc-secure.c > create mode 100644 include/linux/fpga/ifpga-sec-mgr.h > > -- > 2.17.1
