[PATCH] libnvdimm/security: change __nvdimm_security_overwrite_query from global to static

[Tom Rix]

Smatch reports this issue
security.c:416:6: warning: symbol '__nvdimm_security_overwrite_query' was not 
declared. Should it be static?

__nvdimm_security_overwrite_query is only used in security.c so change
its storage-class specifier to static

Signed-off-by: Tom Rix 
---
 drivers/nvdimm/security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 4b80150e4afa..d3e782662bf4 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -413,7 +413,7 @@ static int security_overwrite(struct nvdimm *nvdimm, 
unsigned int keyid)
return rc;
 }
 
-void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
+static void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
 {
struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(>dev);
int rc;
-- 
2.27.0

Re: [PATCH] fpga: dfl: pci: gracefully handle misconfigured port entries

[Tom Rix]

On 4/20/21 10:27 AM, matthew.gerl...@linux.intel.com wrote:

From: Matthew Gerlach 

Gracefully ignore misconfigured port entries encountered in
incorrect FPGA images.

Signed-off-by: Matthew Gerlach 
---
  drivers/fpga/dfl-pci.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index b44523e..660d3b6 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -212,6 +212,7 @@ static int find_dfls_by_default(struct pci_dev *pcidev,

Does something similar need to be added to find_dfls_by_vsec ?

int port_num, bar, i, ret = 0;
resource_size_t start, len;
void __iomem *base;
+   int bars = 0;
u32 offset;
u64 v;
  
@@ -228,6 +229,7 @@ static int find_dfls_by_default(struct pci_dev *pcidev,

if (dfl_feature_is_fme(base)) {
start = pci_resource_start(pcidev, 0);
len = pci_resource_len(pcidev, 0);
+   bars |= BIT(0);
  
  		dfl_fpga_enum_info_add_dfl(info, start, len);
  
@@ -253,9 +255,21 @@ static int find_dfls_by_default(struct pci_dev *pcidev,

 */
bar = FIELD_GET(FME_PORT_OFST_BAR_ID, v);
offset = FIELD_GET(FME_PORT_OFST_DFH_OFST, v);
+   if (bars & BIT(bar)) {
+   dev_warn(>dev, "skipping bad port BAR 
%d\n", bar);
+   continue;
+   }
+
start = pci_resource_start(pcidev, bar) + offset;
-   len = pci_resource_len(pcidev, bar) - offset;
+   len = pci_resource_len(pcidev, bar);
+   if (offset >= len) {
+   dev_warn(>dev, "bad port offset %u >= 
%pa\n",
+offset, );


why %pa, for instead of %u,len ?

Tom


+   continue;
+   }
  
+			len -= offset;

+   bars |= BIT(bar);
dfl_fpga_enum_info_add_dfl(info, start, len);
}
} else if (dfl_feature_is_port(base)) {

Re: Proposal of improvement for DMA - direct passing of hugepages to the SG list

[Tom Rix]

On 4/14/21 4:58 AM, w...@ise.pw.edu.pl wrote:

Hi,

I'm working both on DMA engines implementations in FPGA and their 
Linux drivers.
Now I need to create an engine that takes the hugepages-backed buffer 
allocated

by the user-space application and passes it to the device.
My current solution:

https://forums.xilinx.com/t5/Embedded-Linux/How-to-pass-efficiently-the-hugepages-backed-buffer-to-the-BM/m-p/1229340/highlight/true#M49777 


or https://stackoverflow.com/a/67065962/1735409

uses the get_user_pages_fast function, to create the kernel mapping,
and then uses sg_alloc_table_from_pages to build sg_table for it.

I have verified that the created sg_table has one entry for each 
individual

hugepage (so I can efficiently map it for my SG-capable DMA device).

The disadvantage of that solution is that I need to create and keep a 
huge set
of standard-size pages. Because the "struct page" occupies between 56 
and 80

bytes, I get the overhead up to 80/4096 which is approx. 2%.

The open question is if I can free those pages as soon as the sg_table
is created? (As far as I know, the hugepages are locked automatically).
Of course it is unclear what happens if the application crashes and 
its mmaped
hugepage-based buffer gets freed. Will the driver be notified about 
closing the

file so that it can disable DMA before that memory can be taken for other
purposes?

To be sure that it doesn't happen maybe it is good to keep those pages 
locked

in the kernel as well.
The big improvement would be if we could have the get_user_hugepages_fast
function. The user should be allowed to create a smaller number of 
page structs.
The function should check if the requested region really consists of 
hugepages

and return an error if it doesn't.

Another important fact is that we don't need a kernel mapping for 
those pages

at all. So it would be good to have yet another function:
sg_alloc_table_from_user_pages
which should take an additional "flag" argument enabling the user to 
decide

if the area used consists of normal pages or of hugepages.

The function should return an error in  case if the flag does not 
match the
properties of the region. Of course the function should also lock the 
pages,

and sg_free_table should unlock them (protecting against the danger
of application crash, that I described above).

As a temporary workaround, is it possible to "manually" walk the pages
creating the application-delivered buffer, verify that they are 
hugepages,

lock them and create the sg_table?
What functions/macros should be used for that to ensure that the 
implemented
solution be portable and keeps working in a reasonable number of 
future versions

of the Linux kernel?

I'll appreciate comments, suggestions and considering of the above 
proposal.

With best regards,
Wojtek


Do you have trial patch you could RFC ?

Are you aware of the xilinx qdma patchset ?

https://www.xilinx.com/support/answers/71453.html

https://github.com/Xilinx/dma_ip_drivers

Maybe its kernel or dpdk driver has what you need.

Tom

Re: [PATCH v9 1/1] mfd: intel-m10-bmc: support for MAX10 BMC Secure Updates

[Tom Rix]

On 4/12/21 12:53 PM, Russ Weight wrote:

Add macros and definitions required by the MAX10 BMC
Secure Update driver.

Signed-off-by: Russ Weight 
Acked-by: Lee Jones 
---
v9:
   - Rebased on next-20210412
v8:
   - Previously patch 1/6 in "Intel MAX10 BMC Secure Update Driver"
   - Rebased on next-20210121
v7:
   - No change
v6:
   - No change
v5:
   - Renamed USER_FLASH_COUNT to STAGING_FLASH_COUNT
v4:
   - No change
v3:
   - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure
 Update driver"
   - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The
 underlying functions will be called directly.
v2:
   - These functions and macros were previously distributed among
 the patches that needed them. They are now grouped together
 in a single patch containing changes to the Intel MAX10 BMC
 driver.
   - Added DRBL_ prefix to some definitions
   - Some address definitions were moved here from the .c files that
 use them.
---
  include/linux/mfd/intel-m10-bmc.h | 85 +++
  1 file changed, 85 insertions(+)

diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index c4eb38c13eda..f0044b14136e 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -16,6 +16,9 @@
  #define M10BMC_FLASH_END  0x1fff
  #define M10BMC_MEM_ENDM10BMC_FLASH_END
  
+#define M10BMC_STAGING_BASE		0x1800

+#define M10BMC_STAGING_SIZE0x380
+
  /* Register offset of system registers */
  #define NIOS2_FW_VERSION  0x0
  #define M10BMC_MAC_LOW0x10
@@ -33,6 +36,88 @@
  #define M10BMC_VER_PCB_INFO_MSK   GENMASK(31, 24)
  #define M10BMC_VER_LEGACY_INVALID 0x
  
+/* Secure update doorbell register, in system register region */

+#define M10BMC_DOORBELL0x400


To be consistent with the existing register #defines,

The bit values for the register should follow the register and have a 
M10BMC_ prefix


Tom


+
+/* Authorization Result register, in system register region */
+#define M10BMC_AUTH_RESULT 0x404
+
+/* Doorbell register fields */
+#define DRBL_RSU_REQUEST   BIT(0)
+#define DRBL_RSU_PROGRESS  GENMASK(7, 4)
+#define DRBL_HOST_STATUS   GENMASK(11, 8)
+#define DRBL_RSU_STATUSGENMASK(23, 16)
+#define DRBL_PKVL_EEPROM_LOAD_SEC  BIT(24)
+#define DRBL_PKVL1_POLL_EN BIT(25)
+#define DRBL_PKVL2_POLL_EN BIT(26)
+#define DRBL_CONFIG_SELBIT(28)
+#define DRBL_REBOOT_REQBIT(29)
+#define DRBL_REBOOT_DISABLED   BIT(30)
+
+/* Progress states */
+#define RSU_PROG_IDLE  0x0
+#define RSU_PROG_PREPARE   0x1
+#define RSU_PROG_READY 0x3
+#define RSU_PROG_AUTHENTICATING0x4
+#define RSU_PROG_COPYING   0x5
+#define RSU_PROG_UPDATE_CANCEL 0x6
+#define RSU_PROG_PROGRAM_KEY_HASH  0x7
+#define RSU_PROG_RSU_DONE  0x8
+#define RSU_PROG_PKVL_PROM_DONE0x9
+
+/* Device and error states */
+#define RSU_STAT_NORMAL0x0
+#define RSU_STAT_TIMEOUT   0x1
+#define RSU_STAT_AUTH_FAIL 0x2
+#define RSU_STAT_COPY_FAIL 0x3
+#define RSU_STAT_FATAL 0x4
+#define RSU_STAT_PKVL_REJECT   0x5
+#define RSU_STAT_NON_INC   0x6
+#define RSU_STAT_ERASE_FAIL0x7
+#define RSU_STAT_WEAROUT   0x8
+#define RSU_STAT_NIOS_OK   0x80
+#define RSU_STAT_USER_OK   0x81
+#define RSU_STAT_FACTORY_OK0x82
+#define RSU_STAT_USER_FAIL 0x83
+#define RSU_STAT_FACTORY_FAIL  0x84
+#define RSU_STAT_NIOS_FLASH_ERR0x85
+#define RSU_STAT_FPGA_FLASH_ERR0x86
+
+#define HOST_STATUS_IDLE   0x0
+#define HOST_STATUS_WRITE_DONE 0x1
+#define HOST_STATUS_ABORT_RSU  0x2
+
+#define rsu_prog(doorbell) FIELD_GET(DRBL_RSU_PROGRESS, doorbell)
+#define rsu_stat(doorbell) FIELD_GET(DRBL_RSU_STATUS, doorbell)
+
+/* interval 100ms and timeout 5s */
+#define NIOS_HANDSHAKE_INTERVAL_US (100 * 1000)
+#define NIOS_HANDSHAKE_TIMEOUT_US  (5 * 1000 * 1000)
+
+/* RSU PREP Timeout (2 minutes) to erase flash staging area */
+#define RSU_PREP_INTERVAL_MS   100
+#define RSU_PREP_TIMEOUT_MS(2 * 60 * 1000)
+
+/* RSU Complete Timeout (40 minutes) for full flash update */
+#define RSU_COMPLETE_INTERVAL_MS   1000
+#define RSU_COMPLETE_TIMEOUT_MS(40 * 60 * 1000)
+
+/* Addresses for security related data in FLASH */
+#define BMC_REH_ADDR   0x17ffc004
+#define BMC_PROG_ADDR  0x17ffc000
+#define BMC_PROG_MAGIC 0x5746
+
+#define SR_REH_ADDR0x17ffd004
+#define SR_PROG_ADDR   0x17ffd000
+#define SR_PROG_MAGIC  0x5253
+
+#define PR_REH_ADDR

Re: [PATCH V4 XRT Alveo 09/20] fpga: xrt: management physical function driver (root)

[Tom Rix]

On 4/9/21 11:50 AM, Max Zhen wrote:

Hi Tom,


On 3/31/21 6:03 AM, Tom Rix wrote:

On 3/23/21 10:29 PM, Lizhi Hou wrote:

The PCIE device driver which attaches to management function on Alveo
devices. It instantiates one or more group drivers which, in turn,
instantiate platform drivers. The instantiation of group and platform
drivers is completely dtb driven.

Signed-off-by: Sonal Santan
Signed-off-by: Max Zhen
Signed-off-by: Lizhi Hou
---
  drivers/fpga/xrt/mgmt/root.c | 333 
+++

  1 file changed, 333 insertions(+)
  create mode 100644 drivers/fpga/xrt/mgmt/root.c

diff --git a/drivers/fpga/xrt/mgmt/root.c 
b/drivers/fpga/xrt/mgmt/root.c

new file mode 100644
index ..f97f92807c01
--- /dev/null
+++ b/drivers/fpga/xrt/mgmt/root.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo Management Function Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ *   Cheng Zhen
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xroot.h"
+#include "xmgnt.h"
+#include "metadata.h"
+
+#define XMGMT_MODULE_NAME    "xrt-mgmt"

ok

+#define XMGMT_DRIVER_VERSION "4.0.0"
+
+#define XMGMT_PDEV(xm)   ((xm)->pdev)
+#define XMGMT_DEV(xm) (&(XMGMT_PDEV(xm)->dev))
+#define xmgmt_err(xm, fmt, args...)  \
+ dev_err(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_warn(xm, fmt, args...) \
+ dev_warn(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_info(xm, fmt, args...) \
+ dev_info(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_dbg(xm, fmt, args...)  \
+ dev_dbg(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define XMGMT_DEV_ID(_pcidev)    \
+ ({ typeof(_pcidev) (pcidev) = (_pcidev);    \
+ ((pci_domain_nr((pcidev)->bus) << 16) | \
+ PCI_DEVID((pcidev)->bus->number, 0)); })
+
+static struct class *xmgmt_class;
+
+/* PCI Device IDs */

add a comment on what a golden image is here something like

/*

* Golden image is preloaded on the device when it is shipped to 
customer.


* Then, customer can load other shells (from Xilinx or some other 
vendor).


* If something goes wrong with the shell, customer can always go back to

* golden and start over again.

*/



Will do.



+#define PCI_DEVICE_ID_U50_GOLDEN 0xD020
+#define PCI_DEVICE_ID_U50    0x5020
+static const struct pci_device_id xmgmt_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50_GOLDEN), 
}, /* Alveo U50 (golden) */
+ { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50), }, /* 
Alveo U50 */

+ { 0, }
+};
+
+struct xmgmt {
+ struct pci_dev *pdev;
+ void *root;
+
+ bool ready;
+};
+
+static int xmgmt_config_pci(struct xmgmt *xm)
+{
+ struct pci_dev *pdev = XMGMT_PDEV(xm);
+ int rc;
+
+ rc = pcim_enable_device(pdev);
+ if (rc < 0) {
+ xmgmt_err(xm, "failed to enable device: %d", rc);
+ return rc;
+ }
+
+ rc = pci_enable_pcie_error_reporting(pdev);
+ if (rc)

ok

+ xmgmt_warn(xm, "failed to enable AER: %d", rc);
+
+ pci_set_master(pdev);
+
+ rc = pcie_get_readrq(pdev);
+ if (rc > 512)

512 is magic number, change this to a #define



Will do.



+ pcie_set_readrq(pdev, 512);
+ return 0;
+}
+
+static int xmgmt_match_slot_and_save(struct device *dev, void *data)
+{
+ struct xmgmt *xm = data;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (XMGMT_DEV_ID(pdev) == XMGMT_DEV_ID(xm->pdev)) {
+ pci_cfg_access_lock(pdev);
+ pci_save_state(pdev);
+ }
+
+ return 0;
+}
+
+static void xmgmt_pci_save_config_all(struct xmgmt *xm)
+{
+ bus_for_each_dev(_bus_type, NULL, xm, 
xmgmt_match_slot_and_save);

refactor expected in v5 when pseudo bus change happens.



There might be some mis-understanding here...

No matter how we reorganize our code (using platform_device bus type 
or defining our own bus type), it's a driver that drives a PCIE device 
after all. So, this mgmt/root.c must be a PCIE driver, which may 
interact with a whole bunch of IP drivers through a pseudo bus we are 
about to create.


What this code is doing here is completely of PCIE business (PCIE 
config space access). So, I think it is appropriate code in a PCIE 
driver.


The PCIE device we are driving is a multi-function device. The mgmt pf 
is of function 0, which, according to PCIE spec, can manage other 
functions on the same device. So, I think it's appropriate for mgmt pf 
driver (this root driver) to find it's peer function (through PCIE bus 
type) on the same device and do something about it in certain special 
cases.


Please let me know why you expect this code to be refactored and how 
you want it to be refactored. I might have missed something here...



ok, i get it.

Re: [PATCH v2 2/2] hwmon: intel-m10-bmc-hwmon: add sensor support of Intel D5005 card

[Tom Rix]

On 4/13/21 3:58 PM, matthew.gerl...@linux.intel.com wrote:

From: Matthew Gerlach 

Like the Intel N3000 card, the Intel D5005 has a MAX10 based
BMC.  This commit adds support for the D5005 sensors that are
monitored by the MAX10 BMC.

Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
Acked-by: Lee Jones 


lgtm

Reviewed-by: Tom Rix 


---
v2: change variable name from m10bmc_bmc_subdevs to m10bmc_d5005_subdevs
 added Acked-by: Lee Jones
---
  drivers/hwmon/intel-m10-bmc-hwmon.c | 122 
  drivers/mfd/intel-m10-bmc.c |  10 +++
  2 files changed, 132 insertions(+)

diff --git a/drivers/hwmon/intel-m10-bmc-hwmon.c 
b/drivers/hwmon/intel-m10-bmc-hwmon.c
index 17d5e6b..bd7ed2e 100644
--- a/drivers/hwmon/intel-m10-bmc-hwmon.c
+++ b/drivers/hwmon/intel-m10-bmc-hwmon.c
@@ -99,6 +99,50 @@ struct m10bmc_hwmon {
NULL
  };
  
+static const struct m10bmc_sdata d5005bmc_temp_tbl[] = {

+   { 0x100, 0x104, 0x108, 0x10c, 0x0, 500, "Board Inlet Air Temperature" },
+   { 0x110, 0x114, 0x118, 0x0, 0x0, 500, "FPGA Core Temperature" },
+   { 0x11c, 0x120, 0x124, 0x128, 0x0, 500, "Board Exhaust Air Temperature" 
},
+   { 0x12c, 0x130, 0x134, 0x0, 0x0, 500, "FPGA Transceiver Temperature" },
+   { 0x138, 0x13c, 0x140, 0x144, 0x0, 500, "RDIMM0 Temperature" },
+   { 0x148, 0x14c, 0x150, 0x154, 0x0, 500, "RDIMM1 Temperature" },
+   { 0x158, 0x15c, 0x160, 0x164, 0x0, 500, "RDIMM2 Temperature" },
+   { 0x168, 0x16c, 0x170, 0x174, 0x0, 500, "RDIMM3 Temperature" },
+   { 0x178, 0x17c, 0x180, 0x0, 0x0, 500, "QSFP0 Temperature" },
+   { 0x188, 0x18c, 0x190, 0x0, 0x0, 500, "QSFP1 Temperature" },
+   { 0x1a0, 0x1a4, 0x1a8, 0x0, 0x0, 500, "3.3v Temperature" },
+   { 0x1bc, 0x1c0, 0x1c4, 0x0, 0x0, 500, "VCCERAM Temperature" },
+   { 0x1d8, 0x1dc, 0x1e0, 0x0, 0x0, 500, "VCCR Temperature" },
+   { 0x1f4, 0x1f8, 0x1fc, 0x0, 0x0, 500, "VCCT Temperature" },
+   { 0x210, 0x214, 0x218, 0x0, 0x0, 500, "1.8v Temperature" },
+   { 0x22c, 0x230, 0x234, 0x0, 0x0, 500, "12v Backplane Temperature" },
+   { 0x248, 0x24c, 0x250, 0x0, 0x0, 500, "12v AUX Temperature" },
+};
+
+static const struct m10bmc_sdata d5005bmc_in_tbl[] = {
+   { 0x184, 0x0, 0x0, 0x0, 0x0, 1, "QSFP0 Supply Voltage" },
+   { 0x194, 0x0, 0x0, 0x0, 0x0, 1, "QSFP1 Supply Voltage" },
+   { 0x198, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Voltage" },
+   { 0x1ac, 0x1b0, 0x1b4, 0x0, 0x0, 1, "3.3v Voltage" },
+   { 0x1c8, 0x1cc, 0x1d0, 0x0, 0x0, 1, "VCCERAM Voltage" },
+   { 0x1e4, 0x1e8, 0x1ec, 0x0, 0x0, 1, "VCCR Voltage" },
+   { 0x200, 0x204, 0x208, 0x0, 0x0, 1, "VCCT Voltage" },
+   { 0x21c, 0x220, 0x224, 0x0, 0x0, 1, "1.8v Voltage" },
+   { 0x238, 0x0, 0x0, 0x0, 0x23c, 1, "12v Backplane Voltage" },
+   { 0x254, 0x0, 0x0, 0x0, 0x258, 1, "12v AUX Voltage" },
+};
+
+static const struct m10bmc_sdata d5005bmc_curr_tbl[] = {
+   { 0x19c, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Current" },
+   { 0x1b8, 0x0, 0x0, 0x0, 0x0, 1, "3.3v Current" },
+   { 0x1d4, 0x0, 0x0, 0x0, 0x0, 1, "VCCERAM Current" },
+   { 0x1f0, 0x0, 0x0, 0x0, 0x0, 1, "VCCR Current" },
+   { 0x20c, 0x0, 0x0, 0x0, 0x0, 1, "VCCT Current" },
+   { 0x228, 0x0, 0x0, 0x0, 0x0, 1, "1.8v Current" },
+   { 0x240, 0x244, 0x0, 0x0, 0x0, 1, "12v Backplane Current" },
+   { 0x25c, 0x260, 0x0, 0x0, 0x0, 1, "12v AUX Current" },
+};
+
  static const struct m10bmc_hwmon_board_data n3000bmc_hwmon_bdata = {
.tables = {
[hwmon_temp] = n3000bmc_temp_tbl,
@@ -110,6 +154,80 @@ struct m10bmc_hwmon {
.hinfo = n3000bmc_hinfo,
  };
  
+static const struct hwmon_channel_info *d5005bmc_hinfo[] = {

+   HWMON_CHANNEL_INFO(temp,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+  HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+  HWMON_T_LABEL,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+  HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+  HWMON_T_LABEL,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+  HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+  HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+  HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+

Re: [PATCH v2 1/2] spi: Add DFL bus driver for Altera SPI Master

[Tom Rix]

On 4/13/21 3:58 PM, matthew.gerl...@linux.intel.com wrote:

From: Matthew Gerlach 

This patch adds a Device Feature List (DFL) bus driver for the
Altera SPI Master controller.  The SPI master is connected to an
Intel SPI Slave to Avalon Master Bridge inside an Intel MAX10
BMC Chip.

Signed-off-by: Matthew Gerlach 
---
v2: moved drivers/fpga/dfl-spi-altera.c to drivers/spi/spi-altera-dfl.c
---
  drivers/spi/Kconfig  |   9 ++
  drivers/spi/Makefile |   1 +
  drivers/spi/spi-altera-dfl.c | 222 +++

does this need a MAINTAINER's entry ?

  3 files changed, 232 insertions(+)
  create mode 100644 drivers/spi/spi-altera-dfl.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 853cf4c..6c6798e 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -63,6 +63,15 @@ config SPI_ALTERA
help
  This is the driver for the Altera SPI Controller.
  
+config SPI_ALTERA_DFL

+   tristate "DFL driver for Altera SPI Controller"
+   depends on FPGA_DFL
+   select SPI_ALTERA
+   help
+ This is a Device Feature List (DFL) bus driver for the
+ Altera SPI master controller.  The SPI master is connected
+ to a SPI slave to Avalon Master bridge in a Intel MAX BMC.


Last sentence is a little confusing with two 'masters', could this be

The SPI master is connected to the Avalon SPI bridge in the Intel Max10 BMC.

?


+
  config SPI_AR934X
tristate "Qualcomm Atheros AR934X/QCA95XX SPI controller driver"
depends on ATH79 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 29fee71..2e348ea 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST)   += 
spi-loopback-test.o
  
  # SPI master controller drivers (bus)

  obj-$(CONFIG_SPI_ALTERA)  += spi-altera.o
+obj-$(CONFIG_SPI_ALTERA_DFL)   += spi-altera-dfl.o
  obj-$(CONFIG_SPI_AR934X)  += spi-ar934x.o
  obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
  obj-$(CONFIG_SPI_ATMEL)   += spi-atmel.o
diff --git a/drivers/spi/spi-altera-dfl.c b/drivers/spi/spi-altera-dfl.c
new file mode 100644
index 000..8ddfc5d
--- /dev/null
+++ b/drivers/spi/spi-altera-dfl.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL bus driver for Altera SPI Master
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ *
+ * Authors:
+ *   Matthew Gerlach 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dfl_altera_spi {
+   void __iomem *base;
+   struct regmap *regmap;
+   struct device *dev;
+   struct platform_device *altr_spi;

the read/write can take a while, is a lock needed ?

+};
+
+#define SPI_CORE_PARAMETER  0x8
a prefix would like 'DFL_' would make this less likely to have namespace 
issues.

+#define SHIFT_MODE  BIT_ULL(1)
+#define SHIFT_MODE_MSB  0
+#define SHIFT_MODE_LSB  1
+#define DATA_WIDTH  GENMASK_ULL(7, 2)
+#define NUM_CHIPSELECT  GENMASK_ULL(13, 8)
+#define CLK_POLARITYBIT_ULL(14)
+#define CLK_PHASE   BIT_ULL(15)
+#define PERIPHERAL_ID   GENMASK_ULL(47, 32)
+#define SPI_CLK GENMASK_ULL(31, 22)
+#define SPI_INDIRECT_ACC_OFST   0x10
+
+#define INDIRECT_ADDR   (SPI_INDIRECT_ACC_OFST+0x0)
checkpatch --strict complains here and similar, preferring spaces around 
the '+'

+#define INDIRECT_WR BIT_ULL(8)
+#define INDIRECT_RD BIT_ULL(9)
+#define INDIRECT_RD_DATA(SPI_INDIRECT_ACC_OFST+0x8)
+#define INDIRECT_DATA_MASK  GENMASK_ULL(31, 0)
+#define INDIRECT_DEBUG  BIT_ULL(32)
+#define INDIRECT_WR_DATA(SPI_INDIRECT_ACC_OFST+0x10)
+#define INDIRECT_TIMEOUT1

this does not have units of time, maybe rename to INDIRECT_RETRY_COUNT

+
+static int indirect_bus_reg_read(void *context, unsigned int reg,
+unsigned int *val)
+{
+   struct dfl_altera_spi *aspi = context;
+   void __iomem *base = aspi->base;
+   int loops;

could initialize loop here

+   u64 v;
+
+   writeq((reg >> 2) | INDIRECT_RD, base + INDIRECT_ADDR);

is input 'reg' checked elsewhere ?

+
+   loops = 0;
+   while ((readq(base + INDIRECT_ADDR) & INDIRECT_RD) &&
+  (loops++ < INDIRECT_TIMEOUT))
+   cpu_relax();
+
+   if (loops >= INDIRECT_TIMEOUT) {
+   pr_err("%s timed out %d\n", __func__, loops);
+   return -ETIME;

maybe -EBUSY ?

+   }
+
+   v = readq(base + INDIRECT_RD_DATA);
+
+   *val = v & INDIRECT_DATA_MASK;
+
+   return 0;
+}
+
+static int indirect_bus_reg_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+   struct dfl_altera_spi *aspi = context;
+   

Re: [PATCH] fpga: xilinx-pr-decoupler: remove useless function

[Tom Rix]

On 4/12/21 8:51 PM, Jiapeng Chong wrote:

Fix the following gcc warning:

drivers/fpga/xilinx-pr-decoupler.c:32:19: warning: unused function
'xlnx_pr_decouple_read' [-Wunused-function].

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
  drivers/fpga/xilinx-pr-decoupler.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/fpga/xilinx-pr-decoupler.c 
b/drivers/fpga/xilinx-pr-decoupler.c
index 7d69af2..f407cb2 100644
--- a/drivers/fpga/xilinx-pr-decoupler.c
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -29,12 +29,6 @@ static inline void xlnx_pr_decoupler_write(struct 
xlnx_pr_decoupler_data *d,
writel(val, d->io_base + offset);
  }
  
-static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,

-   u32 offset)
-{
-   return readl(d->io_base + offset);
-}
-


I am not in favor of removing this function.

It should have been used in xlnx_pr_decoupler_enable_show() instead of 
the bare readl().


So use it in this function, and for consistency rename to 
xlnx_pr_decoupler_read()


that is 'decouple' -> 'decoupler'

Tom


  static int xlnx_pr_decoupler_enable_set(struct fpga_bridge *bridge, bool 
enable)
  {
int err;

Re: [PATCH V4 XRT Alveo 20/20] fpga: xrt: Kconfig and Makefile updates for XRT drivers

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:

Update fpga Kconfig/Makefile and add Kconfig/Makefile for new drivers.

Signed-off-by: Sonal Santan 
Signed-off-by: Max Zhen 
Signed-off-by: Lizhi Hou 
---
  MAINTAINERS| 11 +++
  drivers/Makefile   |  1 +
  drivers/fpga/Kconfig   |  2 ++
  drivers/fpga/Makefile  |  5 +
  drivers/fpga/xrt/Kconfig   |  8 
  drivers/fpga/xrt/lib/Kconfig   | 17 +
  drivers/fpga/xrt/lib/Makefile  | 30 ++
  drivers/fpga/xrt/metadata/Kconfig  | 12 
  drivers/fpga/xrt/metadata/Makefile | 16 
  drivers/fpga/xrt/mgmt/Kconfig  | 15 +++
  drivers/fpga/xrt/mgmt/Makefile | 19 +++
  11 files changed, 136 insertions(+)
  create mode 100644 drivers/fpga/xrt/Kconfig
  create mode 100644 drivers/fpga/xrt/lib/Kconfig
  create mode 100644 drivers/fpga/xrt/lib/Makefile
  create mode 100644 drivers/fpga/xrt/metadata/Kconfig
  create mode 100644 drivers/fpga/xrt/metadata/Makefile
  create mode 100644 drivers/fpga/xrt/mgmt/Kconfig
  create mode 100644 drivers/fpga/xrt/mgmt/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index aa84121c5611..44ccc52987ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7009,6 +7009,17 @@ F:   Documentation/fpga/
  F:drivers/fpga/
  F:include/linux/fpga/
  
+FPGA XRT DRIVERS

+M: Lizhi Hou 
+R: Max Zhen 
+R: Sonal Santan 
+L: linux-f...@vger.kernel.org
+S: Maintained

Should this be 'Supported' ?

+W: https://github.com/Xilinx/XRT
+F: Documentation/fpga/xrt.rst
+F: drivers/fpga/xrt/
+F: include/uapi/linux/xrt/
+
  FPU EMULATOR
  M:Bill Metzenthen 
  S:Maintained
diff --git a/drivers/Makefile b/drivers/Makefile
index 6fba7daba591..dbb3b727fc7a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
  obj-$(CONFIG_ANDROID) += android/
  obj-$(CONFIG_NVMEM)   += nvmem/
  obj-$(CONFIG_FPGA)+= fpga/
+obj-$(CONFIG_FPGA_XRT_METADATA) += fpga/
CONFIG_FPGA_XRT_METADATA is only defined when CONFIG_FPGA is, so i don't 
think this line is needed.

  obj-$(CONFIG_FSI) += fsi/
  obj-$(CONFIG_TEE) += tee/
  obj-$(CONFIG_MULTIPLEXER) += mux/
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5ff9438b7b46..01410ff000b9 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -227,4 +227,6 @@ config FPGA_MGR_ZYNQMP_FPGA
  to configure the programmable logic(PL) through PS
  on ZynqMP SoC.
  
+source "drivers/fpga/xrt/Kconfig"

+
  endif # FPGA

This is where it is defined..

diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 18dc9885883a..4b887bf95cb3 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -48,3 +48,8 @@ obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)   += 
dfl-n3000-nios.o
  
  # Drivers for FPGAs which implement DFL

  obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o
+
+# XRT drivers for Alveo
+obj-$(CONFIG_FPGA_XRT_METADATA)+= xrt/metadata/
+obj-$(CONFIG_FPGA_XRT_LIB) += xrt/lib/
+obj-$(CONFIG_FPGA_XRT_XMGMT)   += xrt/mgmt/
diff --git a/drivers/fpga/xrt/Kconfig b/drivers/fpga/xrt/Kconfig
new file mode 100644
index ..0e2c59589ddd
--- /dev/null
+++ b/drivers/fpga/xrt/Kconfig
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Xilinx Alveo FPGA device configuration
+#
+
+source "drivers/fpga/xrt/metadata/Kconfig"
+source "drivers/fpga/xrt/lib/Kconfig"
+source "drivers/fpga/xrt/mgmt/Kconfig"
diff --git a/drivers/fpga/xrt/lib/Kconfig b/drivers/fpga/xrt/lib/Kconfig
new file mode 100644
index ..935369fad570
--- /dev/null
+++ b/drivers/fpga/xrt/lib/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# XRT Alveo FPGA device configuration
+#
+
+config FPGA_XRT_LIB
+   tristate "XRT Alveo Driver Library"
+   depends on HWMON && PCI && HAS_IOMEM
+   select FPGA_XRT_METADATA
+   select REGMAP_MMIO
+   help
+ Select this option to enable Xilinx XRT Alveo driver library. This
+ library is core infrastructure of XRT Alveo FPGA drivers which
+ provides functions for working with device nodes, iteration and
+ lookup of platform devices, common interfaces for platform devices,
+ plumbing of function call and ioctls between platform devices and
+ parent partitions.
diff --git a/drivers/fpga/xrt/lib/Makefile b/drivers/fpga/xrt/lib/Makefile
new file mode 100644
index ..58563416efbf
--- /dev/null
+++ b/drivers/fpga/xrt/lib/Makefile
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2020-2021 Xilinx, Inc. All rights reserved.
+#
+# Authors: sonal.san...@xilinx.com
+#
+
+FULL_XRT_PATH=$(srctree)/$(src)/..
+FULL_DTC_PATH=$(srctree)/scripts/dtc/libfdt
+
+obj-$(CONFIG_FPGA_XRT_LIB) 

Re: [PATCH V4 XRT Alveo 19/20] fpga: xrt: partition isolation platform driver

[Tom Rix]

ot;, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int xrt_axigate_epname_idx(struct platform_device *pdev)
+{
+   struct resource *res;
+   int ret, i;

ok

+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   xrt_err(pdev, "Empty Resource!");
+   return -EINVAL;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(xrt_axigate_epnames); i++) {

ok

+   ret = strncmp(xrt_axigate_epnames[i], res->name,
+ strlen(xrt_axigate_epnames[i]) + 1);

ok

+   if (!ret)
+   return i;
+   }
+
+   return -EINVAL;
+}
+
+static int xrt_axigate_close(struct platform_device *pdev)
+{
+   struct xrt_axigate *gate;
+   u32 status = 0;
+   int ret;
+
+   gate = platform_get_drvdata(pdev);
+
+   mutex_lock(>gate_lock);
+   ret = regmap_read(gate->regmap, XRT_AXIGATE_READ_REG, );
+   if (ret) {
+   xrt_err(pdev, "read gate failed %d", ret);
+   goto failed;
+   }
+   if (status) {   /* gate is opened */
+   xleaf_broadcast_event(pdev, XRT_EVENT_PRE_GATE_CLOSE, false);
+   ret = close_gate(gate);

ok

+   if (ret)
+   goto failed;
+   }
+
+   gate->gate_closed = true;

ok

+
+failed:
+   mutex_unlock(>gate_lock);
+
+   xrt_info(pdev, "close gate %s", gate->ep_name);
+   return ret;
+}
+
+static int xrt_axigate_open(struct platform_device *pdev)
+{
+   struct xrt_axigate *gate;
+   u32 status;
+   int ret;
+
+   gate = platform_get_drvdata(pdev);
+
+   mutex_lock(>gate_lock);
+   ret = regmap_read(gate->regmap, XRT_AXIGATE_READ_REG, );
+   if (ret) {
+   xrt_err(pdev, "read gate failed %d", ret);
+   goto failed;
+   }
+   if (!status) {  /* gate is closed */
+   ret = open_gate(gate);
+   if (ret)
+   goto failed;
+   xleaf_broadcast_event(pdev, XRT_EVENT_POST_GATE_OPEN, true);
+   /* xrt_axigate_open() could be called in event cb, thus
+* we can not wait for the completes
+*/
+   }
+
+   gate->gate_closed = false;
+
+failed:
+   mutex_unlock(>gate_lock);
+
+   xrt_info(pdev, "open gate %s", gate->ep_name);
+   return ret;
+}
+
+static void xrt_axigate_event_cb(struct platform_device *pdev, void *arg)
+{
+   struct xrt_axigate *gate = platform_get_drvdata(pdev);
+   struct xrt_event *evt = (struct xrt_event *)arg;
+   enum xrt_events e = evt->xe_evt;
+   struct platform_device *leaf;
+   enum xrt_subdev_id id;
+   struct resource *res;
+   int instance;
+
+   if (e != XRT_EVENT_POST_CREATION)
+   return;
+
+   instance = evt->xe_subdev.xevt_subdev_instance;
+   id = evt->xe_subdev.xevt_subdev_id;
+   if (id != XRT_SUBDEV_AXIGATE)
+   return;

ok

+
+   leaf = xleaf_get_leaf_by_id(pdev, id, instance);
+   if (!leaf)
+   return;
+
+   res = platform_get_resource(leaf, IORESOURCE_MEM, 0);
+   if (!res || !strncmp(res->name, gate->ep_name, strlen(res->name) + 1)) {
+   xleaf_put_leaf(pdev, leaf);
+   return;
+   }
+
+   /* higher level axigate instance created, make sure the gate is opened. 
*/


ok

only minor ws issue, otherwise good to go

Reviewed-by: Tom Rix 


+   if (xrt_axigate_epname_idx(leaf) > xrt_axigate_epname_idx(pdev))
+   xrt_axigate_open(pdev);
+   else
+   xleaf_call(leaf, XRT_AXIGATE_OPEN, NULL);
+
+   xleaf_put_leaf(pdev, leaf);
+}
+
+static int
+xrt_axigate_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+   int ret = 0;
+
+   switch (cmd) {
+   case XRT_XLEAF_EVENT:
+   xrt_axigate_event_cb(pdev, arg);
+   break;
+   case XRT_AXIGATE_CLOSE:
+   ret = xrt_axigate_close(pdev);
+   break;
+   case XRT_AXIGATE_OPEN:
+   ret = xrt_axigate_open(pdev);
+   break;
+   default:
+   xrt_err(pdev, "unsupported cmd %d", cmd);
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+static int xrt_axigate_probe(struct platform_device *pdev)
+{
+   struct xrt_axigate *gate = NULL;
+   void __iomem *base = NULL;
+   struct resource *res;
+   int ret;
+
+   gate = devm_kzalloc(>dev, sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   return -ENOMEM;
+
+   gate->pdev = pdev;
+   platform_set_drvdata(pdev, gate);
+
+   xrt_info(pdev, "probing...");
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   xrt_err(pdev, &

Re: [PATCH V4 XRT Alveo 18/20] fpga: xrt: DDR calibration platform driver

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:

Add DDR calibration driver. DDR calibration is a hardware function
discovered by walking firmware metadata. A platform device node will
be created for it. Hardware provides DDR calibration status through
this function.

Signed-off-by: Sonal Santan 
Signed-off-by: Max Zhen 
Signed-off-by: Lizhi Hou 
---
  .../fpga/xrt/include/xleaf/ddr_calibration.h  |  28 +++
  drivers/fpga/xrt/lib/xleaf/ddr_calibration.c  | 226 ++

ok

  2 files changed, 254 insertions(+)
  create mode 100644 drivers/fpga/xrt/include/xleaf/ddr_calibration.h
  create mode 100644 drivers/fpga/xrt/lib/xleaf/ddr_calibration.c

diff --git a/drivers/fpga/xrt/include/xleaf/ddr_calibration.h 
b/drivers/fpga/xrt/include/xleaf/ddr_calibration.h
new file mode 100644
index ..878740c26ca2
--- /dev/null
+++ b/drivers/fpga/xrt/include/xleaf/ddr_calibration.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Cheng Zhen 
+ */
+
+#ifndef _XRT_DDR_CALIBRATION_H_
+#define _XRT_DDR_CALIBRATION_H_
+
+#include "xleaf.h"
+#include 
+
+/*
+ * Memory calibration driver leaf calls.
+ */
+enum xrt_calib_results {
+   XRT_CALIB_UNKNOWN = 0,

ok

+   XRT_CALIB_SUCCEEDED,
+   XRT_CALIB_FAILED,
+};
+
+enum xrt_calib_leaf_cmd {
+   XRT_CALIB_RESULT = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
+};
+
+#endif /* _XRT_DDR_CALIBRATION_H_ */
diff --git a/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c 
b/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
new file mode 100644
index ..5a9fa82946cb
--- /dev/null
+++ b/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA memory calibration driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * memory calibration
+ *
+ * Authors:
+ *  Lizhi Hou
+ */
+#include 
+#include 
+#include "xclbin-helper.h"
+#include "metadata.h"
+#include "xleaf/ddr_calibration.h"
+
+#define XRT_CALIB  "xrt_calib"
+
+#define XRT_CALIB_STATUS_REG   0
+#define XRT_CALIB_READ_RETRIES 20
+#define XRT_CALIB_READ_INTERVAL500 /* ms */
+
+static const struct regmap_config calib_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .max_register = 0x1000,

ok

+};
+
+struct calib_cache {
+   struct list_headlink;
+   const char  *ep_name;
+   char*data;
+   u32 data_size;
+};
+
+struct calib {
+   struct platform_device  *pdev;
+   struct regmap   *regmap;
+   struct mutexlock; /* calibration dev lock */
+   struct list_headcache_list;
+   u32 cache_num;
+   enum xrt_calib_results  result;
+};
+
+static void __calib_cache_clean_nolock(struct calib *calib)

ok

+{
+   struct calib_cache *cache, *temp;
+
+   list_for_each_entry_safe(cache, temp, >cache_list, link) {
+   vfree(cache->data);
+   list_del(>link);
+   vfree(cache);
+   }
+   calib->cache_num = 0;
+}
+
+static void calib_cache_clean(struct calib *calib)
+{
+   mutex_lock(>lock);
+   __calib_cache_clean_nolock(calib);
+   mutex_unlock(>lock);
+}
+
+static int calib_calibration(struct calib *calib)
+{
+   u32 times = XRT_CALIB_READ_RETRIES;

ok

+   u32 status;
+   int ret;
+
+   while (times != 0) {
+   ret = regmap_read(calib->regmap, XRT_CALIB_STATUS_REG, );
+   if (ret) {
+   xrt_err(calib->pdev, "failed to read status reg %d", 
ret);
+   return ret;
+   }
+
+   if (status & BIT(0))
+           break;
+   msleep(XRT_CALIB_READ_INTERVAL);


ok

Reviewed-by: Tom Rix 


+   times--;
+   }
+
+   if (!times) {
+   xrt_err(calib->pdev,
+   "MIG calibration timeout after bitstream download");
+   return -ETIMEDOUT;
+   }
+
+   xrt_info(calib->pdev, "took %dms", (XRT_CALIB_READ_RETRIES - times) *
+XRT_CALIB_READ_INTERVAL);
+   return 0;
+}
+
+static void xrt_calib_event_cb(struct platform_device *pdev, void *arg)
+{
+   struct calib *calib = platform_get_drvdata(pdev);
+   struct xrt_event *evt = (struct xrt_event *)arg;
+   enum xrt_events e = evt->xe_evt;
+   enum xrt_subdev_id id;
+   int ret;
+
+   id = evt->xe_subdev.xevt_subdev_id;
+
+   switch (e) {
+   case XRT_EVENT_POST_CREATION:
+   if (id == XRT_SUBDEV_UCS) {
+   ret = calib_calibration(calib);
+   if (ret)
+   calib->result = XRT_CALIB_FAILED;
+ 

Re: [PATCH V4 XRT Alveo 17/20] fpga: xrt: clock frequency counter platform driver

[Tom Rix]

   return -EINVAL;

ok

+
+   count = snprintf(buf, 64, "%u\n", freq);

ok

+
+   return count;
+}
+static DEVICE_ATTR_RO(freq);
+
+static struct attribute *clkfreq_attrs[] = {
+   _attr_freq.attr,
+   NULL,
+};
+
+static struct attribute_group clkfreq_attr_group = {
+   .attrs = clkfreq_attrs,
+};
+
+static int
+xrt_clkfreq_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+   struct clkfreq *clkfreq;
+   int ret = 0;
+
+   clkfreq = platform_get_drvdata(pdev);
+
+   switch (cmd) {
+   case XRT_XLEAF_EVENT:
+   /* Does not handle any event. */
+   break;
+   case XRT_CLKFREQ_READ:

ok

+   ret = clkfreq_read(clkfreq, arg);

ok

+   break;
+   default:
+   xrt_err(pdev, "unsupported cmd %d", cmd);
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+static int clkfreq_remove(struct platform_device *pdev)
+{
+   sysfs_remove_group(>dev.kobj, _attr_group);
+
+   return 0;
+}
+
+static int clkfreq_probe(struct platform_device *pdev)
+{
+   struct clkfreq *clkfreq = NULL;
+   void __iomem *base = NULL;
+   struct resource *res;
+   int ret;
+
+   clkfreq = devm_kzalloc(>dev, sizeof(*clkfreq), GFP_KERNEL);
+   if (!clkfreq)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, clkfreq);
+   clkfreq->pdev = pdev;
+   mutex_init(>clkfreq_lock);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   ret = -EINVAL;
+   goto failed;
+   }
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base)) {
+   ret = PTR_ERR(base);
+   goto failed;
+   }
+
+   clkfreq->regmap = devm_regmap_init_mmio(>dev, base, 
_regmap_config);
+   if (IS_ERR(clkfreq->regmap)) {
+   CLKFREQ_ERR(clkfreq, "regmap %pR failed", res);
+   ret = PTR_ERR(clkfreq->regmap);
+   goto failed;
+   }
+   clkfreq->clkfreq_ep_name = res->name;
+
+   ret = sysfs_create_group(>dev.kobj, _attr_group);
+   if (ret) {
+   CLKFREQ_ERR(clkfreq, "create clkfreq attrs failed: %d", ret);
+   goto failed;
+   }
+
+   CLKFREQ_INFO(clkfreq, "successfully initialized clkfreq subdev");
+
+   return 0;
+
+failed:
+   return ret;
+}
+
+static struct xrt_subdev_endpoints xrt_clkfreq_endpoints[] = {
+   {
+   .xse_names = (struct xrt_subdev_ep_names[]) {
+   { .regmap_name = XRT_MD_REGMAP_CLKFREQ },


ok

Looks good to me

Reviewed-by: Tom Rix 


+   { NULL },
+   },
+   .xse_min_ep = 1,
+   },
+   { 0 },
+};
+
+static struct xrt_subdev_drvdata xrt_clkfreq_data = {
+   .xsd_dev_ops = {
+   .xsd_leaf_call = xrt_clkfreq_leaf_call,
+   },
+};
+
+static const struct platform_device_id xrt_clkfreq_table[] = {
+   { XRT_CLKFREQ, (kernel_ulong_t)_clkfreq_data },
+   { },
+};
+
+static struct platform_driver xrt_clkfreq_driver = {
+   .driver = {
+   .name = XRT_CLKFREQ,
+   },
+   .probe = clkfreq_probe,
+   .remove = clkfreq_remove,
+   .id_table = xrt_clkfreq_table,
+};
+
+XRT_LEAF_INIT_FINI_FUNC(XRT_SUBDEV_CLKFREQ, clkfreq);

Re: [PATCH V4 XRT Alveo 16/20] fpga: xrt: clock platform driver

[Tom Rix]

L);
+   if (err) {
+   xrt_info(clock->pdev, "no default freq");
+   return 0;
+   }
+
+   err = set_freq(clock, be16_to_cpu(*freq));
+
+   return err;
+}
+
+static ssize_t freq_show(struct device *dev, struct device_attribute *attr, 
char *buf)
+{
+   struct clock *clock = platform_get_drvdata(to_platform_device(dev));
+   ssize_t count;
+   u16 freq = 0;
+
+   count = clock_get_freq(clock, , NULL);
+   if (count < 0)
+   return count;
+
+   count = snprintf(buf, 64, "%u\n", freq);


ok

Thanks for the changes

Reviewed-by: Tom Rix 


+
+   return count;
+}
+static DEVICE_ATTR_RO(freq);
+
+static struct attribute *clock_attrs[] = {
+   _attr_freq.attr,
+   NULL,
+};
+
+static struct attribute_group clock_attr_group = {
+   .attrs = clock_attrs,
+};
+
+static int
+xrt_clock_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+   struct clock *clock;
+   int ret = 0;
+
+   clock = platform_get_drvdata(pdev);
+
+   switch (cmd) {
+   case XRT_XLEAF_EVENT:
+   /* Does not handle any event. */
+   break;
+   case XRT_CLOCK_SET: {
+   u16 freq = (u16)(uintptr_t)arg;
+
+   ret = set_freq(clock, freq);
+   break;
+   }
+   case XRT_CLOCK_VERIFY:
+   ret = clock_verify_freq(clock);
+   break;
+   case XRT_CLOCK_GET: {
+   struct xrt_clock_get *get =
+   (struct xrt_clock_get *)arg;
+
+   ret = clock_get_freq(clock, >freq, >freq_cnter);
+   break;
+   }
+   default:
+   xrt_err(pdev, "unsupported cmd %d", cmd);
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+static int clock_remove(struct platform_device *pdev)
+{
+   sysfs_remove_group(>dev.kobj, _attr_group);
+
+   return 0;
+}
+
+static int clock_probe(struct platform_device *pdev)
+{
+   struct clock *clock = NULL;
+   void __iomem *base = NULL;
+   struct resource *res;
+   int ret;
+
+   clock = devm_kzalloc(>dev, sizeof(*clock), GFP_KERNEL);
+   if (!clock)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, clock);
+   clock->pdev = pdev;
+   mutex_init(>clock_lock);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   ret = -EINVAL;
+   goto failed;
+   }
+
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base)) {
+   ret = PTR_ERR(base);
+   goto failed;
+   }
+
+   clock->regmap = devm_regmap_init_mmio(>dev, base, 
_regmap_config);
+   if (IS_ERR(clock->regmap)) {
+   CLOCK_ERR(clock, "regmap %pR failed", res);
+   ret = PTR_ERR(clock->regmap);
+   goto failed;
+   }
+   clock->clock_ep_name = res->name;
+
+   ret = clock_init(clock);
+   if (ret)
+   goto failed;
+
+   ret = sysfs_create_group(>dev.kobj, _attr_group);
+   if (ret) {
+   CLOCK_ERR(clock, "create clock attrs failed: %d", ret);
+   goto failed;
+   }
+
+   CLOCK_INFO(clock, "successfully initialized Clock subdev");
+
+   return 0;
+
+failed:
+   return ret;
+}
+
+static struct xrt_subdev_endpoints xrt_clock_endpoints[] = {
+   {
+   .xse_names = (struct xrt_subdev_ep_names[]) {
+   { .regmap_name = "clkwiz" },
+   { NULL },
+   },
+   .xse_min_ep = 1,
+   },
+   { 0 },
+};
+
+static struct xrt_subdev_drvdata xrt_clock_data = {
+   .xsd_dev_ops = {
+   .xsd_leaf_call = xrt_clock_leaf_call,
+   },
+};
+
+static const struct platform_device_id xrt_clock_table[] = {
+   { XRT_CLOCK, (kernel_ulong_t)_clock_data },
+   { },
+};
+
+static struct platform_driver xrt_clock_driver = {
+   .driver = {
+   .name = XRT_CLOCK,
+   },
+   .probe = clock_probe,
+   .remove = clock_remove,
+   .id_table = xrt_clock_table,
+};
+
+XRT_LEAF_INIT_FINI_FUNC(XRT_SUBDEV_CLOCK, clock);

Re: [PATCH V4 XRT Alveo 15/20] fpga: xrt: devctl platform driver

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:

Add devctl driver. devctl is a type of hardware function which only has
few registers to read or write. They are discovered by walking firmware
metadata. A platform device node will be created for them.

Signed-off-by: Sonal Santan 
Signed-off-by: Max Zhen 
Signed-off-by: Lizhi Hou 
---
  drivers/fpga/xrt/include/xleaf/devctl.h |  40 ++
  drivers/fpga/xrt/lib/xleaf/devctl.c | 183 
  2 files changed, 223 insertions(+)
  create mode 100644 drivers/fpga/xrt/include/xleaf/devctl.h
  create mode 100644 drivers/fpga/xrt/lib/xleaf/devctl.c

diff --git a/drivers/fpga/xrt/include/xleaf/devctl.h 
b/drivers/fpga/xrt/include/xleaf/devctl.h
new file mode 100644
index ..b97f3b6d9326
--- /dev/null
+++ b/drivers/fpga/xrt/include/xleaf/devctl.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou 
+ */
+
+#ifndef _XRT_DEVCTL_H_
+#define _XRT_DEVCTL_H_
+
+#include "xleaf.h"
+
+/*
+ * DEVCTL driver leaf calls.
+ */
+enum xrt_devctl_leaf_cmd {
+   XRT_DEVCTL_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
+};
+
+enum xrt_devctl_id {
+   XRT_DEVCTL_ROM_UUID = 0,

ok

+   XRT_DEVCTL_DDR_CALIB,
+   XRT_DEVCTL_GOLDEN_VER,
+   XRT_DEVCTL_MAX
+};
+
+struct xrt_devctl_rw {
+   u32 xdr_id;
+   void*xdr_buf;
+   u32 xdr_len;
+   u32 xdr_offset;
+};
+
+struct xrt_devctl_intf_uuid {
+   u32 uuid_num;
+   uuid_t  *uuids;
+};
+
+#endif /* _XRT_DEVCTL_H_ */
diff --git a/drivers/fpga/xrt/lib/xleaf/devctl.c 
b/drivers/fpga/xrt/lib/xleaf/devctl.c
new file mode 100644
index ..ae086d7c431d
--- /dev/null
+++ b/drivers/fpga/xrt/lib/xleaf/devctl.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA devctl Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ *  Lizhi Hou
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "metadata.h"
+#include "xleaf.h"
+#include "xleaf/devctl.h"
+
+#define XRT_DEVCTL "xrt_devctl"
+
+struct xrt_name_id {
+   char *ep_name;
+   int id;
+};
+
+static struct xrt_name_id name_id[XRT_DEVCTL_MAX] = {
+   { XRT_MD_NODE_BLP_ROM, XRT_DEVCTL_ROM_UUID },
+   { XRT_MD_NODE_GOLDEN_VER, XRT_DEVCTL_GOLDEN_VER },
+};
+
+static const struct regmap_config devctl_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,

ok

+};
+
+struct xrt_devctl {
+   struct platform_device  *pdev;
+   struct regmap   *regmap[XRT_DEVCTL_MAX];
+   ulong   sizes[XRT_DEVCTL_MAX];
+};
+
+static int xrt_devctl_name2id(struct xrt_devctl *devctl, const char *name)
+{
+   int i;
+
+   for (i = 0; i < XRT_DEVCTL_MAX && name_id[i].ep_name; i++) {
+   if (!strncmp(name_id[i].ep_name, name, 
strlen(name_id[i].ep_name) + 1))
+   return name_id[i].id;
+   }
+
+   return -EINVAL;
+}
+
+static int
+xrt_devctl_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+   struct xrt_devctl *devctl;
+   int ret = 0;
+
+   devctl = platform_get_drvdata(pdev);
+
+   switch (cmd) {
+   case XRT_XLEAF_EVENT:
+   /* Does not handle any event. */
+   break;
+   case XRT_DEVCTL_READ: {
+   struct xrt_devctl_rw *rw_arg = arg;
+
+   if (rw_arg->xdr_len & 0x3) {
+   xrt_err(pdev, "invalid len %d", rw_arg->xdr_len);
+   return -EINVAL;
+   }
+
+   if (rw_arg->xdr_id >= XRT_DEVCTL_MAX) {

ok

+   xrt_err(pdev, "invalid id %d", rw_arg->xdr_id);
+   return -EINVAL;
+   }
+
+   if (!devctl->regmap[rw_arg->xdr_id]) {
+   xrt_err(pdev, "io not found, id %d",
+   rw_arg->xdr_id);
+   return -EINVAL;
+   }
+
+   ret = regmap_bulk_read(devctl->regmap[rw_arg->xdr_id], 
rw_arg->xdr_offset,
+  rw_arg->xdr_buf,
+  rw_arg->xdr_len / 
devctl_regmap_config.reg_stride);
+   break;
+   }


ok, *_WRITE removed.

Thanks for the changes

Reviewed-by: Tom Rix 


+   default:
+   xrt_err(pdev, "unsupported cmd %d", cmd);
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+static int xrt_devctl_probe(struct platform_device *pdev)
+{
+   struct xrt_devctl *devctl = NULL;
+   void __iomem *base = NULL;
+   struct resource *res;
+   int i, id, ret = 0;
+
+   devctl = devm_kzalloc(>dev, sizeof(*devctl), GFP_KERNEL);
+   if (!devctl)
+   return 

Re: [PATCH V4 XRT Alveo 14/20] fpga: xrt: ICAP platform driver

[Tom Rix]

{
+   value = be32_to_cpu(word_buf[i]);
+   ret = regmap_write(icap->regmap, ICAP_REG_WF, value);
+   if (ret)
+   return ret;
+   }
+
+   ret = regmap_write(icap->regmap, ICAP_REG_CR, 0x1);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < 20; i++) {
+   ret = regmap_read(icap->regmap, ICAP_REG_CR, );
+   if (ret)
+   return ret;
+
+   if ((value & 0x1) == 0)
+   return 0;
+   ndelay(50);
+   }
+
+   ICAP_ERR(icap, "writing %d dwords timeout", size);
+   return -EIO;
+}
+
+static int bitstream_helper(struct icap *icap, const u32 *word_buffer,
+   u32 word_count)
+{
+   int wr_fifo_vacancy = 0;
+   u32 word_written = 0;
+   u32 remain_word;
+   int err = 0;
+
+   WARN_ON(!mutex_is_locked(>icap_lock));
+   for (remain_word = word_count; remain_word > 0;
+remain_word -= word_written, word_buffer += word_written) {
+   err = regmap_read(icap->regmap, ICAP_REG_WFV, _fifo_vacancy);
+   if (err) {
+   ICAP_ERR(icap, "read wr_fifo_vacancy failed %d", err);
+   break;
+   }
+   if (wr_fifo_vacancy <= 0) {
+   ICAP_ERR(icap, "no vacancy: %d", wr_fifo_vacancy);
+   err = -EIO;
+   break;
+   }
+   word_written = (wr_fifo_vacancy < remain_word) ?
+   wr_fifo_vacancy : remain_word;
+   if (icap_write(icap, word_buffer, word_written) != 0) {
+   ICAP_ERR(icap, "write failed remain %d, written %d",
+remain_word, word_written);
+   err = -EIO;
+   break;
+   }
+   }
+
+   return err;
+}
+
+static int icap_download(struct icap *icap, const char *buffer,
+unsigned long length)
+{
+   u32 num_chars_read = XCLBIN_HWICAP_BITFILE_BUF_SZ;
+   u32 byte_read;
+   int err = 0;
+
+   if (length % sizeof(u32)) {

ok

+   ICAP_ERR(icap, "invalid bitstream length %ld", length);
+   return -EINVAL;
+   }
+
+   mutex_lock(>icap_lock);
+   for (byte_read = 0; byte_read < length; byte_read += num_chars_read) {
+   num_chars_read = length - byte_read;
+   if (num_chars_read > XCLBIN_HWICAP_BITFILE_BUF_SZ)
+   num_chars_read = XCLBIN_HWICAP_BITFILE_BUF_SZ;
+
+   err = bitstream_helper(icap, (u32 *)buffer, num_chars_read / 
sizeof(u32));
+   if (err)
+   goto failed;
+   buffer += num_chars_read;
+   }
+
+   /* there is not any cleanup needs to be done if writing ICAP timeout. */
+   err = wait_for_done(icap);
+
+failed:
+   mutex_unlock(>icap_lock);
+
+   return err;
+}
+
+/*
+ * Discover the FPGA IDCODE using special sequence of canned commands
+ */
+static int icap_probe_chip(struct icap *icap)
+{
+   int err;
+   u32 val = 0;


ok, thanks for demagic-ing this function.

Looks good overall, only a few minor things.

Reviewed-by: Tom Rix 


+
+   regmap_read(icap->regmap, ICAP_REG_SR, );
+   if (val != ICAP_STATUS_DONE)
+   return -ENODEV;
+   /* Read ICAP FIFO vacancy */
+   regmap_read(icap->regmap, ICAP_REG_WFV, );
+   if (val < 8)
+   return -ENODEV;
+   err = icap_write(icap, idcode_stream, ARRAY_SIZE(idcode_stream));
+   if (err)
+   return err;
+   err = wait_for_done(icap);
+   if (err)
+   return err;
+
+   /* Tell config engine how many words to transfer to read FIFO */
+   regmap_write(icap->regmap, ICAP_REG_SZ, 0x1);
+   /* Switch the ICAP to read mode */
+   regmap_write(icap->regmap, ICAP_REG_CR, 0x2);
+   err = wait_for_done(icap);
+   if (err)
+   return err;
+
+   /* Read IDCODE from Read FIFO */
+   regmap_read(icap->regmap, ICAP_REG_RF, >idcode);
+   return 0;
+}
+
+static int
+xrt_icap_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+   struct xrt_icap_wr *wr_arg = arg;
+   struct icap *icap;
+   int ret = 0;
+
+   icap = platform_get_drvdata(pdev);
+
+   switch (cmd) {
+   case XRT_XLEAF_EVENT:
+   /* Does not handle any event. */
+   break;
+   case XRT_ICAP_WRITE:
+   ret = icap_download(icap, wr_arg->xiiw_bit_data,
+   wr_arg->xiiw_data_len);
+   break;
+   case XRT_ICAP_GET_IDCODE:
+   *(u32 *)arg = icap->idcode;
+   break;
+   default:
+   ICAP_ER

Re: [PATCH RFC 0/3] Adds support to allow the bitstream configuration from pre-allocated dma-buffer

[Tom Rix]

Please add to this patch cover letter what you want to discuss.

Got this new feature, not sure about ...

Tom

On 4/2/21 2:09 AM, Nava kishore Manne wrote:
> Nava kishore Manne (3):
>   fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'
>   fpga: support loading from a pre-allocated buffer
>   fpga: zynqmp: Use the scatterlist interface
>
>  .../devicetree/bindings/fpga/fpga-region.txt  |   2 +
>  drivers/fpga/fpga-mgr.c   | 126 +-
>  drivers/fpga/of-fpga-region.c |   3 +
>  drivers/fpga/zynqmp-fpga.c|  35 +
>  include/linux/fpga/fpga-mgr.h |   6 +-
>  5 files changed, 169 insertions(+), 3 deletions(-)
>

Re: [PATCH V4 XRT Alveo 13/20] fpga: xrt: User Clock Subsystem platform driver

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Add User Clock Subsystem (UCS) driver. UCS is a hardware function
ok
> discovered by walking xclbin metadata. A platform device node will be
> created for it.  UCS enables/disables the dynamic region clocks.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/xleaf/ucs.c | 167 +++
ok on removing ucs.h
>  1 file changed, 167 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/ucs.c
>
> diff --git a/drivers/fpga/xrt/lib/xleaf/ucs.c 
> b/drivers/fpga/xrt/lib/xleaf/ucs.c
> new file mode 100644
> index ..d91ee229e7cb
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/ucs.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA UCS Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/clock.h"
> +
> +#define UCS_ERR(ucs, fmt, arg...)   \
> + xrt_err((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_WARN(ucs, fmt, arg...)  \
> + xrt_warn((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_INFO(ucs, fmt, arg...)  \
> + xrt_info((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_DBG(ucs, fmt, arg...)   \
> + xrt_dbg((ucs)->pdev, fmt "\n", ##arg)
> +
> +#define XRT_UCS  "xrt_ucs"
> +
> +#define XRT_UCS_CHANNEL1_REG 0
> +#define XRT_UCS_CHANNEL2_REG 8
> +
> +#define CLK_MAX_VALUE6400
> +
> +static const struct regmap_config ucs_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x1000,
> +};
> +
> +struct xrt_ucs {
> + struct platform_device  *pdev;
> + struct regmap   *regmap;
ok
> + struct mutexucs_lock; /* ucs dev lock */
> +};
> +
> +static void xrt_ucs_event_cb(struct platform_device *pdev, void *arg)
> +{
> + struct xrt_event *evt = (struct xrt_event *)arg;
> + enum xrt_events e = evt->xe_evt;
> + struct platform_device *leaf;
> + enum xrt_subdev_id id;
> + int instance;
> +
> + id = evt->xe_subdev.xevt_subdev_id;
> + instance = evt->xe_subdev.xevt_subdev_instance;
> +
> + if (e != XRT_EVENT_POST_CREATION) {
> + xrt_dbg(pdev, "ignored event %d", e);
> + return;
> + }
> +
> + if (id != XRT_SUBDEV_CLOCK)
> + return;
ok
> +
> + leaf = xleaf_get_leaf_by_id(pdev, XRT_SUBDEV_CLOCK, instance);
> + if (!leaf) {
> + xrt_err(pdev, "does not get clock subdev");
> + return;
> + }
> +
> + xleaf_call(leaf, XRT_CLOCK_VERIFY, NULL);
> + xleaf_put_leaf(pdev, leaf);
> +}
ok on removing ucs_check.
> +
> +static int ucs_enable(struct xrt_ucs *ucs)
> +{
> + int ret;
> +
> + mutex_lock(>ucs_lock);
ok
> + ret = regmap_write(ucs->regmap, XRT_UCS_CHANNEL2_REG, 1);
> + mutex_unlock(>ucs_lock);
> +
> + return ret;
> +}
> +
> +static int
> +xrt_ucs_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)

ok

Looks fine.

Reviewed-by: Tom Rix 

> +{
> + switch (cmd) {
> + case XRT_XLEAF_EVENT:
> + xrt_ucs_event_cb(pdev, arg);
> + break;
> + default:
> + xrt_err(pdev, "unsupported cmd %d", cmd);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int ucs_probe(struct platform_device *pdev)
> +{
> + struct xrt_ucs *ucs = NULL;
> + void __iomem *base = NULL;
> + struct resource *res;
> +
> + ucs = devm_kzalloc(>dev, sizeof(*ucs), GFP_KERNEL);
> + if (!ucs)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, ucs);
> + ucs->pdev = pdev;
> + mutex_init(>ucs_lock);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + ucs->regmap = devm_regmap_init_mmio(>dev, base, 
> _regmap_config);
> + if (IS_ERR(ucs->regmap)) {
> + UCS_ERR(ucs, "map base %pR failed", res);
> + return PTR_ERR(ucs->regmap);
> + }
>

Re: [PATCH V4 XRT Alveo 12/20] fpga: xrt: VSEC platform driver

[Tom Rix]

local use of 'regmap' conflicts with global meaning.

reword local regmap to something else.

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Add VSEC driver. VSEC is a hardware function discovered by walking
> PCI Express configure space. A platform device node will be created
> for it. VSEC provides board logic UUID and few offset of other hardware
> functions.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/xleaf/vsec.c | 388 ++
>  1 file changed, 388 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/vsec.c
>
> diff --git a/drivers/fpga/xrt/lib/xleaf/vsec.c 
> b/drivers/fpga/xrt/lib/xleaf/vsec.c
> new file mode 100644
> index ..8595d23f5710
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/vsec.c
> @@ -0,0 +1,388 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA VSEC Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +
> +#define XRT_VSEC "xrt_vsec"
> +
> +#define VSEC_TYPE_UUID   0x50
> +#define VSEC_TYPE_FLASH  0x51
> +#define VSEC_TYPE_PLATINFO   0x52
> +#define VSEC_TYPE_MAILBOX0x53
> +#define VSEC_TYPE_END0xff
> +
> +#define VSEC_UUID_LEN16
> +
> +#define VSEC_REG_FORMAT  0x0
> +#define VSEC_REG_LENGTH  0x4
> +#define VSEC_REG_ENTRY   0x8
> +
> +struct xrt_vsec_header {
> + u32 format;
> + u32 length;
> + u32 entry_sz;
> + u32 rsvd;
> +} __packed;
> +
> +struct xrt_vsec_entry {
> + u8  type;
> + u8  bar_rev;
> + u16 off_lo;
> + u32 off_hi;
> + u8  ver_type;
> + u8  minor;
> + u8  major;
> + u8  rsvd0;
> + u32 rsvd1;
> +} __packed;
> +
> +struct vsec_device {
> + u8  type;
> + char*ep_name;
> + ulong   size;
> + char*regmap;

This element should be 'char *name;' as regmap is a different thing.

> +};
> +
> +static struct vsec_device vsec_devs[] = {
> + {
> + .type = VSEC_TYPE_UUID,
> + .ep_name = XRT_MD_NODE_BLP_ROM,
> + .size = VSEC_UUID_LEN,
> + .regmap = "vsec-uuid",
> + },
> + {
> + .type = VSEC_TYPE_FLASH,
> + .ep_name = XRT_MD_NODE_FLASH_VSEC,
> + .size = 4096,
> + .regmap = "vsec-flash",
> + },
> + {
> + .type = VSEC_TYPE_PLATINFO,
> + .ep_name = XRT_MD_NODE_PLAT_INFO,
> + .size = 4,
> + .regmap = "vsec-platinfo",
> + },
> + {
> + .type = VSEC_TYPE_MAILBOX,
> + .ep_name = XRT_MD_NODE_MAILBOX_VSEC,
> + .size = 48,
> + .regmap = "vsec-mbx",
> + },
> +};
> +
> +static const struct regmap_config vsec_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x1000,
At least 0x1000 could be #define, maybe all.
> +};
> +
> +struct xrt_vsec {
> + struct platform_device  *pdev;
> + struct regmap   *regmap;
> + u32 length;
> +
> + char*metadata;
> + charuuid[VSEC_UUID_LEN];
> + int group;
> +};
> +
> +static inline int vsec_read_entry(struct xrt_vsec *vsec, u32 index, struct 
> xrt_vsec_entry *entry)
> +{
> + int ret;
> +
> + ret = regmap_bulk_read(vsec->regmap, sizeof(struct xrt_vsec_header) +
> +index * sizeof(struct xrt_vsec_entry), entry,
> +sizeof(struct xrt_vsec_entry) /
> +vsec_regmap_config.reg_stride);
> +
> + return ret;
> +}
> +
> +static inline u32 vsec_get_bar(struct xrt_vsec_entry *entry)
> +{
> + return ((entry)->bar_rev >> 4) & 0xf;

The extra () were needed when this was a macro, they aren't now.

remove here and the next 2 functions.

> +}
> +
> +static inline u64 vsec_get_bar_off(struct xrt_vsec_entry *entry)
> +{
> + return (entry)->off_lo | ((u64)(entry)->off_hi << 16);
> +}
> +
> +static inline u32 vsec_get_rev(struct xrt_vsec_entry *entry)
> +{
> + return (entry)->bar_rev & 0xf;
> +}
> +
> +static char *type2epname(u32 type)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vsec_devs); i++) {
> + if (vsec_devs[i].type == type)
> + return (vsec_devs[i].ep_name);
> + }
> +
> + return NULL;
> +}
> +
> +static ulong type2size(u32 type)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vsec_devs); i++) {
> + if (vsec_devs[i].type == type)
> + return (vsec_devs[i].size);
> + }

Re: [PATCH V4 XRT Alveo 10/20] fpga: xrt: main platform driver for management function device

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> platform driver that handles IOCTLs, such as hot reset and xclbin download.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xmgmt-main.h |  34 ++
>  drivers/fpga/xrt/mgmt/main.c  | 670 ++
>  drivers/fpga/xrt/mgmt/xmgnt.h |  34 ++
>  include/uapi/linux/xrt/xmgmt-ioctl.h  |  46 ++
>  4 files changed, 784 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xmgmt-main.h
>  create mode 100644 drivers/fpga/xrt/mgmt/main.c
'main' is generic, how about xmgnt-main ?
>  create mode 100644 drivers/fpga/xrt/mgmt/xmgnt.h
>  create mode 100644 include/uapi/linux/xrt/xmgmt-ioctl.h
>
> diff --git a/drivers/fpga/xrt/include/xmgmt-main.h 
> b/drivers/fpga/xrt/include/xmgmt-main.h
> new file mode 100644
> index ..dce9f0d1a0dc
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xmgmt-main.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XMGMT_MAIN_H_
> +#define _XMGMT_MAIN_H_
> +
> +#include 
> +#include "xleaf.h"
> +
> +enum xrt_mgmt_main_leaf_cmd {
> + XRT_MGMT_MAIN_GET_AXLF_SECTION = XRT_XLEAF_CUSTOM_BASE, /* See comments 
> in xleaf.h */
> + XRT_MGMT_MAIN_GET_VBNV,
> +};
> +
> +/* There are three kind of partitions. Each of them is programmed 
> independently. */
> +enum provider_kind {
> + XMGMT_BLP, /* Base Logic Partition */
> + XMGMT_PLP, /* Provider Logic Partition */
> + XMGMT_ULP, /* User Logic Partition */
ok
> +};
> +
> +struct xrt_mgmt_main_get_axlf_section {
> + enum provider_kind xmmigas_axlf_kind;
> + enum axlf_section_kind xmmigas_section_kind;
> + void *xmmigas_section;
> + u64 xmmigas_section_size;
> +};
> +
> +#endif   /* _XMGMT_MAIN_H_ */
> diff --git a/drivers/fpga/xrt/mgmt/main.c b/drivers/fpga/xrt/mgmt/main.c
> new file mode 100644
> index ..f3b46e1fd78b
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/main.c
> @@ -0,0 +1,670 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA MGMT PF entry point driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Sonal Santan 
> + */
> +
> +#include 
> +#include 
> +#include "xclbin-helper.h"
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include 
> +#include "xleaf/devctl.h"
> +#include "xmgmt-main.h"
> +#include "fmgr.h"
> +#include "xleaf/icap.h"
> +#include "xleaf/axigate.h"
> +#include "xmgnt.h"
> +
> +#define XMGMT_MAIN "xmgmt_main"
> +#define XMGMT_SUPP_XCLBIN_MAJOR 2
> +
> +#define XMGMT_FLAG_FLASH_READY   1
> +#define XMGMT_FLAG_DEVCTL_READY  2
> +
> +#define XMGMT_UUID_STR_LEN   80
> +
> +struct xmgmt_main {
> + struct platform_device *pdev;
> + struct axlf *firmware_blp;
> + struct axlf *firmware_plp;
> + struct axlf *firmware_ulp;
> + u32 flags;
ok
> + struct fpga_manager *fmgr;
> + struct mutex lock; /* busy lock */
ok
> +
do not need this nl
> + uuid_t *blp_interface_uuids;
> + u32 blp_interface_uuid_num;
ok
> +};
> +
> +/*
> + * VBNV stands for Vendor, BoardID, Name, Version. It is a string
> + * which describes board and shell.
> + *
> + * Caller is responsible for freeing the returned string.
ok
> + */
> +char *xmgmt_get_vbnv(struct platform_device *pdev)
> +{
> + struct xmgmt_main *xmm = platform_get_drvdata(pdev);
> + const char *vbnv;
> + char *ret;
> + int i;
> +
> + if (xmm->firmware_plp)
> + vbnv = xmm->firmware_plp->header.platform_vbnv;
> + else if (xmm->firmware_blp)
> + vbnv = xmm->firmware_blp->header.platform_vbnv;
> + else
> + return NULL;
> +
> + ret = kstrdup(vbnv, GFP_KERNEL);
> + if (!ret)
> + return NULL;
> +
> + for (i = 0; i < strlen(ret); i++) {
> + if (ret[i] == ':' || ret[i] == '.')
> + ret[i] = '_';
> + }
> + return ret;
> +}
> +
> +static int get_dev_uuid(struct platform_device *pdev, char *uuidstr, size_t 
> len)
> +{
> + struct xrt_devctl_rw devctl_arg = { 0 };
> + struct platform_device *devctl_leaf;
> + char uuid_buf[UUID_SIZE];
> + uuid_t uuid;
> + int err;
> +
> + devctl_leaf = xleaf_get_leaf_by_epname(pdev, XRT_MD_NODE_BLP_ROM);
> + if (!devctl_leaf) {
> + xrt_err(pdev, "can not get %s", XRT_MD_NODE_BLP_ROM);
> + return -EINVAL;
> + }
> +
> + devctl_arg.xdr_id = XRT_DEVCTL_ROM_UUID;
> + devctl_arg.xdr_buf = uuid_buf;
> + devctl_arg.xdr_len = sizeof(uuid_buf);
> + devctl_arg.xdr_offset = 0;
> + err = xleaf_call(devctl_leaf, XRT_DEVCTL_READ, _arg);
> + xleaf_put_leaf(pdev, devctl_leaf);
> + if (err) {
> + xrt_err(pdev, "can not get uuid: %d", err);
> + return err;
> + }
> + import_uuid(, uuid_buf);
ok
> + xrt_md_trans_uuid2str(, 

Re: [PATCH V4 XRT Alveo 11/20] fpga: xrt: fpga-mgr and region implementation for xclbin download

[Tom Rix]

small alloc's should use kzalloc.

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> fpga-mgr and region implementation for xclbin download which will be
> called from main platform driver
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/mgmt/fmgr-drv.c| 191 +++
>  drivers/fpga/xrt/mgmt/fmgr.h|  19 ++
>  drivers/fpga/xrt/mgmt/main-region.c | 483 
>  3 files changed, 693 insertions(+)
>  create mode 100644 drivers/fpga/xrt/mgmt/fmgr-drv.c
>  create mode 100644 drivers/fpga/xrt/mgmt/fmgr.h
a better file name would be xrt-mgr.*
>  create mode 100644 drivers/fpga/xrt/mgmt/main-region.c
>
> diff --git a/drivers/fpga/xrt/mgmt/fmgr-drv.c 
> b/drivers/fpga/xrt/mgmt/fmgr-drv.c
> new file mode 100644
> index ..12e1cc788ad9
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/fmgr-drv.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * FPGA Manager Support for Xilinx Alveo Management Function Driver

Since there is only one fpga mgr for xrt, this could be shortened to

* FPGA Manager Support for Xilinx Alevo

> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors: sonal.san...@xilinx.com
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xclbin-helper.h"
> +#include "xleaf.h"
> +#include "fmgr.h"
> +#include "xleaf/axigate.h"
> +#include "xleaf/icap.h"
> +#include "xmgnt.h"
> +
> +struct xfpga_class {
> + const struct platform_device *pdev;
> + char  name[64];
> +};
> +
> +/*
> + * xclbin download plumbing -- find the download subsystem, ICAP and
> + * pass the xclbin for heavy lifting
> + */
> +static int xmgmt_download_bitstream(struct platform_device *pdev,
> + const struct axlf *xclbin)
> +
> +{
> + struct xclbin_bit_head_info bit_header = { 0 };
> + struct platform_device *icap_leaf = NULL;
> + struct xrt_icap_wr arg;
> + char *bitstream = NULL;
> + u64 bit_len;
> + int ret;
> +
> + ret = xrt_xclbin_get_section(DEV(pdev), xclbin, BITSTREAM, (void 
> **), _len);
> + if (ret) {
> + xrt_err(pdev, "bitstream not found");
> + return -ENOENT;
> + }
> + ret = xrt_xclbin_parse_bitstream_header(DEV(pdev), bitstream,
> + XCLBIN_HWICAP_BITFILE_BUF_SZ,
> + _header);
> + if (ret) {
> + ret = -EINVAL;
> + xrt_err(pdev, "invalid bitstream header");
> + goto fail;
> + }
> + if (bit_header.header_length + bit_header.bitstream_length > bit_len) {
> + ret = -EINVAL;
> + xrt_err(pdev, "invalid bitstream length. header %d, bitstream 
> %d, section len %lld",
> + bit_header.header_length, bit_header.bitstream_length, 
> bit_len);
> + goto fail;
> + }
> +
> + icap_leaf = xleaf_get_leaf_by_id(pdev, XRT_SUBDEV_ICAP, 
> PLATFORM_DEVID_NONE);
> + if (!icap_leaf) {
> + ret = -ENODEV;
> + xrt_err(pdev, "icap does not exist");
> + goto fail;
> + }
> + arg.xiiw_bit_data = bitstream + bit_header.header_length;
> + arg.xiiw_data_len = bit_header.bitstream_length;
> + ret = xleaf_call(icap_leaf, XRT_ICAP_WRITE, );
> + if (ret) {
> + xrt_err(pdev, "write bitstream failed, ret = %d", ret);
> + xleaf_put_leaf(pdev, icap_leaf);
> + goto fail;
> + }
ok, free_header removed
> +
> + xleaf_put_leaf(pdev, icap_leaf);
> + vfree(bitstream);
> +
> + return 0;
> +
> +fail:
> + vfree(bitstream);
> +
> + return ret;
> +}
> +
> +/*
> + * There is no HW prep work we do here since we need the full
> + * xclbin for its sanity check.
> + */
> +static int xmgmt_pr_write_init(struct fpga_manager *mgr,
> +struct fpga_image_info *info,
> +const char *buf, size_t count)
> +{
> + const struct axlf *bin = (const struct axlf *)buf;
> + struct xfpga_class *obj = mgr->priv;
> +
> + if (!(info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + xrt_info(obj->pdev, "%s only supports partial 
> reconfiguration\n", obj->name);
> + return -EINVAL;
> + }
> +
> + if (count < sizeof(struct axlf))
> + return -EINVAL;
> +
> + if (count > bin->header.length)
> + return -EINVAL;
> +
> + xrt_info(obj->pdev, "Prepare download of xclbin %pUb of length %lld B",
> +  >header.uuid, bin->header.length);
> +
> + return 0;
> +}
> +
> +/*
> + * The implementation requries full xclbin image before we can start
> + * programming the hardware via ICAP subsystem. The full image is required
ok
> + * for checking the validity of xclbin and walking the sections to
> + * discover the bitstream.
> + */
> +static int 

Re: [PATCH V4 XRT Alveo 09/20] fpga: xrt: management physical function driver (root)

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> The PCIE device driver which attaches to management function on Alveo
> devices. It instantiates one or more group drivers which, in turn,
> instantiate platform drivers. The instantiation of group and platform
> drivers is completely dtb driven.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/mgmt/root.c | 333 +++
>  1 file changed, 333 insertions(+)
>  create mode 100644 drivers/fpga/xrt/mgmt/root.c
>
> diff --git a/drivers/fpga/xrt/mgmt/root.c b/drivers/fpga/xrt/mgmt/root.c
> new file mode 100644
> index ..f97f92807c01
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/root.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo Management Function Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xroot.h"
> +#include "xmgnt.h"
> +#include "metadata.h"
> +
> +#define XMGMT_MODULE_NAME"xrt-mgmt"
ok
> +#define XMGMT_DRIVER_VERSION "4.0.0"
> +
> +#define XMGMT_PDEV(xm)   ((xm)->pdev)
> +#define XMGMT_DEV(xm)(&(XMGMT_PDEV(xm)->dev))
> +#define xmgmt_err(xm, fmt, args...)  \
> + dev_err(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
> +#define xmgmt_warn(xm, fmt, args...) \
> + dev_warn(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
> +#define xmgmt_info(xm, fmt, args...) \
> + dev_info(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
> +#define xmgmt_dbg(xm, fmt, args...)  \
> + dev_dbg(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
> +#define XMGMT_DEV_ID(_pcidev)\
> + ({ typeof(_pcidev) (pcidev) = (_pcidev);\
> + ((pci_domain_nr((pcidev)->bus) << 16) | \
> + PCI_DEVID((pcidev)->bus->number, 0)); })
> +
> +static struct class *xmgmt_class;
> +
> +/* PCI Device IDs */

add a comment on what a golden image is here something like

/*

* Golden image is preloaded on the device when it is shipped to customer.

* Then, customer can load other shells (from Xilinx or some other vendor).

* If something goes wrong with the shell, customer can always go back to

* golden and start over again.

*/


> +#define PCI_DEVICE_ID_U50_GOLDEN 0xD020
> +#define PCI_DEVICE_ID_U500x5020
> +static const struct pci_device_id xmgmt_pci_ids[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50_GOLDEN), }, /* 
> Alveo U50 (golden) */
> + { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50), }, /* Alveo U50 
> */
> + { 0, }
> +};
> +
> +struct xmgmt {
> + struct pci_dev *pdev;
> + void *root;
> +
> + bool ready;
> +};
> +
> +static int xmgmt_config_pci(struct xmgmt *xm)
> +{
> + struct pci_dev *pdev = XMGMT_PDEV(xm);
> + int rc;
> +
> + rc = pcim_enable_device(pdev);
> + if (rc < 0) {
> + xmgmt_err(xm, "failed to enable device: %d", rc);
> + return rc;
> + }
> +
> + rc = pci_enable_pcie_error_reporting(pdev);
> + if (rc)
ok
> + xmgmt_warn(xm, "failed to enable AER: %d", rc);
> +
> + pci_set_master(pdev);
> +
> + rc = pcie_get_readrq(pdev);
> + if (rc > 512)
512 is magic number, change this to a #define
> + pcie_set_readrq(pdev, 512);
> + return 0;
> +}
> +
> +static int xmgmt_match_slot_and_save(struct device *dev, void *data)
> +{
> + struct xmgmt *xm = data;
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (XMGMT_DEV_ID(pdev) == XMGMT_DEV_ID(xm->pdev)) {
> + pci_cfg_access_lock(pdev);
> + pci_save_state(pdev);
> + }
> +
> + return 0;
> +}
> +
> +static void xmgmt_pci_save_config_all(struct xmgmt *xm)
> +{
> + bus_for_each_dev(_bus_type, NULL, xm, xmgmt_match_slot_and_save);
refactor expected in v5 when pseudo bus change happens.
> +}
> +
> +static int xmgmt_match_slot_and_restore(struct device *dev, void *data)
> +{
> + struct xmgmt *xm = data;
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (XMGMT_DEV_ID(pdev) == XMGMT_DEV_ID(xm->pdev)) {
> + pci_restore_state(pdev);
> + pci_cfg_access_unlock(pdev);
> + }
> +
> + return 0;
> +}
> +
> +static void xmgmt_pci_restore_config_all(struct xmgmt *xm)
> +{
> + bus_for_each_dev(_bus_type, NULL, xm, xmgmt_match_slot_and_restore);
> +}
> +
> +static void xmgmt_root_hot_reset(struct pci_dev *pdev)
> +{
> + struct xmgmt *xm = pci_get_drvdata(pdev);
> + struct pci_bus *bus;
> + u8 pci_bctl;
> + u16 pci_cmd, devctl;
> + int i, ret;
> +
> + xmgmt_info(xm, "hot reset start");
> +
> + xmgmt_pci_save_config_all(xm);
> +
> + pci_disable_device(pdev);
> +
> + bus = pdev->bus;
whitespace, all these nl's are not needed
> +
> + /*
> +  * When flipping the SBR bit, device can fall off the bus. This is
> +  * usually no 

Re: [PATCH V4 XRT Alveo 08/20] fpga: xrt: platform driver infrastructure

[Tom Rix]

Several just for debugging items, consider adding a CONFIG_XRT_DEBUGGING

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Infrastructure code providing APIs for managing leaf driver instance
> groups, facilitating inter-leaf driver calls and root calls.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/subdev.c | 865 ++
>  1 file changed, 865 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/subdev.c
>
> diff --git a/drivers/fpga/xrt/lib/subdev.c b/drivers/fpga/xrt/lib/subdev.c
> new file mode 100644
> index ..6428b183fee3
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/subdev.c
> @@ -0,0 +1,865 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "xleaf.h"
> +#include "subdev_pool.h"
> +#include "lib-drv.h"
> +#include "metadata.h"
> +
> +#define IS_ROOT_DEV(dev) ((dev)->bus == _bus_type)
for readablity, add a new line here
> +static inline struct device *find_root(struct platform_device *pdev)
> +{
> + struct device *d = DEV(pdev);
> +
> + while (!IS_ROOT_DEV(d))
> + d = d->parent;
> + return d;
> +}
> +
> +/*
> + * It represents a holder of a subdev. One holder can repeatedly hold a 
> subdev
> + * as long as there is a unhold corresponding to a hold.
> + */
> +struct xrt_subdev_holder {
> + struct list_head xsh_holder_list;
> + struct device *xsh_holder;
> + int xsh_count;
> + struct kref xsh_kref;
> +};
> +
> +/*
> + * It represents a specific instance of platform driver for a subdev, which
> + * provides services to its clients (another subdev driver or root driver).
> + */
> +struct xrt_subdev {
> + struct list_head xs_dev_list;
> + struct list_head xs_holder_list;
> + enum xrt_subdev_id xs_id;   /* type of subdev */
> + struct platform_device *xs_pdev;/* a particular subdev inst */
> + struct completion xs_holder_comp;
> +};
> +
> +static struct xrt_subdev *xrt_subdev_alloc(void)
> +{
> + struct xrt_subdev *sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
ok
> +
> + if (!sdev)
> + return NULL;
> +
> + INIT_LIST_HEAD(>xs_dev_list);
> + INIT_LIST_HEAD(>xs_holder_list);
> + init_completion(>xs_holder_comp);
> + return sdev;
> +}
> +
> +static void xrt_subdev_free(struct xrt_subdev *sdev)
> +{
> + kfree(sdev);
Abstraction for a single function is not needed, use kfree directly.
> +}
> +
> +int xrt_subdev_root_request(struct platform_device *self, u32 cmd, void *arg)
> +{
> + struct device *dev = DEV(self);
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(self);
> +
> + WARN_ON(!pdata->xsp_root_cb);
ok
> + return (*pdata->xsp_root_cb)(dev->parent, pdata->xsp_root_cb_arg, cmd, 
> arg);
> +}
> +
> +/*
> + * Subdev common sysfs nodes.
> + */
> +static ssize_t holders_show(struct device *dev, struct device_attribute 
> *attr, char *buf)
> +{
> + ssize_t len;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct xrt_root_get_holders holders = { pdev, buf, 1024 };
Since 1024 is config, #define it somewhere so it can be tweeked later
> +
> + len = xrt_subdev_root_request(pdev, XRT_ROOT_GET_LEAF_HOLDERS, 
> );
> + if (len >= holders.xpigh_holder_buf_len)
> + return len;
> + buf[len] = '\n';
> + return len + 1;
> +}
> +static DEVICE_ATTR_RO(holders);
> +
> +static struct attribute *xrt_subdev_attrs[] = {
> + _attr_holders.attr,
> + NULL,
> +};
> +
> +static ssize_t metadata_output(struct file *filp, struct kobject *kobj,
> +struct bin_attribute *attr, char *buf, loff_t 
> off, size_t count)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct platform_device *pdev = to_platform_device(dev);
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(pdev);
> + unsigned char *blob;
> + unsigned long  size;
> + ssize_t ret = 0;
> +
> + blob = pdata->xsp_dtb;
> + size = xrt_md_size(dev, blob);
> + if (size == XRT_MD_INVALID_LENGTH) {
> + ret = -EINVAL;
> + goto failed;
> + }
> +
> + if (off >= size)
> + goto failed;
if this and next are used for debugging, add a 'dev_dbg()' to help out the 
debugging.
> +
> + if (off + count > size)
> + count = size - off;
> + memcpy(buf, blob + off, count);
> +
> + ret = count;
> +failed:
> + return ret;
> +}
> +
> +static struct bin_attribute meta_data_attr = {
> + .attr = {
> + .name = "metadata",
> + .mode = 0400
> + },

Permissions will not be enough, anyone can be root.

A developer only interface should be hidden behind a CONFIG_

> + .read = metadata_output,
> + .size = 0
> +};
> +
> +static struct bin_attribute  *xrt_subdev_bin_attrs[] = {
> + _data_attr,
> +

Re: [PATCH V4 XRT Alveo 07/20] fpga: xrt: root driver infrastructure

[Tom Rix]

This was split from 'fpga: xrt: platform driver infrastructure'

and fpga: xrt: managment physical function driver (root)


On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Contains common code for all root drivers and handles root calls from
> platform drivers. This is part of root driver infrastructure.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/events.h  |  45 +++
>  drivers/fpga/xrt/include/xroot.h   | 117 ++
>  drivers/fpga/xrt/lib/subdev_pool.h |  53 +++
>  drivers/fpga/xrt/lib/xroot.c   | 589 +
>  4 files changed, 804 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/events.h
>  create mode 100644 drivers/fpga/xrt/include/xroot.h
>  create mode 100644 drivers/fpga/xrt/lib/subdev_pool.h
>  create mode 100644 drivers/fpga/xrt/lib/xroot.c
>
> diff --git a/drivers/fpga/xrt/include/events.h 
> b/drivers/fpga/xrt/include/events.h
> new file mode 100644
> index ..775171a47c8e
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/events.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
ok
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_EVENTS_H_
> +#define _XRT_EVENTS_H_
ok
> +
> +#include "subdev_id.h"
> +
> +/*
> + * Event notification.
> + */
> +enum xrt_events {
> + XRT_EVENT_TEST = 0, /* for testing */
> + /*
> +  * Events related to specific subdev
> +  * Callback arg: struct xrt_event_arg_subdev
> +  */
> + XRT_EVENT_POST_CREATION,
> + XRT_EVENT_PRE_REMOVAL,
> + /*
> +  * Events related to change of the whole board
> +  * Callback arg: 
> +  */
> + XRT_EVENT_PRE_HOT_RESET,
> + XRT_EVENT_POST_HOT_RESET,
> + XRT_EVENT_PRE_GATE_CLOSE,
> + XRT_EVENT_POST_GATE_OPEN,
> +};
> +
> +struct xrt_event_arg_subdev {
> + enum xrt_subdev_id xevt_subdev_id;
> + int xevt_subdev_instance;
> +};
> +
> +struct xrt_event {
> + enum xrt_events xe_evt;
> + struct xrt_event_arg_subdev xe_subdev;
> +};
> +
> +#endif   /* _XRT_EVENTS_H_ */
> diff --git a/drivers/fpga/xrt/include/xroot.h 
> b/drivers/fpga/xrt/include/xroot.h
> new file mode 100644
> index ..91c0aeb30bf8
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xroot.h
> @@ -0,0 +1,117 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_ROOT_H_
> +#define _XRT_ROOT_H_
> +
> +#include 
> +#include 
> +#include "subdev_id.h"
> +#include "events.h"
> +
> +typedef bool (*xrt_subdev_match_t)(enum xrt_subdev_id,
> + struct platform_device *, void *);
> +#define XRT_SUBDEV_MATCH_PREV((xrt_subdev_match_t)-1)
> +#define XRT_SUBDEV_MATCH_NEXT((xrt_subdev_match_t)-2)
> +
> +/*
> + * Root calls.
> + */
> +enum xrt_root_cmd {
> + /* Leaf actions. */
> + XRT_ROOT_GET_LEAF = 0,
> + XRT_ROOT_PUT_LEAF,
> + XRT_ROOT_GET_LEAF_HOLDERS,
> +
> + /* Group actions. */
> + XRT_ROOT_CREATE_GROUP,
> + XRT_ROOT_REMOVE_GROUP,
> + XRT_ROOT_LOOKUP_GROUP,
> + XRT_ROOT_WAIT_GROUP_BRINGUP,
> +
> + /* Event actions. */
> + XRT_ROOT_EVENT_SYNC,
> + XRT_ROOT_EVENT_ASYNC,
> +
> + /* Device info. */
> + XRT_ROOT_GET_RESOURCE,
> + XRT_ROOT_GET_ID,
> +
> + /* Misc. */
> + XRT_ROOT_HOT_RESET,
> + XRT_ROOT_HWMON,
> +};
> +
> +struct xrt_root_get_leaf {
> + struct platform_device *xpigl_caller_pdev;
> + xrt_subdev_match_t xpigl_match_cb;
> + void *xpigl_match_arg;
> + struct platform_device *xpigl_tgt_pdev;
> +};
> +
> +struct xrt_root_put_leaf {
> + struct platform_device *xpipl_caller_pdev;
> + struct platform_device *xpipl_tgt_pdev;
> +};
> +
> +struct xrt_root_lookup_group {
> + struct platform_device *xpilp_pdev; /* caller's pdev */
> + xrt_subdev_match_t xpilp_match_cb;
> + void *xpilp_match_arg;
> + int xpilp_grp_inst;
> +};
> +
> +struct xrt_root_get_holders {
> + struct platform_device *xpigh_pdev; /* caller's pdev */
> + char *xpigh_holder_buf;
> + size_t xpigh_holder_buf_len;
> +};
> +
> +struct xrt_root_get_res {
> + struct resource *xpigr_res;
> +};
> +
> +struct xrt_root_get_id {
> + unsigned short  xpigi_vendor_id;
> + unsigned short  xpigi_device_id;
> + unsigned short  xpigi_sub_vendor_id;
> + unsigned short  xpigi_sub_device_id;
> +};
> +
> +struct xrt_root_hwmon {
> + bool xpih_register;
> + const char *xpih_name;
> + void *xpih_drvdata;
> + const struct attribute_group **xpih_groups;
> + struct device *xpih_hwmon_dev;
> +};
> +
> +/*
> + * Callback for leaf to make a root request. Arguments are: parent device, 
> parent cookie, req,
> + * and arg.
> + */
> +typedef int (*xrt_subdev_root_cb_t)(struct device *, void *, u32, void *);
> +int xrt_subdev_root_request(struct platform_device *self, u32 cmd, void 
> 

Re: [PATCH V4 XRT Alveo 06/20] fpga: xrt: char dev node helper functions

[Tom Rix]

It is unclear from the changelog if this new patch was split from an existing 
patch or new content.

the file ops seem to come from mgmnt/main.c, which call what could be file ops 
here.  why is this complicated redirection needed ?

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Helper functions for char device node creation / removal for platform
> drivers. This is part of platform driver infrastructure.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/cdev.c | 232 
>  1 file changed, 232 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/cdev.c
>
> diff --git a/drivers/fpga/xrt/lib/cdev.c b/drivers/fpga/xrt/lib/cdev.c
> new file mode 100644
> index ..38efd24b6e10
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/cdev.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA device node helper functions.
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include "xleaf.h"
> +
> +extern struct class *xrt_class;
> +
> +#define XRT_CDEV_DIR "xfpga"
maybe "xrt_fpga" or just "xrt"
> +#define INODE2PDATA(inode)   \
> + container_of((inode)->i_cdev, struct xrt_subdev_platdata, xsp_cdev)
> +#define INODE2PDEV(inode)\
> + to_platform_device(kobj_to_dev((inode)->i_cdev->kobj.parent))
> +#define CDEV_NAME(sysdev)(strchr((sysdev)->kobj.name, '!') + 1)
> +
> +/* Allow it to be accessed from cdev. */
> +static void xleaf_devnode_allowed(struct platform_device *pdev)
> +{
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(pdev);
> +
> + /* Allow new opens. */
> + mutex_lock(>xsp_devnode_lock);
> + pdata->xsp_devnode_online = true;
> + mutex_unlock(>xsp_devnode_lock);
> +}
> +
> +/* Turn off access from cdev and wait for all existing user to go away. */
> +static int xleaf_devnode_disallowed(struct platform_device *pdev)
> +{
> + int ret = 0;
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(pdev);
> +
> + mutex_lock(>xsp_devnode_lock);
> +
> + /* Prevent new opens. */
> + pdata->xsp_devnode_online = false;
> + /* Wait for existing user to close. */
> + while (!ret && pdata->xsp_devnode_ref) {
> + int rc;
> +
> + mutex_unlock(>xsp_devnode_lock);
> + rc = wait_for_completion_killable(>xsp_devnode_comp);
> + mutex_lock(>xsp_devnode_lock);
> +
> + if (rc == -ERESTARTSYS) {
> + /* Restore online state. */
> + pdata->xsp_devnode_online = true;
> + xrt_err(pdev, "%s is in use, ref=%d",
> + CDEV_NAME(pdata->xsp_sysdev),
> + pdata->xsp_devnode_ref);
> + ret = -EBUSY;
> + }
> + }
> +
> + mutex_unlock(>xsp_devnode_lock);
> +
> + return ret;
> +}
> +
> +static struct platform_device *
> +__xleaf_devnode_open(struct inode *inode, bool excl)
> +{
> + struct xrt_subdev_platdata *pdata = INODE2PDATA(inode);
> + struct platform_device *pdev = INODE2PDEV(inode);
> + bool opened = false;
> +
> + mutex_lock(>xsp_devnode_lock);
> +
> + if (pdata->xsp_devnode_online) {
> + if (excl && pdata->xsp_devnode_ref) {
> + xrt_err(pdev, "%s has already been opened exclusively",
> + CDEV_NAME(pdata->xsp_sysdev));
> + } else if (!excl && pdata->xsp_devnode_excl) {
> + xrt_err(pdev, "%s has been opened exclusively",
> + CDEV_NAME(pdata->xsp_sysdev));
> + } else {
> + pdata->xsp_devnode_ref++;
> + pdata->xsp_devnode_excl = excl;
> + opened = true;
> + xrt_info(pdev, "opened %s, ref=%d",
> +  CDEV_NAME(pdata->xsp_sysdev),
> +  pdata->xsp_devnode_ref);
> + }
> + } else {
> + xrt_err(pdev, "%s is offline", CDEV_NAME(pdata->xsp_sysdev));
> + }
> +
> + mutex_unlock(>xsp_devnode_lock);
> +
> + pdev = opened ? pdev : NULL;
> + return pdev;
> +}
> +
> +struct platform_device *
> +xleaf_devnode_open_excl(struct inode *inode)
> +{
> + return __xleaf_devnode_open(inode, true);
> +}
This function is unused, remove.
> +
> +struct platform_device *
> +xleaf_devnode_open(struct inode *inode)
> +{
> + return __xleaf_devnode_open(inode, false);
> +}
> +EXPORT_SYMBOL_GPL(xleaf_devnode_open);
does this really need to be exported ?
> +
> +void xleaf_devnode_close(struct inode *inode)
> +{
> + struct xrt_subdev_platdata *pdata = INODE2PDATA(inode);
> + struct platform_device *pdev = INODE2PDEV(inode);
> + bool notify = false;
> +
> + mutex_lock(>xsp_devnode_lock);
> +
> + WARN_ON(pdata->xsp_devnode_ref == 0);
> + 

Re: [PATCH V4 XRT Alveo 05/20] fpga: xrt: group platform driver

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> group driver that manages life cycle of a bunch of leaf driver instances
> and bridges them with root.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/group.h |  25 +++
>  drivers/fpga/xrt/lib/group.c | 286 +++
>  2 files changed, 311 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/group.h
>  create mode 100644 drivers/fpga/xrt/lib/group.c
>
> diff --git a/drivers/fpga/xrt/include/group.h 
> b/drivers/fpga/xrt/include/group.h
> new file mode 100644
> index ..09e9d03f53fe
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/group.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
ok, removed generic boilerplate
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_GROUP_H_
> +#define _XRT_GROUP_H_
> +
> +#include "xleaf.h"
move header to another patch
> +
> +/*
> + * Group driver leaf calls.
ok
> + */
> +enum xrt_group_leaf_cmd {
> + XRT_GROUP_GET_LEAF = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h 
> */
ok
> + XRT_GROUP_PUT_LEAF,
> + XRT_GROUP_INIT_CHILDREN,
> + XRT_GROUP_FINI_CHILDREN,
> + XRT_GROUP_TRIGGER_EVENT,
> +};
> +
> +#endif   /* _XRT_GROUP_H_ */
> diff --git a/drivers/fpga/xrt/lib/group.c b/drivers/fpga/xrt/lib/group.c
> new file mode 100644
> index ..7b8716569641
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/group.c
> @@ -0,0 +1,286 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Group Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include 
> +#include 
> +#include "xleaf.h"
> +#include "subdev_pool.h"
> +#include "group.h"
> +#include "metadata.h"
> +#include "lib-drv.h"
> +
> +#define XRT_GRP "xrt_group"
> +
> +struct xrt_group {
> + struct platform_device *pdev;
> + struct xrt_subdev_pool leaves;
> + bool leaves_created;
> + struct mutex lock; /* lock for group */
> +};
> +
> +static int xrt_grp_root_cb(struct device *dev, void *parg,
> +enum xrt_root_cmd cmd, void *arg)
ok
> +{
> + int rc;
> + struct platform_device *pdev =
> + container_of(dev, struct platform_device, dev);
> + struct xrt_group *xg = (struct xrt_group *)parg;
> +
> + switch (cmd) {
> + case XRT_ROOT_GET_LEAF_HOLDERS: {
> + struct xrt_root_get_holders *holders =
> + (struct xrt_root_get_holders *)arg;
> + rc = xrt_subdev_pool_get_holders(>leaves,
> +  holders->xpigh_pdev,
> +  holders->xpigh_holder_buf,
> +  holders->xpigh_holder_buf_len);
> + break;
> + }
> + default:
> + /* Forward parent call to root. */
> + rc = xrt_subdev_root_request(pdev, cmd, arg);
> + break;
> + }
> +
> + return rc;
> +}
> +
> +/*
> + * Cut subdev's dtb from group's dtb based on passed-in endpoint descriptor.
> + * Return the subdev's dtb through dtbp, if found.
> + */
> +static int xrt_grp_cut_subdev_dtb(struct xrt_group *xg, struct 
> xrt_subdev_endpoints *eps,
> +   char *grp_dtb, char **dtbp)
> +{
> + int ret, i, ep_count = 0;
> + char *dtb = NULL;
> +
> + ret = xrt_md_create(DEV(xg->pdev), );
> + if (ret)
> + return ret;
> +
> + for (i = 0; eps->xse_names[i].ep_name || eps->xse_names[i].regmap_name; 
> i++) {
> + const char *ep_name = eps->xse_names[i].ep_name;
> + const char *reg_name = eps->xse_names[i].regmap_name;
> +
> + if (!ep_name)
> + xrt_md_get_compatible_endpoint(DEV(xg->pdev), grp_dtb, 
> reg_name, _name);
> + if (!ep_name)
> + continue;
> +
> + ret = xrt_md_copy_endpoint(DEV(xg->pdev), dtb, grp_dtb, 
> ep_name, reg_name, NULL);
> + if (ret)
> + continue;
> + xrt_md_del_endpoint(DEV(xg->pdev), grp_dtb, ep_name, reg_name);
> + ep_count++;
> + }
> + /* Found enough endpoints, return the subdev's dtb. */
> + if (ep_count >= eps->xse_min_ep) {
> + *dtbp = dtb;
> + return 0;
> + }
> +
> + /* Cleanup - Restore all endpoints that has been deleted, if any. */
> + if (ep_count > 0) {
> + xrt_md_copy_endpoint(DEV(xg->pdev), grp_dtb, dtb,
> +  XRT_MD_NODE_ENDPOINTS, NULL, NULL);
> + }
> + vfree(dtb);
> + *dtbp = NULL;
> + return 0;
> +}
> +
> +static int xrt_grp_create_leaves(struct xrt_group *xg)
> +{
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(xg->pdev);
> + struct xrt_subdev_endpoints *eps = NULL;
> + int ret = 0, failed = 0;
> +   

Re: [PATCH V4 XRT Alveo 04/20] fpga: xrt: xrt-lib platform driver manager

[Tom Rix]

bisectablity may be/is  an issue.

Moritz,

building happens on the last patch, so in theory there will never be a build 
break needing bisection.  Do we care about the misordering of serveral of these 
patches?

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> xrt-lib kernel module infrastructure code to register and manage all
> leaf driver modules.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/subdev_id.h |  38 
>  drivers/fpga/xrt/include/xleaf.h | 264 +
>  drivers/fpga/xrt/lib/lib-drv.c   | 277 +++
ok
>  drivers/fpga/xrt/lib/lib-drv.h   |  17 ++
>  4 files changed, 596 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/subdev_id.h
>  create mode 100644 drivers/fpga/xrt/include/xleaf.h
>  create mode 100644 drivers/fpga/xrt/lib/lib-drv.c
>  create mode 100644 drivers/fpga/xrt/lib/lib-drv.h
>
> diff --git a/drivers/fpga/xrt/include/subdev_id.h 
> b/drivers/fpga/xrt/include/subdev_id.h
> new file mode 100644
> index ..42fbd6f5e80a
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/subdev_id.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_SUBDEV_ID_H_
> +#define _XRT_SUBDEV_ID_H_
> +
> +/*
> + * Every subdev driver has an ID for others to refer to it. There can be 
> multiple number of
> + * instances of a subdev driver. A  tuple is a 
> unique identification
> + * of a specific instance of a subdev driver.
> + */
> +enum xrt_subdev_id {
> + XRT_SUBDEV_GRP = 0,
not necessary to initialize all unless there are gaps.
> + XRT_SUBDEV_VSEC = 1,
> + XRT_SUBDEV_VSEC_GOLDEN = 2,
> + XRT_SUBDEV_DEVCTL = 3,
> + XRT_SUBDEV_AXIGATE = 4,
> + XRT_SUBDEV_ICAP = 5,
> + XRT_SUBDEV_TEST = 6,
> + XRT_SUBDEV_MGMT_MAIN = 7,
> + XRT_SUBDEV_QSPI = 8,
> + XRT_SUBDEV_MAILBOX = 9,
> + XRT_SUBDEV_CMC = 10,
> + XRT_SUBDEV_CALIB = 11,
> + XRT_SUBDEV_CLKFREQ = 12,
> + XRT_SUBDEV_CLOCK = 13,
> + XRT_SUBDEV_SRSR = 14,
> + XRT_SUBDEV_UCS = 15,
> + XRT_SUBDEV_NUM = 16, /* Total number of subdevs. */
> + XRT_ROOT = -1, /* Special ID for root driver. */
> +};
> +
> +#endif   /* _XRT_SUBDEV_ID_H_ */
> diff --git a/drivers/fpga/xrt/include/xleaf.h 
> b/drivers/fpga/xrt/include/xleaf.h
> new file mode 100644
> index ..acb500df04b0
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf.h
> @@ -0,0 +1,264 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *Cheng Zhen 
> + *Sonal Santan 
> + */
> +
> +#ifndef _XRT_XLEAF_H_
> +#define _XRT_XLEAF_H_
> +
> +#include 
> +#include 
> +#include 
> +#include "subdev_id.h"
> +#include "xroot.h"
> +#include "events.h"
> +
> +/* All subdev drivers should use below common routines to print out msg. */
> +#define DEV(pdev)(&(pdev)->dev)
> +#define DEV_PDATA(pdev)  \
> + ((struct xrt_subdev_platdata *)dev_get_platdata(DEV(pdev)))
> +#define DEV_DRVDATA(pdev)\
> + ((struct xrt_subdev_drvdata *)  \
> + platform_get_device_id(pdev)->driver_data)
> +#define FMT_PRT(prt_fn, pdev, fmt, args...)  \
> + ({typeof(pdev) (_pdev) = (pdev);\
> + prt_fn(DEV(_pdev), "%s %s: " fmt,   \
> + DEV_PDATA(_pdev)->xsp_root_name, __func__, ##args); })
> +#define xrt_err(pdev, fmt, args...) FMT_PRT(dev_err, pdev, fmt, ##args)
> +#define xrt_warn(pdev, fmt, args...) FMT_PRT(dev_warn, pdev, fmt, ##args)
> +#define xrt_info(pdev, fmt, args...) FMT_PRT(dev_info, pdev, fmt, ##args)
> +#define xrt_dbg(pdev, fmt, args...) FMT_PRT(dev_dbg, pdev, fmt, ##args)
> +
> +enum {
> + /* Starting cmd for common leaf cmd implemented by all leaves. */
> + XRT_XLEAF_COMMON_BASE = 0,
> + /* Starting cmd for leaves' specific leaf cmds. */
> + XRT_XLEAF_CUSTOM_BASE = 64,
> +};
> +
> +enum xrt_xleaf_common_leaf_cmd {
> + XRT_XLEAF_EVENT = XRT_XLEAF_COMMON_BASE,
> +};
> +
> +/*
> + * If populated by subdev driver, infra will handle the mechanics of
> + * char device (un)registration.
> + */
> +enum xrt_subdev_file_mode {
> + /* Infra create cdev, default file name */
> + XRT_SUBDEV_FILE_DEFAULT = 0,
> + /* Infra create cdev, need to encode inst num in file name */
> + XRT_SUBDEV_FILE_MULTI_INST,
> + /* No auto creation of cdev by infra, leaf handles it by itself */
> + XRT_SUBDEV_FILE_NO_AUTO,
> +};
> +
> +struct xrt_subdev_file_ops {
> + const struct file_operations xsf_ops;
> + dev_t xsf_dev_t;
> + const char *xsf_dev_name;
> + enum xrt_subdev_file_mode xsf_mode;
> +};
> +
> +/*
> + * Subdev driver callbacks populated by subdev driver.
> + */
> +struct xrt_subdev_drv_ops {
> + /*
> +  * Per driver instance 

Re: [PATCH V4 XRT Alveo 03/20] fpga: xrt: xclbin file helper functions

[Tom Rix]

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Alveo FPGA firmware and partial reconfigure file are in xclbin format. This
> code enumerates and extracts sections from xclbin files. xclbin.h is cross
> platform and used across all platforms and OS.
ok
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xclbin-helper.h |  48 +++
>  drivers/fpga/xrt/lib/xclbin.c| 369 
>  include/uapi/linux/xrt/xclbin.h  | 409 +++
>  3 files changed, 826 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xclbin-helper.h
>  create mode 100644 drivers/fpga/xrt/lib/xclbin.c
>  create mode 100644 include/uapi/linux/xrt/xclbin.h
>
> diff --git a/drivers/fpga/xrt/include/xclbin-helper.h 
> b/drivers/fpga/xrt/include/xclbin-helper.h
> new file mode 100644
> index ..382b1de97b0a
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xclbin-helper.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *David Zhang 
> + *Sonal Santan 
> + */
> +
> +#ifndef _XCLBIN_HELPER_H_
> +#define _XCLBIN_HELPER_H_
ok
> +
> +#include 
> +#include 
> +#include 
> +
> +#define XCLBIN_VERSION2  "xclbin2"
> +#define XCLBIN_HWICAP_BITFILE_BUF_SZ 1024
> +#define XCLBIN_MAX_SIZE (1024 * 1024 * 1024) /* Assuming xclbin <= 1G, 
> always */
ok
> +
> +enum axlf_section_kind;
> +struct axlf;
> +
> +/**
> + * Bitstream header information as defined by Xilinx tools.
> + * Please note that this struct definition is not owned by the driver.
> + */
> +struct xclbin_bit_head_info {
> + u32 header_length;  /* Length of header in 32 bit words */
> + u32 bitstream_length;   /* Length of bitstream to read in bytes 
> */
> + const unchar *design_name;  /* Design name get from bitstream */
> + const unchar *part_name;/* Part name read from bitstream */
> + const unchar *date; /* Date read from bitstream header */
> + const unchar *time; /* Bitstream creation time */
> + u32 magic_length;   /* Length of the magic numbers */
> + const unchar *version;  /* Version string */
> +};
> +
ok, bit removed.
> +/* caller must free the allocated memory for **data. len could be NULL. */
> +int xrt_xclbin_get_section(struct device *dev,  const struct axlf *xclbin,
> +enum axlf_section_kind kind, void **data,
> +uint64_t *len);

need to add comment that user must free data

need to add comment that len is optional

> +int xrt_xclbin_get_metadata(struct device *dev, const struct axlf *xclbin, 
> char **dtb);
> +int xrt_xclbin_parse_bitstream_header(struct device *dev, const unchar *data,
> +   u32 size, struct xclbin_bit_head_info 
> *head_info);
> +const char *xrt_clock_type2epname(enum XCLBIN_CLOCK_TYPE type);
ok
> +
> +#endif /* _XCLBIN_HELPER_H_ */
> diff --git a/drivers/fpga/xrt/lib/xclbin.c b/drivers/fpga/xrt/lib/xclbin.c
> new file mode 100644
> index ..31b363c014a3
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xclbin.c
> @@ -0,0 +1,369 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Driver XCLBIN parser
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors: David Zhang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "xclbin-helper.h"
> +#include "metadata.h"
> +
> +/* Used for parsing bitstream header */
> +#define BITSTREAM_EVEN_MAGIC_BYTE0x0f
> +#define BITSTREAM_ODD_MAGIC_BYTE 0xf0
ok
> +
> +static int xrt_xclbin_get_section_hdr(const struct axlf *xclbin,
> +   enum axlf_section_kind kind,
> +   const struct axlf_section_header **header)
> +{
> + const struct axlf_section_header *phead = NULL;
> + u64 xclbin_len;
> + int i;
> +
> + *header = NULL;
> + for (i = 0; i < xclbin->header.num_sections; i++) {
> + if (xclbin->sections[i].section_kind == kind) {
> + phead = >sections[i];
> + break;
> + }
> + }
> +
> + if (!phead)
> + return -ENOENT;
> +
> + xclbin_len = xclbin->header.length;
> + if (xclbin_len > XCLBIN_MAX_SIZE ||
> + phead->section_offset + phead->section_size > xclbin_len)
> + return -EINVAL;
> +
> + *header = phead;
> + return 0;
> +}
> +
> +static int xrt_xclbin_section_info(const struct axlf *xclbin,
> +enum axlf_section_kind kind,
> +u64 *offset, u64 *size)
> +{
> + const struct axlf_section_header *mem_header = NULL;
> + int rc;
> +
> + rc = xrt_xclbin_get_section_hdr(xclbin, kind, _header);
> + if (rc)
> + return rc;
> +
> + *offset = mem_header->section_offset;
> + *size = 

Re: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region

[Tom Rix]

On 3/27/21 11:09 AM, Moritz Fischer wrote:
> Hi Richard, Russ,
>
> On Thu, Feb 25, 2021 at 01:07:14PM +, Gong, Richard wrote:
>> Hi Moritz,
>>
>> Sorry for asking.
>>
>> When you have chance, can you help review the version 5 patchset submitted 
>> on 02/09/21?
>>
>> Regards,
>> Richard
>>
>> -Original Message-
>> From: richard.g...@linux.intel.com  
>> Sent: Tuesday, February 9, 2021 4:20 PM
>> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org; 
>> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Cc: Gong, Richard 
>> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>>
>> From: Richard Gong 
>>
>> This is 5th submission of Intel service layer and FPGA patches, which 
>> includes the missing standalone patch in the 4th submission.
>>
>> This submission includes additional changes for Intel service layer driver 
>> to get the firmware version running at FPGA SoC device. Then FPGA manager 
>> driver, one of Intel service layer driver's client, can decide whether to 
>> handle the newly added bitstream authentication function based on the 
>> retrieved firmware version. So that we can maintain FPGA manager driver the 
>> back compatible.
>>
>> Bitstream authentication makes sure a signed bitstream has valid signatures.
>>
>> The customer sends the bitstream via FPGA framework and overlay, the 
>> firmware will authenticate the bitstream but not program the bitstream to 
>> device. If the authentication passes, the bitstream will be programmed into 
>> QSPI flash and will be expected to boot without issues.
>>
>> Extend Intel service layer, FPGA manager and region drivers to support the 
>> bitstream authentication feature. 
>>
>> Richard Gong (7):
>>   firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0
>>   firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag
>>   firmware: stratix10-svc: extend SVC driver to get the firmware version
>>   fpga: fpga-mgr: add FPGA_MGR_BITSTREAM_AUTHENTICATE flag
>>   fpga: of-fpga-region: add authenticate-fpga-config property
>>   dt-bindings: fpga: add authenticate-fpga-config property
>>   fpga: stratix10-soc: extend driver for bitstream authentication
>>
>>  .../devicetree/bindings/fpga/fpga-region.txt   | 10 
>>  drivers/firmware/stratix10-svc.c   | 12 -
>>  drivers/fpga/of-fpga-region.c  | 24 ++---
>>  drivers/fpga/stratix10-soc.c   | 62 
>> +++---
>>  include/linux/firmware/intel/stratix10-smc.h   | 21 +++-
>>  .../linux/firmware/intel/stratix10-svc-client.h| 11 +++-
>>  include/linux/fpga/fpga-mgr.h  |  3 ++
>>  7 files changed, 125 insertions(+), 18 deletions(-)
>>
>> --
>> 2.7.4
>>
> Apologies for the epic delay in getting back to this, I took another
> look at this patchset and Russ' patchset.
>
> TL;DR I'm not really a fan of using device-tree overlays for this (and
> again, apologies, I should've voiced this earlier ...).
>
> Anyways, let's find a common API for this and Russ' work, they're trying
> to achieve the same / similar thing, they should use the same API.
>
> I'd like to re-invetigate the possiblity to extend FPGA Manager with
> 'secure update' ops that work for both these use-cases (and I susspect
> hte XRT patchset will follow with a similar requirement, right after).

The xrt patchset makes heavy use of device trees.

What is the general guidance for device tree usage ?

Tom

>
> - Moritz
>

Re: [PATCH V4 XRT Alveo 02/20] fpga: xrt: driver metadata helper functions

[Tom Rix]

Do not reorder function definitions, this makes comparing changes from the 
previous patchset difficult.

A general issue with returning consistent error codes.  There are several cases 
where fdt_* code are not translated.

On 3/23/21 10:29 PM, Lizhi Hou wrote:
> XRT drivers use device tree as metadata format to discover HW subsystems
> behind PCIe BAR. Thus libfdt functions are called for the driver to parse
> device tree blob.
to parse the device
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/metadata.h  | 233 
>  drivers/fpga/xrt/metadata/metadata.c | 545 +++
>  2 files changed, 778 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/metadata.h
>  create mode 100644 drivers/fpga/xrt/metadata/metadata.c
>
> diff --git a/drivers/fpga/xrt/include/metadata.h 
> b/drivers/fpga/xrt/include/metadata.h
> new file mode 100644
> index ..479e47960c61
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/metadata.h
> @@ -0,0 +1,233 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou 
> + */
> +
> +#ifndef _XRT_METADATA_H
> +#define _XRT_METADATA_H
> +
> +#include 
> +#include 
> +#include 
> +
> +#define XRT_MD_INVALID_LENGTH (~0UL)
> +
> +/* metadata properties */
> +#define XRT_MD_PROP_BAR_IDX "pcie_bar_mapping"
> +#define XRT_MD_PROP_COMPATIBLE "compatible"
> +#define XRT_MD_PROP_HWICAP "axi_hwicap"
> +#define XRT_MD_PROP_INTERFACE_UUID "interface_uuid"
> +#define XRT_MD_PROP_INTERRUPTS "interrupts"
> +#define XRT_MD_PROP_IO_OFFSET "reg"
> +#define XRT_MD_PROP_LOGIC_UUID "logic_uuid"
> +#define XRT_MD_PROP_PDI_CONFIG "pdi_config_mem"
> +#define XRT_MD_PROP_PF_NUM "pcie_physical_function"
> +#define XRT_MD_PROP_VERSION_MAJOR "firmware_version_major"
> +
> +/* non IP nodes */
> +#define XRT_MD_NODE_ENDPOINTS "addressable_endpoints"
> +#define XRT_MD_NODE_FIRMWARE "firmware"
> +#define XRT_MD_NODE_INTERFACES "interfaces"
> +#define XRT_MD_NODE_PARTITION_INFO "partition_info"
> +
> +/*
> + * IP nodes
> + * AF:  AXI Firewall
> + * CMC: Card Management Controller
> + * ERT: Embedded Runtime
* EP: End Point
> + * PLP: Provider Reconfigurable Partition
> + * ULP: User Reconfigurable Partition
> + */
> +#define XRT_MD_NODE_ADDR_TRANSLATOR "ep_remap_data_c2h_00"
> +#define XRT_MD_NODE_AF_BLP_CTRL_MGMT "ep_firewall_blp_ctrl_mgmt_00"
> +#define XRT_MD_NODE_AF_BLP_CTRL_USER "ep_firewall_blp_ctrl_user_00"
> +#define XRT_MD_NODE_AF_CTRL_DEBUG "ep_firewall_ctrl_debug_00"
> +#define XRT_MD_NODE_AF_CTRL_MGMT "ep_firewall_ctrl_mgmt_00"
> +#define XRT_MD_NODE_AF_CTRL_USER "ep_firewall_ctrl_user_00"
> +#define XRT_MD_NODE_AF_DATA_C2H "ep_firewall_data_c2h_00"
c2h ?
> +#define XRT_MD_NODE_AF_DATA_H2C "ep_firewall_data_h2c_00"
> +#define XRT_MD_NODE_AF_DATA_M2M "ep_firewall_data_m2m_00"
> +#define XRT_MD_NODE_AF_DATA_P2P "ep_firewall_data_p2p_00"
> +#define XRT_MD_NODE_CLKFREQ_HBM "ep_freq_cnt_aclk_hbm_00"
> +#define XRT_MD_NODE_CLKFREQ_K1 "ep_freq_cnt_aclk_kernel_00"
> +#define XRT_MD_NODE_CLKFREQ_K2 "ep_freq_cnt_aclk_kernel_01"
> +#define XRT_MD_NODE_CLK_KERNEL1 "ep_aclk_kernel_00"
> +#define XRT_MD_NODE_CLK_KERNEL2 "ep_aclk_kernel_01"
> +#define XRT_MD_NODE_CLK_KERNEL3 "ep_aclk_hbm_00"

hbm ?

unusual acronyms should be documented.

> +#define XRT_MD_NODE_CLK_SHUTDOWN "ep_aclk_shutdown_00"
> +#define XRT_MD_NODE_CMC_FW_MEM "ep_cmc_firmware_mem_00"
> +#define XRT_MD_NODE_CMC_MUTEX "ep_cmc_mutex_00"
> +#define XRT_MD_NODE_CMC_REG "ep_cmc_regmap_00"
> +#define XRT_MD_NODE_CMC_RESET "ep_cmc_reset_00"
> +#define XRT_MD_NODE_DDR_CALIB "ep_ddr_mem_calib_00"
> +#define XRT_MD_NODE_DDR4_RESET_GATE "ep_ddr_mem_srsr_gate_00"
> +#define XRT_MD_NODE_ERT_BASE "ep_ert_base_address_00"
> +#define XRT_MD_NODE_ERT_CQ_MGMT "ep_ert_command_queue_mgmt_00"
> +#define XRT_MD_NODE_ERT_CQ_USER "ep_ert_command_queue_user_00"
> +#define XRT_MD_NODE_ERT_FW_MEM "ep_ert_firmware_mem_00"
> +#define XRT_MD_NODE_ERT_RESET "ep_ert_reset_00"
> +#define XRT_MD_NODE_ERT_SCHED "ep_ert_sched_00"
> +#define XRT_MD_NODE_FLASH "ep_card_flash_program_00"
> +#define XRT_MD_NODE_FPGA_CONFIG "ep_fpga_configuration_00"
> +#define XRT_MD_NODE_GAPPING "ep_gapping_demand_00"
> +#define XRT_MD_NODE_GATE_PLP "ep_pr_isolate_plp_00"
> +#define XRT_MD_NODE_GATE_ULP "ep_pr_isolate_ulp_00"
> +#define XRT_MD_NODE_KDMA_CTRL "ep_kdma_ctrl_00"
> +#define XRT_MD_NODE_MAILBOX_MGMT "ep_mailbox_mgmt_00"
> +#define XRT_MD_NODE_MAILBOX_USER "ep_mailbox_user_00"
> +#define XRT_MD_NODE_MAILBOX_XRT "ep_mailbox_user_to_ert_00"
> +#define XRT_MD_NODE_MSIX "ep_msix_00"
> +#define XRT_MD_NODE_P2P "ep_p2p_00"
> +#define XRT_MD_NODE_PCIE_MON "ep_pcie_link_mon_00"
> +#define XRT_MD_NODE_PMC_INTR   "ep_pmc_intr_00"
> +#define XRT_MD_NODE_PMC_MUX"ep_pmc_mux_00"
> +#define XRT_MD_NODE_QDMA "ep_qdma_00"
> +#define XRT_MD_NODE_QDMA4 "ep_qdma4_00"
> +#define XRT_MD_NODE_REMAP_P2P "ep_remap_p2p_00"
> 

Re: [PATCH V4 XRT Alveo 01/20] Documentation: fpga: Add a document describing XRT Alveo drivers

[Tom Rix]

general problem with xmgmt needing to be changed to xrt-mgmt


On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Describe XRT driver architecture and provide basic overview of
> Xilinx Alveo platform.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  Documentation/fpga/index.rst |   1 +
>  Documentation/fpga/xrt.rst   | 844 +++
>  2 files changed, 845 insertions(+)
>  create mode 100644 Documentation/fpga/xrt.rst
>
> diff --git a/Documentation/fpga/index.rst b/Documentation/fpga/index.rst
> index f80f95667ca2..30134357b70d 100644
> --- a/Documentation/fpga/index.rst
> +++ b/Documentation/fpga/index.rst
> @@ -8,6 +8,7 @@ fpga
>  :maxdepth: 1
>  
>  dfl
> +xrt
>  
>  .. only::  subproject and html
>  
> diff --git a/Documentation/fpga/xrt.rst b/Documentation/fpga/xrt.rst
> new file mode 100644
> index ..0f7977464270
> --- /dev/null
> +++ b/Documentation/fpga/xrt.rst
> @@ -0,0 +1,844 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==
> +XRTV2 Linux Kernel Driver Overview
> +==
> +
> +Authors:
> +
> +* Sonal Santan 
> +* Max Zhen 
> +* Lizhi Hou 
> +
> +XRTV2 drivers are second generation `XRT `_
> +drivers which support `Alveo 
> `_
> +PCIe platforms from Xilinx.
> +
> +XRTV2 drivers support *subsystem* style data driven platforms where driver's
> +configuration and behavior is determined by meta data provided by the 
> platform
> +(in *device tree* format). Primary management physical function (MPF) driver
> +is called **xmgmt**. Primary user physical function (UPF) driver is called
> +**xuser** and is under development. xrt driver framework and HW subsystem
> +drivers are packaged into a library module called **xrt-lib**, which is
> +shared by **xmgmt** and **xuser** (under development). The xrt driver 
> framework
> +implements a pseudo-bus which is used to discover HW subsystems and 
> facilitate
> +inter HW subsystem interaction.
> +
> +Driver Modules
> +==
> +
> +xrt-lib.ko
> +--
> +
> +Repository of all subsystem drivers and pure software modules that can 
> potentially
> +be shared between xmgmt and xuser. All these drivers are structured as Linux
> +*platform driver* and are instantiated by xmgmt (or xuser under development) 
> based
> +on meta data associated with the hardware. The metadata is in the form of a 
> device
ok
> +tree as mentioned before. Each platform driver statically defines a 
> subsystem node
> +array by using node name or a string in its ``compatible`` property. And this
> +array is eventually translated to IOMEM resources of the platform device.
> +
> +The xrt-lib core infrastructure provides hooks to platform drivers for 
> device node
> +management, user file operations and ioctl callbacks. The core 
> infrastructure also
ok
> +provides pseudo-bus functionality for platform driver registration, 
> discovery and
> +inter platform driver ioctl calls.
if/where infrastructure moves is undecided.
> +
> +.. note::
> +   See code in ``include/xleaf.h``
> +
> +
> +xmgmt.ko
> +
> +
> +The xmgmt driver is a PCIe device driver driving MPF found on Xilinx's Alveo
> +PCIE device. It consists of one *root* driver, one or more *group* drivers
> +and one or more *xleaf* drivers. The root and MPF specific xleaf drivers are
> +in xmgmt.ko. The group driver and other xleaf drivers are in xrt-lib.ko.
> +
> +The instantiation of specific group driver or xleaf driver is completely data
> +driven based on meta data (mostly in device tree format) found through VSEC
> +capability and inside firmware files, such as platform xsabin or user xclbin 
> file.
> +The root driver manages the life cycle of multiple group drivers, which, in 
> turn,
> +manages multiple xleaf drivers. This allows a single set of drivers to 
> support
ok
> +all kinds of subsystems exposed by different shells. The difference among all
> +these subsystems will be handled in xleaf drivers with root and group drivers
> +being part of the infrastructure and provide common services for all leaves
> +found on all platforms.
> +
> +The driver object model looks like the following::
> +
> ++---+
> +|   xroot   |
> ++-+-+
> +  |
> +  +---+---+
> +  |   |
> +  v   v
> ++---+  +---+
> +|   group   |...   |   group   |
> ++-+-+  +--++
> +  |   |
> +  |   |
> ++-+++-++
> +|  ||  |
> +v  vv  v
> ++---+  +---++---+  

Re: [PATCH net-next] airo: work around stack usage warning

[Tom Rix]

On 3/23/21 6:16 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann 
>
> gcc-11 with KASAN on 32-bit arm produces a warning about a function
> that needs a lot of stack space:
>
> drivers/net/wireless/cisco/airo.c: In function 'setup_card.constprop':
> drivers/net/wireless/cisco/airo.c:3960:1: error: the frame size of 1512 bytes 
> is larger than 1400 bytes [-Werror=frame-larger-than=]
>
> Most of this is from a single large structure that could be dynamically
> allocated or moved into the per-device structure.  However, as the callers
> all seem to have a fairly well bounded call chain, the easiest change
> is to pull out the part of the function that needs the large variables
> into a separate function and mark that as noinline_for_stack. This does
> not reduce the total stack usage, but it gets rid of the warning and
> requires minimal changes otherwise.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/net/wireless/cisco/airo.c | 117 +-
>  1 file changed, 65 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/wireless/cisco/airo.c 
> b/drivers/net/wireless/cisco/airo.c
> index e35e1380ae43..540ba694899c 100644
> --- a/drivers/net/wireless/cisco/airo.c
> +++ b/drivers/net/wireless/cisco/airo.c
> @@ -3818,6 +3818,68 @@ static inline void set_auth_type(struct airo_info 
> *local, int auth_type)
>   local->last_auth = auth_type;
>  }
>  
> +static int noinline_for_stack airo_readconfig(struct airo_info *ai, u8 *mac, 
> int lock)
> +{
> + int i, status;
> + /* large variables, so don't inline this function,
> +  * maybe change to kmalloc
> +  */
> + tdsRssiRid rssi_rid;
> + CapabilityRid cap_rid;
> +
> + kfree(ai->SSID);
> + ai->SSID = NULL;
> + // general configuration (read/modify/write)
> + status = readConfigRid(ai, lock);
> + if (status != SUCCESS) return ERROR;
> +
> + status = readCapabilityRid(ai, _rid, lock);
> + if (status != SUCCESS) return ERROR;
> +
> + status = PC4500_readrid(ai, RID_RSSI, _rid, sizeof(rssi_rid), 
> lock);
> + if (status == SUCCESS) {
> + if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) != NULL)
> + memcpy(ai->rssi, (u8*)_rid + 2, 512); /* Skip RID 
> length member */
> + }
> + else {
> + kfree(ai->rssi);
> + ai->rssi = NULL;
> + if (cap_rid.softCap & cpu_to_le16(8))
> + ai->config.rmode |= RXMODE_NORMALIZED_RSSI;
> + else
> + airo_print_warn(ai->dev->name, "unknown received signal 
> "
> + "level scale");
> + }
> + ai->config.opmode = adhoc ? MODE_STA_IBSS : MODE_STA_ESS;
> + set_auth_type(ai, AUTH_OPEN);
> + ai->config.modulation = MOD_CCK;
> +
> + if (le16_to_cpu(cap_rid.len) >= sizeof(cap_rid) &&
> + (cap_rid.extSoftCap & cpu_to_le16(1)) &&
> + micsetup(ai) == SUCCESS) {
> + ai->config.opmode |= MODE_MIC;
> + set_bit(FLAG_MIC_CAPABLE, >flags);
> + }
> +
> + /* Save off the MAC */
> + for (i = 0; i < ETH_ALEN; i++) {
> + mac[i] = ai->config.macAddr[i];
> + }
> +
> + /* Check to see if there are any insmod configured
> +rates to add */
> + if (rates[0]) {
> + memset(ai->config.rates, 0, sizeof(ai->config.rates));
> + for (i = 0; i < 8 && rates[i]; i++) {
> + ai->config.rates[i] = rates[i];
> + }
> + }
> + set_bit (FLAG_COMMIT, >flags);
> +
> + return SUCCESS;
> +}
> +
> +
>  static u16 setup_card(struct airo_info *ai, u8 *mac, int lock)
>  {
>   Cmd cmd;
> @@ -3864,58 +3926,9 @@ static u16 setup_card(struct airo_info *ai, u8 *mac, 
> int lock)
>   if (lock)
>   up(>sem);
>   if (ai->config.len == 0) {
> - int i;
> - tdsRssiRid rssi_rid;
This is mostly an array, and what I guess is the problem.
> - CapabilityRid cap_rid;
> -
> - kfree(ai->SSID);
> - ai->SSID = NULL;
> - // general configuration (read/modify/write)
> - status = readConfigRid(ai, lock);
> - if (status != SUCCESS) return ERROR;
> -
> - status = readCapabilityRid(ai, _rid, lock);
> - if (status != SUCCESS) return ERROR;
> -
> - status = PC4500_readrid(ai, RID_RSSI,_rid, 
> sizeof(rssi_rid), lock);
This is reading into a stack temp
> - if (status == SUCCESS) {
> - if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) 
> != NULL)
> - memcpy(ai->rssi, (u8*)_rid + 2, 512); /* 
> Skip RID length member */

Here is the temp being copied to heap memory.

This is the only use of rssi_rid

Why not do the alloc in PC4500_read ?

The call would be something like

status = PC4500_readrid(ai, RID_RSSI, >rssi, sizeof(), lock)

or since ai, is common reduce the signature of 

Re: [PATCH] amdgpu: avoid incorrect %hu format string

[Tom Rix]

On 3/22/21 4:54 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann 
>
> clang points out that the %hu format string does not match the type
> of the variables here:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type 
> 'unsigned short' but the argument has type 'unsigned int' [-Wformat]
>   version_major, version_minor);
>   ^
> include/drm/drm_print.h:498:19: note: expanded from macro 'DRM_ERROR'
> __drm_err(fmt, ##__VA_ARGS__)
>   ~~~^~~
>
> Change it to a regular %u, the same way a previous patch did for
> another instance of the same warning.

It would be good to explicitly call out the change.

ex/ do you mean mine ?

0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")

This was for a different reason.

imo, you do not need to include what another patch did.

so you could also just remove this bit from the commit log.


The change itself looks good.

Reviewed-by: Tom Rix 

>
> Fixes: 0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index e2ed4689118a..c6dbc0801604 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -259,7 +259,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
>   if ((adev->asic_type == CHIP_POLARIS10 ||
>adev->asic_type == CHIP_POLARIS11) &&
>   (adev->uvd.fw_version < FW_1_66_16))
> - DRM_ERROR("POLARIS10/11 UVD firmware version %hu.%hu is 
> too old.\n",
> + DRM_ERROR("POLARIS10/11 UVD firmware version %u.%u is 
> too old.\n",
> version_major, version_minor);
>   } else {
>   unsigned int enc_major, enc_minor, dec_minor;

Re: FW: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region

[Tom Rix]

On 3/21/21 2:05 PM, Richard Gong wrote:
>
> Hi Tom,
>
>>
>>
>> On 3/19/21 4:22 PM, Richard Gong wrote:
>>>
>>> Hi Moritz,
>>>
>>> Thanks for approving the 1st patch of my version 5 patchest, which 
>>> submitted on 02/09/21.
>>
>> This change
>>
>> e23bd83368af ("firmware: stratix10-svc: fix kernel-doc markups")
>
> This patch e23bd83368af is not from my version 5 patch set.

Correct.

But since it is already in char-misc-next, your version 5 patchset will 
conflict with it.

I could not apply this patchset to my unoffical fpga-testing.

I am suggesting you do a test application of your patchset against 
char-misc-next.

And if you find there are issues, rebase your patchset. 

>>
>> Makes a lot of formatting changes in the same files as this patchset, 
>> including the first patch.
>>
>> It would be good to try applying this patchset to char-misc-next and 
>> resubmit if there are conflicts.
>>
>>>
>>> Can you help review the remaining 6 patches from the same version 5 
>>> patchset? I need your ACKs to move forward, or please let me know if 
>>> additional work is need.
>>
>> These changes look good to me.
>>
>> I was looking at the patchset again seeing if the firmware/ parts could be 
>> split out.
>
> No, we can't split out the firmware parts.

ok

Tom

>>
>> Even though stratix10 is a fpga, from the MAINTAINERS file it is not clear 
>> to me if linux-fpga owns them and they come in on Moritz's branch.  I think 
>> this change is needed to the MAINTAINERS file to make that clearer.
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index aa84121c5611..1f68e9ff76de 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9193,7 +9193,8 @@ F:    tools/power/x86/intel-speed-select/
>>     INTEL STRATIX10 FIRMWARE DRIVERS
>>   M:    Richard Gong 
>> -L:    linux-kernel@vger.kernel.org
>> +R:    Tom Rix 
>> +L:    linux-f...@vger.kernel.org
>>   S:    Maintained
>>   F:    Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu
>>   F:    Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
>>
>> I also added myself as a reviewer because I want to help out.
>>
>> Tom
>>
>
> Regards,
> Richard
>
>>
>>>
>>> Many thanks for your time again!
>>>
>>> Regards,
>>> Richard
>>>
>>>
>>> On 2/25/21 7:07 AM, Gong, Richard wrote:
>>>> Hi Moritz,
>>>>
>>>> Sorry for asking.
>>>>
>>>> When you have chance, can you help review the version 5 patchset submitted 
>>>> on 02/09/21?
>>>>
>>>> Regards,
>>>> Richard
>>>>
>>>> -Original Message-
>>>> From: richard.g...@linux.intel.com 
>>>> Sent: Tuesday, February 9, 2021 4:20 PM
>>>> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org; 
>>>> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
>>>> Cc: Gong, Richard 
>>>> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>>>>
>>>> From: Richard Gong 
>>>>
>>>> This is 5th submission of Intel service layer and FPGA patches, which 
>>>> includes the missing standalone patch in the 4th submission.
>>>>
>>>> This submission includes additional changes for Intel service layer driver 
>>>> to get the firmware version running at FPGA SoC device. Then FPGA manager 
>>>> driver, one of Intel service layer driver's client, can decide whether to 
>>>> handle the newly added bitstream authentication function based on the 
>>>> retrieved firmware version. So that we can maintain FPGA manager driver 
>>>> the back compatible.
>>>>
>>>> Bitstream authentication makes sure a signed bitstream has valid 
>>>> signatures.
>>>>
>>>> The customer sends the bitstream via FPGA framework and overlay, the 
>>>> firmware will authenticate the bitstream but not program the bitstream to 
>>>> device. If the authentication passes, the bitstream will be programmed 
>>>> into QSPI flash and will be expected to boot without issues.
>>>>
>>>> Extend Intel service layer, FPGA manager and region drivers to support the 
>>>> bitstream authentication feature.
>>>>
>>>> Richard Gong (7):
>>>>     firmware: stratix10-svc: reset COMMAND_R

Re: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region

[Tom Rix]

On 3/19/21 4:22 PM, Richard Gong wrote:
>
> Hi Moritz,
>
> Thanks for approving the 1st patch of my version 5 patchest, which submitted 
> on 02/09/21.

This change

e23bd83368af ("firmware: stratix10-svc: fix kernel-doc markups")

Makes a lot of formatting changes in the same files as this patchset, including 
the first patch.

It would be good to try applying this patchset to char-misc-next and resubmit 
if there are conflicts.

>
> Can you help review the remaining 6 patches from the same version 5 patchset? 
> I need your ACKs to move forward, or please let me know if additional work is 
> need.

These changes look good to me.

I was looking at the patchset again seeing if the firmware/ parts could be 
split out.

Even though stratix10 is a fpga, from the MAINTAINERS file it is not clear to 
me if linux-fpga owns them and they come in on Moritz's branch.  I think this 
change is needed to the MAINTAINERS file to make that clearer.

diff --git a/MAINTAINERS b/MAINTAINERS
index aa84121c5611..1f68e9ff76de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9193,7 +9193,8 @@ F:    tools/power/x86/intel-speed-select/
 
 INTEL STRATIX10 FIRMWARE DRIVERS
 M:    Richard Gong 
-L:    linux-kernel@vger.kernel.org
+R:    Tom Rix 
+L:    linux-f...@vger.kernel.org
 S:    Maintained
 F:    Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu
 F:    Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt

I also added myself as a reviewer because I want to help out.

Tom


>
> Many thanks for your time again!
>
> Regards,
> Richard
>
>
> On 2/25/21 7:07 AM, Gong, Richard wrote:
>> Hi Moritz,
>>
>> Sorry for asking.
>>
>> When you have chance, can you help review the version 5 patchset submitted 
>> on 02/09/21?
>>
>> Regards,
>> Richard
>>
>> -Original Message-
>> From: richard.g...@linux.intel.com 
>> Sent: Tuesday, February 9, 2021 4:20 PM
>> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org; 
>> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Cc: Gong, Richard 
>> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>>
>> From: Richard Gong 
>>
>> This is 5th submission of Intel service layer and FPGA patches, which 
>> includes the missing standalone patch in the 4th submission.
>>
>> This submission includes additional changes for Intel service layer driver 
>> to get the firmware version running at FPGA SoC device. Then FPGA manager 
>> driver, one of Intel service layer driver's client, can decide whether to 
>> handle the newly added bitstream authentication function based on the 
>> retrieved firmware version. So that we can maintain FPGA manager driver the 
>> back compatible.
>>
>> Bitstream authentication makes sure a signed bitstream has valid signatures.
>>
>> The customer sends the bitstream via FPGA framework and overlay, the 
>> firmware will authenticate the bitstream but not program the bitstream to 
>> device. If the authentication passes, the bitstream will be programmed into 
>> QSPI flash and will be expected to boot without issues.
>>
>> Extend Intel service layer, FPGA manager and region drivers to support the 
>> bitstream authentication feature.
>>
>> Richard Gong (7):
>>    firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0
>>    firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag
>>    firmware: stratix10-svc: extend SVC driver to get the firmware version
>>    fpga: fpga-mgr: add FPGA_MGR_BITSTREAM_AUTHENTICATE flag
>>    fpga: of-fpga-region: add authenticate-fpga-config property
>>    dt-bindings: fpga: add authenticate-fpga-config property
>>    fpga: stratix10-soc: extend driver for bitstream authentication
>>
>>   .../devicetree/bindings/fpga/fpga-region.txt   | 10 
>>   drivers/firmware/stratix10-svc.c   | 12 -
>>   drivers/fpga/of-fpga-region.c  | 24 ++---
>>   drivers/fpga/stratix10-soc.c   | 62 
>> +++---
>>   include/linux/firmware/intel/stratix10-smc.h   | 21 +++-
>>   .../linux/firmware/intel/stratix10-svc-client.h    | 11 +++-
>>   include/linux/fpga/fpga-mgr.h  |  3 ++
>>   7 files changed, 125 insertions(+), 18 deletions(-)
>>
>> -- 
>> 2.7.4
>>
>

Re: [PATCH V3 XRT Alveo 13/18] fpga: xrt: devctl platform driver

[Tom Rix]

On 3/16/21 4:54 PM, Lizhi Hou wrote:
>
>
> On 03/04/2021 05:39 AM, Tom Rix wrote:
>> CAUTION: This message has originated from an External Source. Please use 
>> proper judgment and caution when opening attachments, clicking links, or 
>> responding to this email.
>>
>>
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> Add devctl driver. devctl is a type of hardware function which only has
>>> few registers to read or write. They are discovered by walking firmware
>>> metadata. A platform device node will be created for them.
>>>
>>> Signed-off-by: Sonal Santan 
>>> Signed-off-by: Max Zhen 
>>> Signed-off-by: Lizhi Hou 
>>> ---
>>>   drivers/fpga/xrt/include/xleaf/devctl.h |  43 +
>>>   drivers/fpga/xrt/lib/xleaf/devctl.c | 206 
>>>   2 files changed, 249 insertions(+)
>>>   create mode 100644 drivers/fpga/xrt/include/xleaf/devctl.h
>>>   create mode 100644 drivers/fpga/xrt/lib/xleaf/devctl.c
>>>
>>> diff --git a/drivers/fpga/xrt/include/xleaf/devctl.h 
>>> b/drivers/fpga/xrt/include/xleaf/devctl.h
>>> new file mode 100644
>>> index ..96a40e066f83
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xleaf/devctl.h
>>> @@ -0,0 +1,43 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for XRT DEVCTL Leaf Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + *   Lizhi Hou 
>>> + */
>>> +
>>> +#ifndef _XRT_DEVCTL_H_
>>> +#define _XRT_DEVCTL_H_
>>> +
>>> +#include "xleaf.h"
>>> +
>>> +/*
>>> + * DEVCTL driver IOCTL calls.
>>> + */
>>> +enum xrt_devctl_ioctl_cmd {
>>> + XRT_DEVCTL_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
>>> + XRT_DEVCTL_WRITE,
>>> +};
>>> +
>>> +enum xrt_devctl_id {
>>> + XRT_DEVCTL_ROM_UUID,
>> Assumes 0, should make this explicit and initialize to 0
> Sure.
>>> + XRT_DEVCTL_DDR_CALIB,
>>> + XRT_DEVCTL_GOLDEN_VER,
>>> + XRT_DEVCTL_MAX
>>> +};
>>> +
>>> +struct xrt_devctl_ioctl_rw {
>>> + u32 xgir_id;
>>> + void    *xgir_buf;
>>> + u32 xgir_len;
>>> + u32 xgir_offset;
>> similar to other patches, the xgir_ prefix is not needed
>>> +};
>>> +
>>> +struct xrt_devctl_ioctl_intf_uuid {
>>> + u32 xgir_uuid_num;
>>> + uuid_t  *xgir_uuids;
>>> +};
>>> +
>>> +#endif   /* _XRT_DEVCTL_H_ */
>>> diff --git a/drivers/fpga/xrt/lib/xleaf/devctl.c 
>>> b/drivers/fpga/xrt/lib/xleaf/devctl.c
>>> new file mode 100644
>>> index ..caf8c6569f0f
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/lib/xleaf/devctl.c
>>> @@ -0,0 +1,206 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Xilinx Alveo FPGA devctl Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + *  Lizhi Hou
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include "metadata.h"
>>> +#include "xleaf.h"
>>> +#include "xleaf/devctl.h"
>>> +
>>> +#define XRT_DEVCTL "xrt_devctl"
>>> +
>>> +struct xrt_name_id {
>>> + char *ep_name;
>>> + int id;
>>> +};
>>> +
>>> +static struct xrt_name_id name_id[XRT_DEVCTL_MAX] = {
>>> + { XRT_MD_NODE_BLP_ROM, XRT_DEVCTL_ROM_UUID },
>>> + { XRT_MD_NODE_GOLDEN_VER, XRT_DEVCTL_GOLDEN_VER },
>> DDR_CALIB is unused ?
> Not sure if I understand the question correctly. ddr_calib will have more 
> things need to handle other than just read/write.

I do not understand either, ignore this comment.

If it is important, I will bring it up in a later revision's review and do a 
better job of explaining the issue.

Tom

>>> +};
>>> +
>>> +struct xrt_devctl {
>>> + struct platform_device  *pdev;
>>> + void    __iomem *base_addrs[XRT_DEVCTL_MAX];
>>> + ulong   sizes[XRT_DEVCTL_MAX];
>>> +};
>> similar to other patches, why not use regmap ?
> Will change to regmap.
>>> +

Re: [PATCH V3 XRT Alveo 08/18] fpga: xrt: main platform driver for management function device

[Tom Rix]

On 3/16/21 2:23 PM, Lizhi Hou wrote:
> Hi Tom,
>
>
> On 02/26/2021 09:22 AM, Tom Rix wrote:
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> platform driver that handles IOCTLs, such as hot reset and xclbin download.
>>>
>>> Signed-off-by: Sonal Santan 
>>> Signed-off-by: Max Zhen 
>>> Signed-off-by: Lizhi Hou 
>>> ---
>>>   drivers/fpga/xrt/include/xmgmt-main.h |  37 ++
>>>   drivers/fpga/xrt/mgmt/main-impl.h |  37 ++
>>>   drivers/fpga/xrt/mgmt/main.c  | 693 ++
>>>   include/uapi/linux/xrt/xmgmt-ioctl.h  |  46 ++
>>>   4 files changed, 813 insertions(+)
>>>   create mode 100644 drivers/fpga/xrt/include/xmgmt-main.h
>>>   create mode 100644 drivers/fpga/xrt/mgmt/main-impl.h
>>>   create mode 100644 drivers/fpga/xrt/mgmt/main.c
>>>   create mode 100644 include/uapi/linux/xrt/xmgmt-ioctl.h
>>>
>>> diff --git a/drivers/fpga/xrt/include/xmgmt-main.h 
>>> b/drivers/fpga/xrt/include/xmgmt-main.h
>>> new file mode 100644
>>> index ..1216d1881f8e
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xmgmt-main.h
>>> @@ -0,0 +1,37 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Runtime (XRT) driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + *   Cheng Zhen 
>>> + */
>>> +
>>> +#ifndef _XMGMT_MAIN_H_
>>> +#define _XMGMT_MAIN_H_
>>> +
>>> +#include 
>>> +#include "xleaf.h"
>>> +
>>> +enum xrt_mgmt_main_ioctl_cmd {
>>> + /* section needs to be vfree'd by caller */
>>> + XRT_MGMT_MAIN_GET_AXLF_SECTION = XRT_XLEAF_CUSTOM_BASE, /* See 
>>> comments in xleaf.h */
>> the must free instructions should go with the pointer needing freeing
> Sure. Will move the free instructions.
>>> + /* vbnv needs to be kfree'd by caller */
>>> + XRT_MGMT_MAIN_GET_VBNV,
>>> +};
>>> +
>>> +enum provider_kind {
>>> + XMGMT_BLP,
>>> + XMGMT_PLP,
>>> + XMGMT_ULP,
>> what do these three mean ?
> Will add comment
>
> /* There are three kind of partitions. Each of them is programmed 
> independently. */
> enum provider_kind {
>     XMGMT_BLP, /* Base Logic Partition */
>     XMGMT_PLP, /* Provider Logic Partition */
>     XMGMT_ULP, /* User Logic Partition */
> };
>
looks good
>>> +};
>>> +
>>> +struct xrt_mgmt_main_ioctl_get_axlf_section {
>>> + enum provider_kind xmmigas_axlf_kind;
>>> + enum axlf_section_kind xmmigas_section_kind;
>>> + void *xmmigas_section;
>>> + u64 xmmigas_section_size;
>>> +};
>>> +
>>> +#endif   /* _XMGMT_MAIN_H_ */
>>> diff --git a/drivers/fpga/xrt/mgmt/main-impl.h 
>>> b/drivers/fpga/xrt/mgmt/main-impl.h
>>  From prefix used in the functions, a better name for this file would be 
>> xmgnt.h
> Will change.
>>> new file mode 100644
>>> index ..dd1b3e3773cc
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/mgmt/main-impl.h
>>> @@ -0,0 +1,37 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Alveo Management Function Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + *   Lizhi Hou 
>>> + *   Cheng Zhen 
>>> + */
>>> +
>>> +#ifndef _XMGMT_MAIN_IMPL_H_
>>> +#define _XMGMT_MAIN_IMPL_H_
>>> +
>>> +#include 
>>> +#include "xmgmt-main.h"
>>> +
>>> +struct fpga_manager;
>>> +int xmgmt_process_xclbin(struct platform_device *pdev,
>>> +  struct fpga_manager *fmgr,
>>> +  const struct axlf *xclbin,
>>> +  enum provider_kind kind);
>>> +void xmgmt_region_cleanup_all(struct platform_device *pdev);
>>> +
>>> +int bitstream_axlf_mailbox(struct platform_device *pdev, const void 
>>> *xclbin);
>> the prefix should be consistent
> Will fix this.
>>> +int xmgmt_hot_reset(struct platform_device *pdev);
>>> +
>>> +/* Getting dtb for specified group. Caller should vfree returned dtb .*/
>>> +char *xmgmt_get_dtb(struct platform_device *pdev, enum provider_kind kind);
>>> +char *xmgmt_get_vbnv(struct platform_device *pdev);
>>> +int xm

Re: [PATCH V3 XRT Alveo 07/18] fpga: xrt: management physical function driver (root)

[Tom Rix]

On 3/16/21 1:29 PM, Max Zhen wrote:
> Hi Tom,
>
>
> On 2/26/21 7:01 AM, Tom Rix wrote:
>> CAUTION: This message has originated from an External Source. Please use 
>> proper judgment and caution when opening attachments, clicking links, or 
>> responding to this email.
>>
>>
>> A question i do not know the answer to.
>>
>> Seems like 'golden' is linked to a manufacturing (diagnostics?) image.
>>
>> If the public will never see it, should handling it here be done ?
>>
>> Moritz, do you know ?
>
>
> Golden image is preloaded on the device when it is shipped to customer. Then, 
> customer can load other shells (from Xilinx or some other vendor). If 
> something goes wrong with the shell, customer can always go back to golden 
> and start over again. So, golden image is going to be used in public, not 
> just internally by Xilinx.
>
>
Thanks for the explanation.


>>
>>
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> The PCIE device driver which attaches to management function on Alveo
>> to the management
>
>
> Sure.
>
>
>>> devices. It instantiates one or more partition drivers which in turn
>> more fpga partition / group ?
>
>
> Group driver.
>
>
>>> instantiate platform drivers. The instantiation of partition and platform
>>> drivers is completely data driven.
>> data driven ? everything is data driven.  do you mean dtb driven ?
>
>
> Data driven means not hard-coded. Here data means meta data which is 
> presented in device tree format, dtb.
>
>
>>> Signed-off-by: Sonal Santan 
>>> Signed-off-by: Max Zhen 
>>> Signed-off-by: Lizhi Hou 
>>> ---
>>>   drivers/fpga/xrt/include/xroot.h | 114 +++
>>>   drivers/fpga/xrt/mgmt/root.c | 342 +++
>>>   2 files changed, 456 insertions(+)
>>>   create mode 100644 drivers/fpga/xrt/include/xroot.h
>>>   create mode 100644 drivers/fpga/xrt/mgmt/root.c
>>>
>>> diff --git a/drivers/fpga/xrt/include/xroot.h 
>>> b/drivers/fpga/xrt/include/xroot.h
>>> new file mode 100644
>>> index ..752e10daa85e
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xroot.h
>>> @@ -0,0 +1,114 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Runtime (XRT) driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + *   Cheng Zhen 
>>> + */
>>> +
>>> +#ifndef _XRT_ROOT_H_
>>> +#define _XRT_ROOT_H_
>>> +
>>> +#include 
>>> +#include "subdev_id.h"
>>> +#include "events.h"
>>> +
>>> +typedef bool (*xrt_subdev_match_t)(enum xrt_subdev_id,
>>> + struct platform_device *, void *);
>>> +#define XRT_SUBDEV_MATCH_PREV    ((xrt_subdev_match_t)-1)
>>> +#define XRT_SUBDEV_MATCH_NEXT    ((xrt_subdev_match_t)-2)
>>> +
>>> +/*
>>> + * Root IOCTL calls.
>>> + */
>>> +enum xrt_root_ioctl_cmd {
>>> + /* Leaf actions. */
>>> + XRT_ROOT_GET_LEAF = 0,
>>> + XRT_ROOT_PUT_LEAF,
>>> + XRT_ROOT_GET_LEAF_HOLDERS,
>>> +
>>> + /* Group actions. */
>>> + XRT_ROOT_CREATE_GROUP,
>>> + XRT_ROOT_REMOVE_GROUP,
>>> + XRT_ROOT_LOOKUP_GROUP,
>>> + XRT_ROOT_WAIT_GROUP_BRINGUP,
>>> +
>>> + /* Event actions. */
>>> + XRT_ROOT_EVENT,
>> should this be XRT_ROOT_EVENT_SYNC ?
>
>
> Sure.
>
>
>>> + XRT_ROOT_EVENT_ASYNC,
>>> +
>>> + /* Device info. */
>>> + XRT_ROOT_GET_RESOURCE,
>>> + XRT_ROOT_GET_ID,
>>> +
>>> + /* Misc. */
>>> + XRT_ROOT_HOT_RESET,
>>> + XRT_ROOT_HWMON,
>>> +};
>>> +
>>> +struct xrt_root_ioctl_get_leaf {
>>> + struct platform_device *xpigl_pdev; /* caller's pdev */
>> xpigl_ ? unneeded suffix in element names
>
>
> It's needed since the it might be included and used in > 1 .c files. I'd like 
> to keep it's name unique.

This is an element name, the variable name sound be unique enough to make it 
clear.

This is not a critical issue, ok as-is.

>
>
>>> + xrt_subdev_match_t xpigl_match_cb;
>>> + void *xpigl_match_arg;
>>> + struct platform_device *xpigl_leaf; /* target leaf pdev */
>>> +};
>>> +
>>> +struct xrt_root_ioctl_put_leaf {
&

Re: [PATCH v10 3/5] fpga: m10bmc-sec: expose max10 canceled keys in sysfs

[Tom Rix]

On 3/12/21 11:36 AM, Russ Weight wrote:
> Extend the MAX10 BMC Secure Update driver to provide sysfs
> files to expose the canceled code signing key (CSK) bit
> vectors. These use the standard bitmap list format
> (e.g. 1,2-6,9).
>
> Signed-off-by: Russ Weight 
> Reviewed-by: Tom Rix 
> ---
> v10:
>   - Changed the path expressions in the sysfs documentation to
> replace the n3000 reference with something more generic to
> accomodate other devices that use the same driver.
> v9:
>   - Rebased to 5.12-rc2 next
>   - Updated Date and KernelVersion in ABI documentation
> v8:
>   - Previously patch 4/6, otherwise no change
> v7:
>   - Updated Date and KernelVersion in ABI documentation
> v6:
>   - Added WARN_ON() call for (size / stride) to ensure
> that the proper count is passed to regmap_bulk_read().
> v5:
>   - No change
> v4:
>   - Moved sysfs files for displaying the code-signing-key (CSK)
> cancellation vectors from the FPGA Security Manger class driver
> to here. The m10bmc_csk_vector() and m10bmc_csk_cancel_nbits()
> functions are removed and the functionality from these functions
> is moved into a show_canceled_csk() function for for displaying
> the CSK vectors.
>   - Added ABI documentation for new sysfs entries
> v3:
>   - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_
>   - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure Update
> driver"
>   - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The
> underlying functions are now called directly.
>   - Renamed get_csk_vector() to m10bmc_csk_vector()
> v2:
>   - Replaced small function-creation macros for explicit function
> declarations.
>   - Fixed get_csk_vector() function to properly apply the stride
> variable in calls to m10bmc_raw_bulk_read()
>   - Added m10bmc_ prefix to functions in m10bmc_iops structure
> ---
>  .../testing/sysfs-driver-intel-m10-bmc-secure | 24 ++
>  drivers/fpga/intel-m10-bmc-secure.c   | 48 +++
>  2 files changed, 72 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure 
> b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
> index 598db1116d34..93ad4de9b941 100644
> --- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
> +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
> @@ -28,6 +28,30 @@ Description:   Read only. Returns the root entry hash 
> for the BMC image
>       underlying device supports it.
>   Format: "0x%x".
>  
> +What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/sr_canceled_csks

This is fine.

Reviewed-by: Tom Rix 

> +Date:April 2021
> +KernelVersion:  5.13
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the static region. The standard bitmap
> + list format is used (e.g. "1,2-6,9").
> +
> +What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/pr_canceled_csks
> +Date:April 2021
> +KernelVersion:  5.13
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the partial reconfiguration region. The
> + standard bitmap list format is used (e.g. "1,2-6,9").
> +
> +What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/bmc_canceled_csks
> +Date:April 2021
> +KernelVersion:  5.13
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the BMC.  The standard bitmap list format
> + is used (e.g. "1,2-6,9").
> +
>  What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/flash_count
>  Date:April 2021
>  KernelVersion:  5.13
> diff --git a/drivers/fpga/intel-m10-bmc-secure.c 
> b/drivers/fpga/intel-m10-bmc-secure.c
> index ecd63c13cb2d..87e16c146569 100644
> --- a/drivers/fpga/intel-m10-bmc-secure.c
> +++ b/drivers/fpga/intel-m10-bmc-secure.c
> @@ -79,6 +79,51 @@ DEVICE_ATTR_SEC_REH_RO(bmc, BMC_PROG_MAGIC, BMC_PROG_ADDR, 
> BMC_REH_ADDR);
>  DEVICE_ATTR_SEC_REH_RO(sr, SR_PROG_MAGIC, SR_PROG_ADDR, SR_REH_ADDR);
>  DEVICE_ATTR_SEC_REH_RO(pr, PR_PROG_MAGIC, PR_PROG_ADDR, PR_REH_ADDR);
>  
> +#define CSK_BIT_LEN  128U
> +#define CSK_32ARRAY_SIZE DIV_ROUND_UP(CSK_BIT_LEN, 32)
> +
> +static ssize_t
> +show_canceled_csk(struct device *dev, u32 addr, char *buf)

Re: [PATCH v10 1/5] fpga: m10bmc-sec: create max10 bmc secure update driver

[Tom Rix]

On 3/12/21 11:36 AM, Russ Weight wrote:
> Create a platform driver that can be invoked as a sub
> driver for the Intel MAX10 BMC in order to support
> secure updates. This sub-driver will invoke an
> instance of the FPGA Security Manager class driver
> in order to expose sysfs interfaces for managing and
> monitoring secure updates to FPGA and BMC images.
>
> This patch creates the MAX10 BMC Secure Update driver and
> provides sysfs files for displaying the current root entry hashes
> for the FPGA static region, the FPGA PR region, and the MAX10
> BMC.
>
> Signed-off-by: Russ Weight 
> ---
> v10:
>   - Changed the path expressions in the sysfs documentation to
> replace the n3000 reference with something more generic to
> accomodate other devices that use the same driver.
> v9:
>   - Rebased to 5.12-rc2 next
>   - Updated Date and KernelVersion in ABI documentation
> v8:
>   - Previously patch 2/6, otherwise no change
> v7:
>   - Updated Date and KernelVersion in ABI documentation
> v6:
>   - Added WARN_ON() call for (sha_num_bytes / stride) to assert
> that the proper count is passed to regmap_bulk_read().
> v5:
>   - No change
> v4:
>   - Moved sysfs files for displaying the root entry hashes (REH)
> from the FPGA Security Manager class driver to here. The
> m10bmc_reh() and m10bmc_reh_size() functions are removed and
> the functionality from these functions is moved into a
> show_root_entry_hash() function for displaying the REHs.
>   - Added ABI documentation for the new sysfs entries:
> sysfs-driver-intel-m10-bmc-secure
>   - Updated the MAINTAINERS file to add the new ABI documentation
> file: sysfs-driver-intel-m10-bmc-secure
>   - Removed unnecessary ret variable from m10bmc_secure_probe()
>   - Incorporated new devm_fpga_sec_mgr_register() function into
> m10bmc_secure_probe() and removed the m10bmc_secure_remove()
> function.
> v3:
>   - Changed from "Intel FPGA Security Manager" to FPGA Security Manager"
>   - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_
>   - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure
> Update driver"
>   - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The
> underlying functions are now called directly.
>   - Changed "_root_entry_hash" to "_reh", with a comment explaining
> what reh is.
> v2:
>   - Added drivers/fpga/intel-m10-bmc-secure.c file to MAINTAINERS.
>   - Switched to GENMASK(31, 16) for a couple of mask definitions.
>   - Moved MAX10 BMC address and function definitions to a separate
> patch.
>   - Replaced small function-creation macros with explicit function
> declarations.
>   - Removed ifpga_sec_mgr_init() and ifpga_sec_mgr_uinit() functions.
>   - Adapted to changes in the Intel FPGA Security Manager by splitting
> the single call to ifpga_sec_mgr_register() into two function
> calls: devm_ifpga_sec_mgr_create() and ifpga_sec_mgr_register().
> ---
>  .../testing/sysfs-driver-intel-m10-bmc-secure |  29 
>  MAINTAINERS   |   2 +
>  drivers/fpga/Kconfig  |  11 ++
>  drivers/fpga/Makefile |   3 +
>  drivers/fpga/intel-m10-bmc-secure.c   | 135 ++
>  5 files changed, 180 insertions(+)
>  create mode 100644 
> Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
>  create mode 100644 drivers/fpga/intel-m10-bmc-secure.c
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure 
> b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
> new file mode 100644
> index ..bd3ee9bc1a92
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
> @@ -0,0 +1,29 @@
> +What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/sr_root_entry_hash

This is fine.

Reviewed-by: Tom Rix 

> +Date:April 2021
> +KernelVersion:  5.13
> +Contact: Russ Weight 
> +Description: Read only. Returns the root entry hash for the static
> + region if one is programmed, else it returns the
> + string: "hash not programmed".  This file is only
> + visible if the underlying device supports it.
> + Format: "0x%x".
> +
> +What:
> /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/pr_root_entry_hash
> +Date:April 2021
> +KernelVersion:  5.13
> +Contact: Russ Weight 
> +Description: Read only. Returns the root entry hash for the partial
> + reconfiguration region if one is prog

Re: [PATCH v3 00/15] arm64 / clk: socfpga: simplifying, cleanups and compile testing

[Tom Rix]

On 3/11/21 7:25 AM, Krzysztof Kozlowski wrote:
> Hi,
>
> All three Intel arm64 SoCFPGA architectures (Agilex, N5X and Stratix 10)
> are basically flavors/platforms of the same architecture.  At least from
> the Linux point of view.  Up to a point that N5X and Agilex share DTSI.
> Having three top-level architectures for the same one barely makes
> sense and complicates driver selection.
>
> Additionally it was pointed out that ARCH_SOCFPGA name is too generic.
> There are other vendors making SoC+FPGA designs, so the name should be
> changed to have real vendor (currently: Intel).
>
>
> Dependencies / merging
> ==
> 1. Patch 1 is used as base, so other changes depend on its hunks.
>I put it at beginning as it is something close to a fix, so candidate
>for stable (even though I did not mark it like that).
> 2. Patch 2: everything depends on it.
>
> 3. 64-bit path:
> 3a. Patches 3-7: depend on patch 2, from 64-bit point of view.
> 3b. Patch 8: depends on 2-7 as it finally removes 64-bit ARCH_XXX
> symbols.
>
> 4. 32-bit path:
> 4a. Patches 9-14: depend on 2, from 32-bit point of view.
> 4b. Patch 15: depends on 9-14 as it finally removes 32-bit ARCH_SOCFPGA
> symbol.
>
> If the patches look good, proposed merging is via SoC tree (after
> getting acks from everyone). Sharing immutable branches is also a way.
>
>
> Changes since v2
> 
> 1. Several new patches and changes.
> 2. Rename ARCH_SOCFPGA to ARCH_INTEL_SOCFPGA on 32-bit and 64-bit.
> 3. Enable compile testing of 32-bit socfpga clock drivers.
> 4. Split changes per subsystems for easier review.
> 5. I already received an ack from Lee Jones, but I did not add it as
>there was big refactoring.  Please kindly ack one more time if it
>looks good.
>
> Changes since v1
> 
> 1. New patch 3: arm64: socfpga: rename ARCH_STRATIX10 to ARCH_SOCFPGA64.
> 2. New patch 4: arm64: intel: merge Agilex and N5X into ARCH_SOCFPGA64.
> 3. Fix build is.sue reported by kernel test robot (with ARCH_STRATIX10
>and COMPILE_TEST but without selecting some of the clocks).
>
>
> RFT
> ===
> I tested compile builds on few configurations, so I hope kbuild 0-day
> will check more options (please give it few days on the lists).
> I compare the generated autoconf.h and found no issues.  Testing on real
> hardware would be appreciated.
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (15):
>   clk: socfpga: allow building N5X clocks with ARCH_N5X
>   ARM: socfpga: introduce common ARCH_INTEL_SOCFPGA
>   mfd: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10
>   net: stmmac: merge ARCH_SOCFPGA and ARCH_STRATIX10
>   clk: socfpga: build together Stratix 10, Agilex and N5X clock drivers
>   clk: socfpga: merge ARCH_SOCFPGA and ARCH_STRATIX10
>   EDAC: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10
>   arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGA
>   clk: socfpga: allow compile testing of Stratix 10 / Agilex clocks
>   clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and
> compile test)
>   dmaengine: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
>   fpga: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
>   i2c: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
>   reset: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
>   ARM: socfpga: drop ARCH_SOCFPGA
>
>  arch/arm/Kconfig|  2 +-
>  arch/arm/Kconfig.debug  |  6 +++---
>  arch/arm/Makefile   |  2 +-
>  arch/arm/boot/dts/Makefile  |  2 +-
>  arch/arm/configs/multi_v7_defconfig |  2 +-
>  arch/arm/configs/socfpga_defconfig  |  2 +-
>  arch/arm/mach-socfpga/Kconfig   |  4 ++--
>  arch/arm64/Kconfig.platforms| 17 -
>  arch/arm64/boot/dts/altera/Makefile |  2 +-
>  arch/arm64/boot/dts/intel/Makefile  |  6 +++---
>  arch/arm64/configs/defconfig|  3 +--
>  drivers/clk/Kconfig |  1 +
>  drivers/clk/Makefile|  4 +---
>  drivers/clk/socfpga/Kconfig | 19 +++
>  drivers/clk/socfpga/Makefile| 11 +--
>  drivers/dma/Kconfig |  2 +-
>  drivers/edac/Kconfig|  2 +-
>  drivers/edac/altera_edac.c  | 17 +++--
>  drivers/firmware/Kconfig|  2 +-
>  drivers/fpga/Kconfig|  8 
>  drivers/i2c/busses/Kconfig  |  2 +-
>  drivers/mfd/Kconfig |  4 ++--
>  drivers/net/ethernet/stmicro/stmmac/Kconfig |  4 ++--
>  drivers/reset/Kconfig   |  6 +++---
>  24 files changed, 71 insertions(+), 59 deletions(-)
>  create mode 100644 drivers/clk/socfpga/Kconfig
>
Thanks for changing the config name.

Please review checkpatch --strict on this set, the typical complaint is

Re: [PATCH v10 0/7] FPGA Security Manager Class Driver

[Tom Rix]

On 3/9/21 6:51 PM, Moritz Fischer wrote:
> Hi Tom,
> On Tue, Mar 09, 2021 at 08:03:09AM -0800, Tom Rix wrote:
>> Moritz,
>>
>> This and the next patchset apply to today's char-misc-next.
>>
>> However they conflicts with other in flight linux-fpga patchsets.
>>
>> Since I believe these patchsets came first, I think they should have 
>> preference.
> I'm not sure what the ask here is, do you expect me to back out the
> applied patches?
>
> Conflicts will happen, it's part of working with git.

When I say in-flight, I mean yet to be accepted patches.

I track these here

https://github.com/trixirt/linux-fpga/tree/fpga-testing


I am sure everyone wants their patch in 5.13, I am plugging for these because 
they are oldest and most useful.

This is an old patchset, from the changelog in this patchset it has been 
rebased for the last 2 releases without change.

AFAIK, the dfl fpga's bitstream can not be updated with the mainline kernel 
without these patches.

Since updating is why you would use an fpga, this is an important feature.


While I am plugging for 5.13

A fix for dfl port enable logic

https://lore.kernel.org/linux-fpga/20210303014543.68292-1-russell.h.wei...@intel.com/

A patchset with a fix for stable

https://lore.kernel.org/linux-fpga/8fe75a64-0457-16ac-5049-ee8b756ae...@linux.intel.com/

Tom

>> This feature of updating is needed for the basic operation of the fpga.
>>
>> Tom
>>
>> On 3/8/21 4:35 PM, Russ Weight wrote:
>>> The FPGA Security Manager class driver provides a common
>>> API for user-space tools to manage updates for secure FPGA
>>> devices. Device drivers that instantiate the FPGA Security
>>> Manager class driver will interact with a 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.
>>>
>>> A significant difference between the FPGA Manager and the FPGA 
>>> Security Manager is that the FPGA Manager does a live update (Partial
>>> Reconfiguration) to a device whereas the FPGA Security Manager
>>> updates the FLASH images for the Static Region and the BMC so that
>>> they will be loaded the next time the FPGA card boots. Security is
>>> enforced by hardware and firmware. The security manager interacts
>>> with the firmware to initiate an update, pass in the necessary data,
>>> and collect status on the update.
>>>
>>> The n3000bmc-secure driver is the first driver to use the FPGA
>>> Security Manager. This driver was previously submitted in the same
>>> patch set, but has been split out into a separate patch set starting
>>> with V2. Future devices will also make use of this common API for
>>> secure updates.
>>>
>>> In addition to managing secure updates of the FPGA and BMC images,
>>> the FPGA Security Manager update process may also be used to
>>> program root entry hashes and cancellation keys for the FPGA static
>>> region, the FPGA partial reconfiguration region, and the BMC.
>>> The image files are self-describing, and contain a header describing
>>> the image type.
>>>
>>> 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.
>>>
>>> The API includes a "name" sysfs file to export the name of the parent
>>> driver. It also includes an "update" sub-directory containing files that
>>> that can be used to instantiate and monitor a secure update.
>>>
>>> Changelog v9 -> v10:
>>>   - Rebased to 5.12-rc2 next
>>>   - Updated Date and KernelVersion in ABI documentation
>>>
>>> Changelog v8 -> v9:
>>>   - Rebased patches for 5.11-rc2
>>>   - Updated Date and KernelVersion in ABI documentation
>>>
>>> Changelog v7 -> v8:
>>>   - Fixed grammatical error in Documentation/fpga/fpga-sec-mgr.rst
>>>
>>> Changelog v6 -> v7:
>>>   - Changed dates in documentation file to December 2020
>>>   - Changed filename_store() to use kmemdup_nul() instead of
>>> kstrndup() and changed the count to not assume a line-return.
>>>
>>> Changelog v5 -> v6:
>>>   - Removed sysfs support an

Re: [RFC v2 3/5] arm64: socfpga: rename ARCH_STRATIX10 to ARCH_SOCFPGA64

[Tom Rix]

On 3/10/21 1:45 AM, Lee Jones wrote:
> On Wed, 10 Mar 2021, Krzysztof Kozlowski wrote:
>
>> Prepare for merging Stratix 10, Agilex and N5X into one arm64
>> architecture by first renaming the ARCH_STRATIX10 into ARCH_SOCFPGA64.
>>
>> The existing ARCH_SOCFPGA (in ARMv7) Kconfig symbol cannot be used
>> because altera_edac driver builds differently between them (with
>> ifdefs).
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm64/Kconfig.platforms|  7 ---
>>  arch/arm64/boot/dts/altera/Makefile |  2 +-
>>  arch/arm64/configs/defconfig|  2 +-
>>  drivers/clk/Makefile|  2 +-
>>  drivers/clk/socfpga/Kconfig |  4 ++--
>>  drivers/edac/Kconfig|  2 +-
>>  drivers/edac/altera_edac.c  | 10 +-
>>  drivers/firmware/Kconfig|  2 +-
>>  drivers/fpga/Kconfig|  2 +-
>>  drivers/mfd/Kconfig |  2 +-
> If it's okay with everyone else, it'll be okay with me:
>
> Acked-by: Lee Jones 

I think the name is too broad, from the description in the config

+   bool "Intel's SoCFPGA ARMv8 Families"

A better name would be ARCH_INTEL_SOCFPGA64

So other vendors like Xilinx could do their own thing.

Tom

>
>>  drivers/net/ethernet/stmicro/stmmac/Kconfig |  4 ++--
>>  drivers/reset/Kconfig   |  2 +-
>>  12 files changed, 21 insertions(+), 20 deletions(-)

Re: [PATCH v10 0/7] FPGA Security Manager Class Driver

[Tom Rix]

Moritz,

This and the next patchset apply to today's char-misc-next.

However they conflicts with other in flight linux-fpga patchsets.

Since I believe these patchsets came first, I think they should have preference.

This feature of updating is needed for the basic operation of the fpga.

Tom

On 3/8/21 4:35 PM, Russ Weight wrote:
> The FPGA Security Manager class driver provides a common
> API for user-space tools to manage updates for secure FPGA
> devices. Device drivers that instantiate the FPGA Security
> Manager class driver will interact with a 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.
>
> A significant difference between the FPGA Manager and the FPGA 
> Security Manager is that the FPGA Manager does a live update (Partial
> Reconfiguration) to a device whereas the FPGA Security Manager
> updates the FLASH images for the Static Region and the BMC so that
> they will be loaded the next time the FPGA card boots. Security is
> enforced by hardware and firmware. The security manager interacts
> with the firmware to initiate an update, pass in the necessary data,
> and collect status on the update.
>
> The n3000bmc-secure driver is the first driver to use the FPGA
> Security Manager. This driver was previously submitted in the same
> patch set, but has been split out into a separate patch set starting
> with V2. Future devices will also make use of this common API for
> secure updates.
>
> In addition to managing secure updates of the FPGA and BMC images,
> the FPGA Security Manager update process may also be used to
> program root entry hashes and cancellation keys for the FPGA static
> region, the FPGA partial reconfiguration region, and the BMC.
> The image files are self-describing, and contain a header describing
> the image type.
>
> 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.
>
> The API includes a "name" sysfs file to export the name of the parent
> driver. It also includes an "update" sub-directory containing files that
> that can be used to instantiate and monitor a secure update.
>
> Changelog v9 -> v10:
>   - Rebased to 5.12-rc2 next
>   - Updated Date and KernelVersion in ABI documentation
>
> Changelog v8 -> v9:
>   - Rebased patches for 5.11-rc2
>   - Updated Date and KernelVersion in ABI documentation
>
> Changelog v7 -> v8:
>   - Fixed grammatical error in Documentation/fpga/fpga-sec-mgr.rst
>
> Changelog v6 -> v7:
>   - Changed dates in documentation file to December 2020
>   - Changed filename_store() to use kmemdup_nul() instead of
> kstrndup() and changed the count to not assume a line-return.
>
> Changelog v5 -> v6:
>   - Removed sysfs support and documentation for the display of the
> flash count, root entry hashes, and code-signing-key cancelation
> vectors from the class driver. This information can vary by device
> and will instead be displayed by the device-specific parent driver.
>
> Changelog v4 -> v5:
>   - Added the devm_fpga_sec_mgr_unregister() function, following recent
> changes to the fpga_manager() implementation.
>   - Changed most of the *_show() functions to use sysfs_emit()
> instead of sprintf(
>   - When checking the return values for functions of type enum
> fpga_sec_err err_code, test for FPGA_SEC_ERR_NONE instead of 0
>
> Changelog v3 -> v4:
>   - This driver is generic enough that it could be used for non Intel
> FPGA devices. Changed from "Intel FPGA Security Manager" to FPGA
> Security Manager" and removed unnecessary references to "Intel".
>   - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_
> Note that this also affects some filenames.
>
> Changelog v2 -> v3:
>   - Use dev_err() to report invalid progress in sec_progress()
>   - Use dev_err() to report invalid error code in sec_error()
>   - Modified sysfs handler check in check_sysfs_handler() to make
> it more readable.
>   - Removed unnecessary "goto done"
>   - Added a comment to explain imgr->driver_unload in
> ifpga_sec_mgr_unregister()
>
> Changelog v1 -> v2:
>   - Separated out the MAX10 BMC Security Engine to be submitted in
> a separate patch-set.
>   - Bumped documentation dates and versions
>   - Split ifpga_sec_mgr_register() into create() and register() functions
>   - Added devm_ifpga_sec_mgr_create()
>   - Added Documentation/fpga/ifpga-sec-mgr.rst 
>   - Changed progress state "read_file" to "reading"
>   - Added sec_error() function (similar to sec_progress())
>   - Removed references to bmc_flash_count & smbus_flash_count (not supported)
>   - 

Re: [PATCH V3 XRT Alveo 17/18] fpga: xrt: partition isolation platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add partition isolation platform driver. partition isolation is
> a hardware function discovered by walking firmware metadata.
> A platform device node will be created for it. Partition isolation
> function isolate the different fpga regions
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/axigate.h |  25 ++
>  drivers/fpga/xrt/lib/xleaf/axigate.c | 298 +++
>  2 files changed, 323 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/axigate.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/axigate.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/axigate.h 
> b/drivers/fpga/xrt/include/xleaf/axigate.h
> new file mode 100644
> index ..2cef71e13b30
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/axigate.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT Axigate Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_AXIGATE_H_
> +#define _XRT_AXIGATE_H_
> +
> +#include "xleaf.h"
> +#include "metadata.h"
> +
> +/*
> + * AXIGATE driver IOCTL calls.
> + */
> +enum xrt_axigate_ioctl_cmd {
> + XRT_AXIGATE_FREEZE = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h 
> */
> + XRT_AXIGATE_FREE,
These are substrings, could change suffix to make it harder for developer to 
mix up.
> +};
> +
> +#endif   /* _XRT_AXIGATE_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/axigate.c 
> b/drivers/fpga/xrt/lib/xleaf/axigate.c
> new file mode 100644
> index ..382969f9925f
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/axigate.c
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA AXI Gate Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/axigate.h"
> +
> +#define XRT_AXIGATE "xrt_axigate"
> +
> +struct axigate_regs {
> + u32 iag_wr;
> + u32 iag_rvsd;
> + u32 iag_rd;
> +} __packed;
similar to other patches, prefix of element is not needed.
> +
> +struct xrt_axigate {
> + struct platform_device  *pdev;
> + void*base;
> + struct mutexgate_lock; /* gate dev lock */
> +
> + void*evt_hdl;
> + const char  *ep_name;
> +
> + boolgate_freezed;
> +};
> +
> +/* the ep names are in the order of hardware layers */
> +static const char * const xrt_axigate_epnames[] = {
> + XRT_MD_NODE_GATE_PLP,
> + XRT_MD_NODE_GATE_ULP,
what are plp, ulp ? it is helpful to comment or expand acronyms
> + NULL
> +};
> +
> +#define reg_rd(g, r) \
> + ioread32((void *)(g)->base + offsetof(struct axigate_regs, r))
> +#define reg_wr(g, v, r)  \
> + iowrite32(v, (void *)(g)->base + offsetof(struct axigate_regs, r))
> +
> +static inline void freeze_gate(struct xrt_axigate *gate)
> +{
> + reg_wr(gate, 0, iag_wr);
The values written here and below are magic, the need to have #defines
> + ndelay(500);
> + reg_rd(gate, iag_rd);
> +}
> +
> +static inline void free_gate(struct xrt_axigate *gate)
> +{
> + reg_wr(gate, 0x2, iag_wr);
> + ndelay(500);
> + (void)reg_rd(gate, iag_rd);
> + reg_wr(gate, 0x3, iag_wr);
> + ndelay(500);
> + reg_rd(gate, iag_rd);
> +}
> +
> +static int xrt_axigate_epname_idx(struct platform_device *pdev)
> +{
> + int i;
> + int ret;
int i, ret;
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + xrt_err(pdev, "Empty Resource!");
> + return -EINVAL;
> + }
> +
> + for (i = 0; xrt_axigate_epnames[i]; i++) {

null guarded array is useful with the size isn't know,

in this case it is, so covert loop to using ARRAY_SIZE

> + ret = strncmp(xrt_axigate_epnames[i], res->name,
> +   strlen(xrt_axigate_epnames[i]) + 1);
needs a strlen check in case res->name is just a substring
> + if (!ret)
> + break;
> + }
> +
> + ret = (xrt_axigate_epnames[i]) ? i : -EINVAL;
> + return ret;
> +}
> +
> +static void xrt_axigate_freeze(struct platform_device *pdev)
> +{
> + struct xrt_axigate  *gate;
> + u32 freeze = 0;
> +
> + gate = platform_get_drvdata(pdev);
> +
> + mutex_lock(>gate_lock);
> + freeze = reg_rd(gate, iag_rd);
> + if (freeze) {   /* gate is opened */
> + xleaf_broadcast_event(pdev, XRT_EVENT_PRE_GATE_CLOSE, false);
> + 

Re: [PATCH V3 XRT Alveo 16/18] fpga: xrt: DDR calibration platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add DDR calibration driver. DDR calibration is a hardware function
> discovered by walking firmware metadata. A platform device node will
> be created for it. Hardware provides DDR calibration status through
> this function.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/calib.h |  30 
>  drivers/fpga/xrt/lib/xleaf/calib.c | 226 +
>  2 files changed, 256 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/calib.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/calib.c
calib is not descriptive, change filename to ddr_calibration
>
> diff --git a/drivers/fpga/xrt/include/xleaf/calib.h 
> b/drivers/fpga/xrt/include/xleaf/calib.h
> new file mode 100644
> index ..f8aba4594c58
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/calib.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT DDR Calibration Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_CALIB_H_
> +#define _XRT_CALIB_H_
> +
> +#include "xleaf.h"
> +#include 
> +
> +/*
> + * Memory calibration driver IOCTL calls.
> + */
> +enum xrt_calib_results {
> + XRT_CALIB_UNKNOWN,
Initialize ?
> + XRT_CALIB_SUCCEEDED,
> + XRT_CALIB_FAILED,
> +};
> +
> +enum xrt_calib_ioctl_cmd {
> + XRT_CALIB_RESULT = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
> +};
> +
> +#endif   /* _XRT_CALIB_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/calib.c 
> b/drivers/fpga/xrt/lib/xleaf/calib.c
> new file mode 100644
> index ..fbb813636e76
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/calib.c
> @@ -0,0 +1,226 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA memory calibration driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * memory calibration
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +#include 
> +#include "xclbin-helper.h"
> +#include "metadata.h"
> +#include "xleaf/calib.h"
> +
> +#define XRT_CALIB"xrt_calib"
> +
> +struct calib_cache {
> + struct list_headlink;
> + const char  *ep_name;
> + char*data;
> + u32 data_size;
> +};
> +
> +struct calib {
> + struct platform_device  *pdev;
> + void*calib_base;
> + struct mutexlock; /* calibration dev lock */
> + struct list_headcache_list;
> + u32 cache_num;
> + enum xrt_calib_results  result;
> +};
> +
> +#define CALIB_DONE(calib)\
> + (ioread32((calib)->calib_base) & BIT(0))
> +
> +static void calib_cache_clean_nolock(struct calib *calib)
> +{
> + struct calib_cache *cache, *temp;
> +
> + list_for_each_entry_safe(cache, temp, >cache_list, link) {
> + vfree(cache->data);
> + list_del(>link);
> + vfree(cache);
> + }
> + calib->cache_num = 0;
> +}
> +
> +static void calib_cache_clean(struct calib *calib)
> +{
> + mutex_lock(>lock);
> + calib_cache_clean_nolock(calib);
No lock functions (i believe) should be prefixed with '__'
> + mutex_unlock(>lock);
> +}
> +
> +static int calib_srsr(struct calib *calib, struct platform_device *srsr_leaf)

what is srsr ?

Why a noop function ?

> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int calib_calibration(struct calib *calib)
> +{
> + int i;
> +
> + for (i = 0; i < 20; i++) {

20 is a config parameter so should have a #define

There a couple of busy wait blocks in xrt/ some count up, some count down.

It would be good if they were consistent.

> + if (CALIB_DONE(calib))
> + break;
> + msleep(500);

500 is another config

Tom

> + }
> +
> + if (i == 20) {
> + xrt_err(calib->pdev,
> + "MIG calibration timeout after bitstream download");
> + return -ETIMEDOUT;
> + }
> +
> + xrt_info(calib->pdev, "took %dms", i * 500);
> + return 0;
> +}
> +
> +static void xrt_calib_event_cb(struct platform_device *pdev, void *arg)
> +{
> + struct calib *calib = platform_get_drvdata(pdev);
> + struct xrt_event *evt = (struct xrt_event *)arg;
> + enum xrt_events e = evt->xe_evt;
> + enum xrt_subdev_id id = evt->xe_subdev.xevt_subdev_id;
> + int instance = evt->xe_subdev.xevt_subdev_instance;
> + struct platform_device *leaf;
> + int ret;
> +
> + switch (e) {
> + case XRT_EVENT_POST_CREATION: {
> + if (id == XRT_SUBDEV_SRSR) {
> + leaf = xleaf_get_leaf_by_id(pdev,
> + XRT_SUBDEV_SRSR,
> + instance);
> + if (!leaf) {
> + xrt_err(pdev, "does 

Re: [PATCH V3 XRT Alveo 15/18] fpga: xrt: clock frequence counter platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add clock frequence counter driver. Clock frequence counter is
> a hardware function discovered by walking xclbin metadata. A platform
> device node will be created for it. Other part of driver can read the
> actual clock frequence through clock frequence counter driver.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/clkfreq.h |  23 +++
>  drivers/fpga/xrt/lib/xleaf/clkfreq.c | 221 +++
>  2 files changed, 244 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/clkfreq.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/clkfreq.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/clkfreq.h 
> b/drivers/fpga/xrt/include/xleaf/clkfreq.h
> new file mode 100644
> index ..29fc45e8a31b
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/clkfreq.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT Clock Counter Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_CLKFREQ_H_
> +#define _XRT_CLKFREQ_H_
> +
> +#include "xleaf.h"
> +
> +/*
> + * CLKFREQ driver IOCTL calls.
> + */
> +enum xrt_clkfreq_ioctl_cmd {
> + XRT_CLKFREQ_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
> +};
> +
> +#endif   /* _XRT_CLKFREQ_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/clkfreq.c 
> b/drivers/fpga/xrt/lib/xleaf/clkfreq.c
> new file mode 100644
> index ..2482dd2cff47
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/clkfreq.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Clock Frequency Counter Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/clkfreq.h"
> +
> +#define CLKFREQ_ERR(clkfreq, fmt, arg...)   \
> + xrt_err((clkfreq)->pdev, fmt "\n", ##arg)
> +#define CLKFREQ_WARN(clkfreq, fmt, arg...)  \
> + xrt_warn((clkfreq)->pdev, fmt "\n", ##arg)
> +#define CLKFREQ_INFO(clkfreq, fmt, arg...)  \
> + xrt_info((clkfreq)->pdev, fmt "\n", ##arg)
> +#define CLKFREQ_DBG(clkfreq, fmt, arg...)   \
> + xrt_dbg((clkfreq)->pdev, fmt "\n", ##arg)
> +
> +#define XRT_CLKFREQ  "xrt_clkfreq"
> +
> +#define OCL_CLKWIZ_STATUS_MASK   0x
> +
> +#define OCL_CLKWIZ_STATUS_MEASURE_START  0x1
> +#define OCL_CLKWIZ_STATUS_MEASURE_DONE   0x2
> +#define OCL_CLK_FREQ_COUNTER_OFFSET  0x8
> +#define OCL_CLK_FREQ_V5_COUNTER_OFFSET   0x10
> +#define OCL_CLK_FREQ_V5_CLK0_ENABLED 0x1

Similar to earlier, OCL -> XRT_CLKFREQ

Use regmap

> +
> +struct clkfreq {
> + struct platform_device  *pdev;
> + void __iomem*clkfreq_base;
> + const char  *clkfreq_ep_name;
> + struct mutexclkfreq_lock; /* clock counter dev lock */
> +};
> +
> +static inline u32 reg_rd(struct clkfreq *clkfreq, u32 offset)
> +{
> + return ioread32(clkfreq->clkfreq_base + offset);
> +}
> +
> +static inline void reg_wr(struct clkfreq *clkfreq, u32 val, u32 offset)
> +{
> + iowrite32(val, clkfreq->clkfreq_base + offset);
> +}
> +
> +static u32 clkfreq_read(struct clkfreq *clkfreq)
> +{

failure returns 0, it would be better if -EINVAL or similar was returned.

and u32 *freq added as a function parameter

> + u32 freq = 0, status;
> + int times = 10;
10 is a config parameter, should be a #define
> +
> + mutex_lock(>clkfreq_lock);
> + reg_wr(clkfreq, OCL_CLKWIZ_STATUS_MEASURE_START, 0);
> + while (times != 0) {
> + status = reg_rd(clkfreq, 0);
> + if ((status & OCL_CLKWIZ_STATUS_MASK) ==
> + OCL_CLKWIZ_STATUS_MEASURE_DONE)
> + break;
> + mdelay(1);
> + times--;
> + };
> + if (times > 0) {
I do not like tristate setting, convert to if-else
> + freq = (status & OCL_CLK_FREQ_V5_CLK0_ENABLED) ?
> + reg_rd(clkfreq, OCL_CLK_FREQ_V5_COUNTER_OFFSET) :
> + reg_rd(clkfreq, OCL_CLK_FREQ_COUNTER_OFFSET);
> + }
> + mutex_unlock(>clkfreq_lock);
> +
> + return freq;
> +}
> +
> +static ssize_t freq_show(struct device *dev, struct device_attribute *attr, 
> char *buf)
> +{
> + struct clkfreq *clkfreq = platform_get_drvdata(to_platform_device(dev));
> + u32 freq;
> + ssize_t count;
> +
> + freq = clkfreq_read(clkfreq);
unchecked error
> + count = snprintf(buf, 64, "%d\n", freq);
%u
> +
> + return count;
> +}
> +static DEVICE_ATTR_RO(freq);
> +
> +static struct attribute *clkfreq_attrs[] = {
> + _attr_freq.attr,
> + NULL,
> +};
> +
> +static struct attribute_group clkfreq_attr_group = {
> + .attrs = clkfreq_attrs,
> +};
> +
> +static int
> 

Re: [PATCH V3 XRT Alveo 14/18] fpga: xrt: clock platform driver

[Tom Rix]

why are clock and clkfeq separated ?

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add clock driver. Clock is a hardware function discovered by walking
> xclbin metadata. A platform device node will be created for it. Other
> part of driver configures clock through clock driver.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/clock.h |  31 ++
>  drivers/fpga/xrt/lib/xleaf/clock.c | 648 +
>  2 files changed, 679 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/clock.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/clock.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/clock.h 
> b/drivers/fpga/xrt/include/xleaf/clock.h
> new file mode 100644
> index ..a2da59b32551
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/clock.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT Clock Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_CLOCK_H_
> +#define _XRT_CLOCK_H_
> +
> +#include "xleaf.h"
> +#include 
> +
> +/*
> + * CLOCK driver IOCTL calls.
> + */
> +enum xrt_clock_ioctl_cmd {
> + XRT_CLOCK_SET = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
> + XRT_CLOCK_GET,
> + XRT_CLOCK_VERIFY,
> +};
> +
> +struct xrt_clock_ioctl_get {
> + u16 freq;
> + u32 freq_cnter;
> +};
> +
> +#endif   /* _XRT_CLOCK_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/clock.c 
> b/drivers/fpga/xrt/lib/xleaf/clock.c
> new file mode 100644
> index ..a067b501a607
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/clock.c
> @@ -0,0 +1,648 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Clock Wizard Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + *  Sonal Santan 
> + *  David Zhang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/clock.h"
> +#include "xleaf/clkfreq.h"
> +
> +/* CLOCK_MAX_NUM_CLOCKS should be a concept from XCLBIN_ in the future */
> +#define CLOCK_MAX_NUM_CLOCKS 4
> +#define OCL_CLKWIZ_STATUS_OFFSET 0x4
OCL_CLKWIZ does not match the name of this file, change to something like 
XRT_CLOCK
> +#define OCL_CLKWIZ_STATUS_MASK   0x
> +#define OCL_CLKWIZ_STATUS_MEASURE_START  0x1
> +#define OCL_CLKWIZ_STATUS_MEASURE_DONE   0x2
> +#define OCL_CLKWIZ_CONFIG_OFFSET(n)  (0x200 + 4 * (n))

This should be expanded to logical names of the registers.

It's use below has a magic indexes.

> +#define CLOCK_DEFAULT_EXPIRE_SECS1
> +
> +#define CLOCK_ERR(clock, fmt, arg...)\
> + xrt_err((clock)->pdev, fmt "\n", ##arg)
> +#define CLOCK_WARN(clock, fmt, arg...)   \
> + xrt_warn((clock)->pdev, fmt "\n", ##arg)
> +#define CLOCK_INFO(clock, fmt, arg...)   \
> + xrt_info((clock)->pdev, fmt "\n", ##arg)
> +#define CLOCK_DBG(clock, fmt, arg...)\
> + xrt_dbg((clock)->pdev, fmt "\n", ##arg)
> +
> +#define XRT_CLOCK"xrt_clock"
> +
> +struct clock {
> + struct platform_device  *pdev;
> + void __iomem*clock_base;
> + struct mutexclock_lock; /* clock dev lock */
> +
> + const char  *clock_ep_name;
> +};
> +
> +/*
> + * Precomputed table with config0 and config2 register values together with
> + * target frequency. The steps are approximately 5 MHz apart. Table is
> + * generated by wiz.pl.
where is wiz.pl ? include the script
> + */
> +static const struct xmgmt_ocl_clockwiz {
> + /* target frequency */
> + unsigned short ocl;
> + /* config0 register */
> + unsigned long config0;
Should be u32
> + /* config2 register */
> + unsigned int config2;
> +} frequency_table[] = {
> + {/*1275.000*/   10.000, 0x02EE0C01, 0x0001F47F},

Could clean up this table, to use spaces instead of tabs, move the comment out 
of branches

/* freq */ { ocl, config0, config2 },

> + {/*1575.000*/   15.000, 0x02EE0F01, 0x0069},
ocl is short, the data if float, change the generator output an integer
> + {/*1600.000*/   20.000, 0x1001, 0x0050},
> + {/*1600.000*/   25.000, 0x1001, 0x0040},
> + {/*1575.000*/   30.000, 0x02EE0F01, 0x0001F434},
> + {/*1575.000*/   35.000, 0x02EE0F01, 0x002D},
> + {/*1600.000*/   40.000, 0x1001, 0x0028},
> + {/*1575.000*/   45.000, 0x02EE0F01, 0x0023},
> + {/*1600.000*/   50.000, 0x1001, 0x0020},
> + {/*1512.500*/   55.000, 0x007D0F01, 0x0001F41B},
> + {/*1575.000*/   60.000, 0x02EE0F01, 0xFA1A},
> + {/*1462.500*/   65.000, 0x02710E01, 0x0001F416},
> + {/*1575.000*/   70.000, 

Re: [PATCH v2 1/2] dt-bindings: fpga: Add compatible value for Xilinx DFX AXI shutdown manager

[Tom Rix]

On 2/10/21 9:11 PM, Nava kishore Manne wrote:
> This patch Adds compatible value for Xilinx Dynamic Function eXchnage(DFX)
> AXI Shutdown manager IP.
>
> Signed-off-by: Nava kishore Manne 
> ---
> Changes for v2:
> -Modified the doc and added DFX axi shutdown manager node
>  example node as suggested by Tom Rix.
>
>  .../bindings/fpga/xilinx-pr-decoupler.txt | 24 ++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> index 4284d293fa61..0acdfa6d62a4 100644
> --- a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> @@ -7,13 +7,24 @@ changes from passing through the bridge.  The controller 
> can also
>  couple / enable the bridges which allows traffic to pass through the
>  bridge normally.
>  
> +Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager
> +Softcore is compatible with the Xilinx LogiCORE pr-decoupler.
> +
> +The Dynamic Function eXchange AXI shutdown manager prevents AXI traffic
> +from passing through the bridge. The controller safely handles AXI4MM
> +and AXI4-Lite interfaces on a Reconfigurable Partition when it is
> +undergoing dynamic reconfiguration, preventing the system deadlock
> +that can occur if AXI transactions are interrupted by DFX
> +
>  The Driver supports only MMIO handling. A PR region can have multiple
>  PR Decouplers which can be handled independently or chained via decouple/
>  decouple_status signals.
>  
>  Required properties:
>  - compatible : Should contain "xlnx,pr-decoupler-1.00" followed by
> -  "xlnx,pr-decoupler"
> +  "xlnx,pr-decoupler" or
> +  "xlnx,dfx-axi-shutdown-manager-1.00" followed by
> +  "xlnx,dfx-axi-shutdown-manager"
>  - regs   : base address and size for decoupler module
>  - clocks : input clock to IP
>  - clock-names: should contain "aclk"
> @@ -22,6 +33,7 @@ See Documentation/devicetree/bindings/fpga/fpga-region.txt 
> and
>  Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
>  
>  Example:
> +Partial Reconfig Decoupler:
>   fpga-bridge@10450 {
>   compatible = "xlnx,pr-decoupler-1.00",
>"xlnx-pr-decoupler";
> @@ -30,3 +42,13 @@ Example:
>   clock-names = "aclk";
>   bridge-enable = <0>;
>   };
> +
> +Dynamic Function eXchange AXI shutdown manager:
> + fpga-bridge@10450 {
> + compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
> +  "xlnx,dfx-axi-shutdown-manager";
> + regs = <0x1045 0x10>;
> + clocks = < 15>;
> + clock-names = "aclk";
> + bridge-enable = <0>;
> + };

Thanks for the example.

Reviewed-by: Tom Rix 

Re: [PATCH v2 2/2] fpga: Add support for Xilinx DFX AXI Shutdown manager

[Tom Rix]

On 2/10/21 9:11 PM, Nava kishore Manne wrote:
> This patch adds support for Xilinx Dynamic Function eXchange(DFX) AXI
> shutdown manager IP. It can be used to safely handling the AXI traffic
> on a Reconfigurable Partition when it is undergoing dynamic reconfiguration
> and there by preventing system deadlock that may occur if AXI transactions
> are interrupted during reconfiguration.
>
> PR-Decoupler and AXI shutdown manager are completely different IPs.
> But both the IP registers are compatible and also both belong to the
> same sub-system (fpga-bridge).So using same driver for both IP's.
>
> Signed-off-by: Nava kishore Manne 
> ---
> Changes for v2:
> -Fixed some minor coding issues as suggested by
>  Tom Rix.
>
>  drivers/fpga/Kconfig   |  9 +++-
>  drivers/fpga/xilinx-pr-decoupler.c | 37 ++
>  2 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 5645226ca3ce..bf85b9a65ec2 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -118,10 +118,17 @@ config XILINX_PR_DECOUPLER
>   depends on FPGA_BRIDGE
>   depends on HAS_IOMEM
>   help
> -   Say Y to enable drivers for Xilinx LogiCORE PR Decoupler.
> +   Say Y to enable drivers for Xilinx LogiCORE PR Decoupler
> +   or Xilinx Dynamic Function eXchnage AIX Shutdown Manager.
> The PR Decoupler exists in the FPGA fabric to isolate one
> region of the FPGA from the busses while that region is
> being reprogrammed during partial reconfig.
> +   The Dynamic Function eXchange AXI shutdown manager prevents
> +   AXI traffic from passing through the bridge. The controller
> +   safely handles AXI4MM and AXI4-Lite interfaces on a
> +   Reconfigurable Partition when it is undergoing dynamic
> +   reconfiguration, preventing the system deadlock that can
> +   occur if AXI transactions are interrupted by DFX.
>  
>  config FPGA_REGION
>   tristate "FPGA Region"
> diff --git a/drivers/fpga/xilinx-pr-decoupler.c 
> b/drivers/fpga/xilinx-pr-decoupler.c
> index 7d69af230567..78a6f5324193 100644
> --- a/drivers/fpga/xilinx-pr-decoupler.c
> +++ b/drivers/fpga/xilinx-pr-decoupler.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2017, National Instruments Corp.
> - * Copyright (c) 2017, Xilix Inc
> + * Copyright (c) 2017, Xilinx Inc
>   *
>   * FPGA Bridge Driver for the Xilinx LogiCORE Partial Reconfiguration
>   * Decoupler IP Core.
> @@ -18,7 +18,12 @@
>  #define CTRL_CMD_COUPLE  0
>  #define CTRL_OFFSET  0
>  
> +struct xlnx_config_data {
> + const char *name;
> +};
> +
>  struct xlnx_pr_decoupler_data {
> + const struct xlnx_config_data *ipconfig;
>   void __iomem *io_base;
>   struct clk *clk;
>  };
> @@ -76,15 +81,28 @@ static const struct fpga_bridge_ops 
> xlnx_pr_decoupler_br_ops = {
>   .enable_show = xlnx_pr_decoupler_enable_show,
>  };
>  
> +static const struct xlnx_config_data decoupler_config = {
> + .name = "Xilinx PR Decoupler",
> +};
> +
> +static const struct xlnx_config_data shutdown_config = {
> + .name = "Xilinx DFX AXI Shutdown Manager",
> +};
> +
>  static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
> - { .compatible = "xlnx,pr-decoupler-1.00", },
> - { .compatible = "xlnx,pr-decoupler", },
> + { .compatible = "xlnx,pr-decoupler-1.00", .data = _config },
> + { .compatible = "xlnx,pr-decoupler", .data = _config },
> + { .compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
> + .data = _config },
> + { .compatible = "xlnx,dfx-axi-shutdown-manager",
> + .data = _config },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, xlnx_pr_decoupler_of_match);
>  
>  static int xlnx_pr_decoupler_probe(struct platform_device *pdev)
>  {
> + struct device_node *np = pdev->dev.of_node;
>   struct xlnx_pr_decoupler_data *priv;
>   struct fpga_bridge *br;
>   int err;
> @@ -94,6 +112,14 @@ static int xlnx_pr_decoupler_probe(struct platform_device 
> *pdev)
>   if (!priv)
>   return -ENOMEM;
>  
> + if (np) {
> + const struct of_device_id *match;
> +
> + match = of_match_node(xlnx_pr_decoupler_of_match, np);
> + if (match && match->data)
> + priv->ipconfig = match->data;
> + }
> +
>   res = platfor

Re: [PATCH V3 XRT Alveo 13/18] fpga: xrt: devctl platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add devctl driver. devctl is a type of hardware function which only has
> few registers to read or write. They are discovered by walking firmware
> metadata. A platform device node will be created for them.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/devctl.h |  43 +
>  drivers/fpga/xrt/lib/xleaf/devctl.c | 206 
>  2 files changed, 249 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/devctl.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/devctl.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/devctl.h 
> b/drivers/fpga/xrt/include/xleaf/devctl.h
> new file mode 100644
> index ..96a40e066f83
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/devctl.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT DEVCTL Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_DEVCTL_H_
> +#define _XRT_DEVCTL_H_
> +
> +#include "xleaf.h"
> +
> +/*
> + * DEVCTL driver IOCTL calls.
> + */
> +enum xrt_devctl_ioctl_cmd {
> + XRT_DEVCTL_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
> + XRT_DEVCTL_WRITE,
> +};
> +
> +enum xrt_devctl_id {
> + XRT_DEVCTL_ROM_UUID,
Assumes 0, should make this explicit and initialize to 0
> + XRT_DEVCTL_DDR_CALIB,
> + XRT_DEVCTL_GOLDEN_VER,
> + XRT_DEVCTL_MAX
> +};
> +
> +struct xrt_devctl_ioctl_rw {
> + u32 xgir_id;
> + void*xgir_buf;
> + u32 xgir_len;
> + u32 xgir_offset;
similar to other patches, the xgir_ prefix is not needed
> +};
> +
> +struct xrt_devctl_ioctl_intf_uuid {
> + u32 xgir_uuid_num;
> + uuid_t  *xgir_uuids;
> +};
> +
> +#endif   /* _XRT_DEVCTL_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/devctl.c 
> b/drivers/fpga/xrt/lib/xleaf/devctl.c
> new file mode 100644
> index ..caf8c6569f0f
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/devctl.c
> @@ -0,0 +1,206 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA devctl Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/devctl.h"
> +
> +#define XRT_DEVCTL "xrt_devctl"
> +
> +struct xrt_name_id {
> + char *ep_name;
> + int id;
> +};
> +
> +static struct xrt_name_id name_id[XRT_DEVCTL_MAX] = {
> + { XRT_MD_NODE_BLP_ROM, XRT_DEVCTL_ROM_UUID },
> + { XRT_MD_NODE_GOLDEN_VER, XRT_DEVCTL_GOLDEN_VER },
DDR_CALIB is unused ?
> +};
> +
> +struct xrt_devctl {
> + struct platform_device  *pdev;
> + void__iomem *base_addrs[XRT_DEVCTL_MAX];
> + ulong   sizes[XRT_DEVCTL_MAX];
> +};
similar to other patches, why not use regmap ?
> +
> +static int xrt_devctl_name2id(struct xrt_devctl *devctl, const char *name)
> +{
> + int i;
> +
> + for (i = 0; i < XRT_DEVCTL_MAX && name_id[i].ep_name; i++) {
> + if (!strncmp(name_id[i].ep_name, name, 
> strlen(name_id[i].ep_name) + 1))
> + return name_id[i].id;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int
> +xrt_devctl_leaf_ioctl(struct platform_device *pdev, u32 cmd, void *arg)
> +{
> + struct xrt_devctl   *devctl;
> + int ret = 0;
> +
> + devctl = platform_get_drvdata(pdev);
> +
> + switch (cmd) {
> + case XRT_XLEAF_EVENT:
> + /* Does not handle any event. */
> + break;
> + case XRT_DEVCTL_READ: {
> + struct xrt_devctl_ioctl_rw  *rw_arg = arg;
> + u32 *p_src, *p_dst, i;
> +
> + if (rw_arg->xgir_len & 0x3) {
> + xrt_err(pdev, "invalid len %d", rw_arg->xgir_len);
> + return -EINVAL;
> + }
> +
> + if (rw_arg->xgir_id >= XRT_DEVCTL_MAX) {
> + xrt_err(pdev, "invalid id %d", rw_arg->xgir_id);
> + return -EINVAL;
> + }
needs a < 0 check ?
> +
> + p_src = devctl->base_addrs[rw_arg->xgir_id];
> + if (!p_src) {
> + xrt_err(pdev, "io not found, id %d",
> + rw_arg->xgir_id);
> + return -EINVAL;
> + }
> + if (rw_arg->xgir_offset + rw_arg->xgir_len >
> + devctl->sizes[rw_arg->xgir_id]) {
> + xrt_err(pdev, "invalid argument, off %d, len %d",
> + rw_arg->xgir_offset, rw_arg->xgir_len);
> + return -EINVAL;
> + }
> + p_dst = rw_arg->xgir_buf;
> + for (i = 0; i < rw_arg->xgir_len / sizeof(u32); i++) {
> + u32 

Re: [PATCH V3 XRT Alveo 12/18] fpga: xrt: ICAP platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add ICAP driver. ICAP is a hardware function discovered by walking
What does ICAP stand for ?
> firmware metadata. A platform device node will be created for it.
> FPGA bitstream is written to hardware through ICAP.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/icap.h |  29 +++
>  drivers/fpga/xrt/lib/xleaf/icap.c | 317 ++
>  2 files changed, 346 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/icap.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/icap.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/icap.h 
> b/drivers/fpga/xrt/include/xleaf/icap.h
> new file mode 100644
> index ..a14fc0ffa78f
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/icap.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT ICAP Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_ICAP_H_
> +#define _XRT_ICAP_H_
> +
> +#include "xleaf.h"
> +
> +/*
> + * ICAP driver IOCTL calls.
> + */
> +enum xrt_icap_ioctl_cmd {
> + XRT_ICAP_WRITE = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
maybe XRT_ICAP_GET_IDCODE
> + XRT_ICAP_IDCODE,
> +};
> +
> +struct xrt_icap_ioctl_wr {
> + void*xiiw_bit_data;
> + u32 xiiw_data_len;
> +};
> +
> +#endif   /* _XRT_ICAP_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/icap.c 
> b/drivers/fpga/xrt/lib/xleaf/icap.c
> new file mode 100644
> index ..0500a97bdef9
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/icap.c
> @@ -0,0 +1,317 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA ICAP Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + *  Sonal Santan 
> + *  Max Zhen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/icap.h"
> +#include "xclbin-helper.h"
> +
> +#define XRT_ICAP "xrt_icap"
> +
> +#define ICAP_ERR(icap, fmt, arg...)  \
> + xrt_err((icap)->pdev, fmt "\n", ##arg)
> +#define ICAP_WARN(icap, fmt, arg...) \
> + xrt_warn((icap)->pdev, fmt "\n", ##arg)
> +#define ICAP_INFO(icap, fmt, arg...) \
> + xrt_info((icap)->pdev, fmt "\n", ##arg)
> +#define ICAP_DBG(icap, fmt, arg...)  \
> + xrt_dbg((icap)->pdev, fmt "\n", ##arg)
> +
> +/*
> + * AXI-HWICAP IP register layout
> + */
> +struct icap_reg {
> + u32 ir_rsvd1[7];
> + u32 ir_gier;
> + u32 ir_isr;
> + u32 ir_rsvd2;
> + u32 ir_ier;
> + u32 ir_rsvd3[53];
> + u32 ir_wf;
> + u32 ir_rf;
> + u32 ir_sz;
> + u32 ir_cr;
> + u32 ir_sr;
> + u32 ir_wfv;
> + u32 ir_rfo;
> + u32 ir_asr;
> +} __packed;
> +
> +struct icap {
> + struct platform_device  *pdev;
> + struct icap_reg *icap_regs;
> + struct mutexicap_lock; /* icap dev lock */
> +
> + unsigned intidcode;
returned as a 64 bit value, but could be stored as 32 bit
> +};
> +
> +static inline u32 reg_rd(void __iomem *reg)
> +{
> + if (!reg)
> + return -1;
> +
> + return ioread32(reg);
Look at converting the io access to using regmap* api
> +}
> +
> +static inline void reg_wr(void __iomem *reg, u32 val)
> +{
> + if (!reg)
> + return;
> +
> + iowrite32(val, reg);
> +}
> +
> +static int wait_for_done(struct icap *icap)
> +{
> + u32 w;
> + int i = 0;
> +
> + WARN_ON(!mutex_is_locked(>icap_lock));
is this needed ? wait_for_done is only called in one place.
> + for (i = 0; i < 10; i++) {
> + udelay(5);
comment on delay.
> + w = reg_rd(>icap_regs->ir_sr);
> + ICAP_INFO(icap, "XHWICAP_SR: %x", w);
> + if (w & 0x5)
0x5 is a magic number, should be #defined
> + return 0;
> + }
> +
> + ICAP_ERR(icap, "bitstream download timeout");
> + return -ETIMEDOUT;
> +}
> +
> +static int icap_write(struct icap *icap, const u32 *word_buf, int size)
> +{
> + int i;
> + u32 value = 0;
> +
> + for (i = 0; i < size; i++) {
> + value = be32_to_cpu(word_buf[i]);
> + reg_wr(>icap_regs->ir_wf, value);
> + }
> +
> + reg_wr(>icap_regs->ir_cr, 0x1);
> +
> + for (i = 0; i < 20; i++) {
> + value = reg_rd(>icap_regs->ir_cr);
> + if ((value & 0x1) == 0)
> + return 0;
> + ndelay(50);
> + }
> +
> + ICAP_ERR(icap, "writing %d dwords timeout", size);
> + return -EIO;
> +}
> +
> +static int bitstream_helper(struct icap *icap, const u32 *word_buffer,
> + u32 word_count)
> +{
> + u32 remain_word;
> + u32 word_written = 0;
> + int wr_fifo_vacancy = 0;
> + int err = 0;
> +

Re: [PATCH V3 XRT Alveo 11/18] fpga: xrt: UCS platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add UCS driver. UCS is a hardware function discovered by walking xclbin
What does UCS stand for ? add to commit log
> metadata. A platform device node will be created for it.
> UCS enables/disables the dynamic region clocks.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xleaf/ucs.h |  24 +++
>  drivers/fpga/xrt/lib/xleaf/ucs.c | 235 +++
>  2 files changed, 259 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xleaf/ucs.h
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/ucs.c
>
> diff --git a/drivers/fpga/xrt/include/xleaf/ucs.h 
> b/drivers/fpga/xrt/include/xleaf/ucs.h
> new file mode 100644
> index ..a5ef0e100e12
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf/ucs.h

This header is only used by ucs.c, so is it needed ?

could the enum be defined in ucs.c ?

> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for XRT UCS Leaf Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + */
> +
> +#ifndef _XRT_UCS_H_
> +#define _XRT_UCS_H_
> +
> +#include "xleaf.h"
> +
> +/*
> + * UCS driver IOCTL calls.
> + */
> +enum xrt_ucs_ioctl_cmd {
> + XRT_UCS_CHECK = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
> + XRT_UCS_ENABLE,
no disable ?
> +};
> +
> +#endif   /* _XRT_UCS_H_ */
> diff --git a/drivers/fpga/xrt/lib/xleaf/ucs.c 
> b/drivers/fpga/xrt/lib/xleaf/ucs.c
> new file mode 100644
> index ..ae762c8fddbb
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/ucs.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA UCS Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/ucs.h"
> +#include "xleaf/clock.h"
> +
> +#define UCS_ERR(ucs, fmt, arg...)   \
> + xrt_err((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_WARN(ucs, fmt, arg...)  \
> + xrt_warn((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_INFO(ucs, fmt, arg...)  \
> + xrt_info((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_DBG(ucs, fmt, arg...)   \
> + xrt_dbg((ucs)->pdev, fmt "\n", ##arg)
> +
> +#define XRT_UCS  "xrt_ucs"
> +
> +#define CHANNEL1_OFFSET  0
> +#define CHANNEL2_OFFSET  8
> +
> +#define CLK_MAX_VALUE6400
> +
> +struct ucs_control_status_ch1 {
> + unsigned int shutdown_clocks_latched:1;
> + unsigned int reserved1:15;
> + unsigned int clock_throttling_average:14;
> + unsigned int reserved2:2;
> +};
Likely needs to be packed and/or the unsigned int changed to u32
> +
> +struct xrt_ucs {
> + struct platform_device  *pdev;
> + void __iomem*ucs_base;
> + struct mutexucs_lock; /* ucs dev lock */
> +};
> +
> +static inline u32 reg_rd(struct xrt_ucs *ucs, u32 offset)
> +{
> + return ioread32(ucs->ucs_base + offset);
> +}
> +
> +static inline void reg_wr(struct xrt_ucs *ucs, u32 val, u32 offset)
> +{
> + iowrite32(val, ucs->ucs_base + offset);
> +}
> +
> +static void xrt_ucs_event_cb(struct platform_device *pdev, void *arg)
> +{
> + struct platform_device  *leaf;
> + struct xrt_event *evt = (struct xrt_event *)arg;
> + enum xrt_events e = evt->xe_evt;
> + enum xrt_subdev_id id = evt->xe_subdev.xevt_subdev_id;
> + int instance = evt->xe_subdev.xevt_subdev_instance;
> +
> + switch (e) {
> + case XRT_EVENT_POST_CREATION:
> + break;
> + default:
> + xrt_dbg(pdev, "ignored event %d", e);
> + return;
> + }
this switch is a noop, remove
> +
> + if (id != XRT_SUBDEV_CLOCK)
> + return;
> +
> + leaf = xleaf_get_leaf_by_id(pdev, XRT_SUBDEV_CLOCK, instance);
> + if (!leaf) {
> + xrt_err(pdev, "does not get clock subdev");
> + return;
> + }
> +
> + xleaf_ioctl(leaf, XRT_CLOCK_VERIFY, NULL);
> + xleaf_put_leaf(pdev, leaf);
> +}
> +
> +static void ucs_check(struct xrt_ucs *ucs, bool *latched)
> +{

checking but not returning status, change to returning int.

this function is called but xrt_ucs_leaf_ioctl which does return status.

> + struct ucs_control_status_ch1 *ucs_status_ch1;
> + u32 status;
> +
> + mutex_lock(>ucs_lock);
> + status = reg_rd(ucs, CHANNEL1_OFFSET);
> + ucs_status_ch1 = (struct ucs_control_status_ch1 *)
> + if (ucs_status_ch1->shutdown_clocks_latched) {
> + UCS_ERR(ucs,
> + "Critical temperature or power event, kernel clocks 
> have been stopped.");
> + UCS_ERR(ucs,
> + "run 'xbutil valiate -q' to continue. See AR 73398 for 
> more details.");
This error message does not seem like it would be 

Re: [PATCH V3 XRT Alveo 10/18] fpga: xrt: VSEC platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Add VSEC driver. VSEC is a hardware function discovered by walking
> PCI Express configure space. A platform device node will be created
> for it. VSEC provides board logic UUID and few offset of other hardware
> functions.
Is this vsec walking infra or is a general find a list of mmio regions that 
need to be mapped in and do the mapping in as a set of platform drivers ?
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/xleaf/vsec.c | 359 ++
>  1 file changed, 359 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/xleaf/vsec.c
>
> diff --git a/drivers/fpga/xrt/lib/xleaf/vsec.c 
> b/drivers/fpga/xrt/lib/xleaf/vsec.c
> new file mode 100644
> index ..8e5cb22522ec
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/vsec.c
> @@ -0,0 +1,359 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA VSEC Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou
> + */
> +
> +#include 
> +#include "metadata.h"
> +#include "xleaf.h"
> +
> +#define XRT_VSEC "xrt_vsec"
> +
> +#define VSEC_TYPE_UUID   0x50
> +#define VSEC_TYPE_FLASH  0x51
> +#define VSEC_TYPE_PLATINFO   0x52
> +#define VSEC_TYPE_MAILBOX0x53
> +#define VSEC_TYPE_END0xff
Type of devices, this list can not grow much.
> +
> +#define VSEC_UUID_LEN16
> +
> +struct xrt_vsec_header {
> + u32 format;
> + u32 length;
> + u32 entry_sz;
> + u32 rsvd;
> +} __packed;
> +
> +#define head_rd(g, r)\
> + ioread32((void *)(g)->base + offsetof(struct xrt_vsec_header, r))
> +
> +#define GET_BAR(entry)   (((entry)->bar_rev >> 4) & 0xf)
> +#define GET_BAR_OFF(_entry)  \
> + ({ typeof(_entry) entry = (_entry); \
> +  ((entry)->off_lo | ((u64)(entry)->off_hi << 16)); })

A 48 bit value stored in xrt_md_endpoint.bar_off (long)

bar_off should be u64 

> +#define GET_REV(entry)   ((entry)->bar_rev & 0xf)
> +
I prefer functions over macros.
> +struct xrt_vsec_entry {
> + u8  type;
> + u8  bar_rev;
> + u16 off_lo;
> + u32 off_hi;
> + u8  ver_type;
> + u8  minor;
> + u8  major;
> + u8  rsvd0;
> + u32 rsvd1;
> +} __packed;
> +
> +#define read_entry(g, i, e)  \
> + do {\
> + u32 *p = (u32 *)((g)->base +\
> + sizeof(struct xrt_vsec_header) +\
> + (i) * sizeof(struct xrt_vsec_entry));   \
> + u32 off;\
> + for (off = 0;   \
> + off < sizeof(struct xrt_vsec_entry) / 4;\
> + off++)  \
> + *((u32 *)(e) + off) = ioread32(p + off);\
> + } while (0)
This could be a static inline func.
> +
> +struct vsec_device {
> + u8  type;
> + char*ep_name;
> + ulong   size;
> + char*regmap;
> +};
> +
> +static struct vsec_device vsec_devs[] = {
> + {
> + .type = VSEC_TYPE_UUID,
> + .ep_name = XRT_MD_NODE_BLP_ROM,
> + .size = VSEC_UUID_LEN,
> + .regmap = "vsec-uuid",
> + },
> + {
> + .type = VSEC_TYPE_FLASH,
> + .ep_name = XRT_MD_NODE_FLASH_VSEC,
> + .size = 4096,
> + .regmap = "vsec-flash",
> + },
> + {
> + .type = VSEC_TYPE_PLATINFO,
> + .ep_name = XRT_MD_NODE_PLAT_INFO,
> + .size = 4,
> + .regmap = "vsec-platinfo",
> + },
> + {
> + .type = VSEC_TYPE_MAILBOX,
> + .ep_name = XRT_MD_NODE_MAILBOX_VSEC,
> + .size = 48,
> + .regmap = "vsec-mbx",
> + },
This is a static list, how would a new type be added to this ?
> +};
> +
> +struct xrt_vsec {
> + struct platform_device  *pdev;
> + void*base;
> + ulong   length;
> +
> + char*metadata;
> + charuuid[VSEC_UUID_LEN];
> +};
> +
> +static char *type2epname(u32 type)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vsec_devs); i++) {
> + if (vsec_devs[i].type == type)
> + return (vsec_devs[i].ep_name);
> + }
> +
> + return NULL;
> +}
> +
> +static ulong type2size(u32 type)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vsec_devs); i++) {
> + if (vsec_devs[i].type == type)
> + return 

Re: [PATCH V3 XRT Alveo 03/18] fpga: xrt: xclbin file helper functions

[Tom Rix]

On 2/26/21 1:23 PM, Lizhi Hou wrote:
> Hi Tom,
>
>
snip

>>
>> I also do not see a pragma pack, usually this is set of 1 so the compiler 
>> does not shuffle elements, increase size etc.
> This data structure is shared with other tools. And the structure is well 
> defined with reasonable alignment. It is compatible with all compilers we 
> have tested. So pragma pack is not necessary.

You can not have possibly tested all the configurations since the kernel 
supports many arches and compilers.

If the tested existing alignment is ok, pragma pack should be a noop on your 
tested configurations.

And help cover the untested configurations.

Tom

Re: [PATCH V3 XRT Alveo 09/18] fpga: xrt: fpga-mgr and region implementation for xclbin download

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> fpga-mgr and region implementation for xclbin download which will be
> called from main platform driver
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/mgmt/fmgr-drv.c| 187 +++
>  drivers/fpga/xrt/mgmt/fmgr.h|  28 ++
>  drivers/fpga/xrt/mgmt/main-region.c | 471 
>  3 files changed, 686 insertions(+)
>  create mode 100644 drivers/fpga/xrt/mgmt/fmgr-drv.c
>  create mode 100644 drivers/fpga/xrt/mgmt/fmgr.h
>  create mode 100644 drivers/fpga/xrt/mgmt/main-region.c
>
> diff --git a/drivers/fpga/xrt/mgmt/fmgr-drv.c 
> b/drivers/fpga/xrt/mgmt/fmgr-drv.c
> new file mode 100644
> index ..a44d35ecdb60
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/fmgr-drv.c
> @@ -0,0 +1,187 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * FPGA Manager Support for Xilinx Alveo Management Function Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors: sonal.san...@xilinx.com
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xclbin-helper.h"
> +#include "xleaf.h"
> +#include "fmgr.h"
> +#include "xleaf/axigate.h"
> +#include "xleaf/icap.h"
> +#include "main-impl.h"
> +
> +struct xfpga_class {
> + const struct platform_device *pdev;
> + char  name[64];
> +};
> +
> +/*
> + * xclbin download plumbing -- find the download subsystem, ICAP and
> + * pass the xclbin for heavy lifting
> + */
> +static int xmgmt_download_bitstream(struct platform_device *pdev,
> + const struct axlf *xclbin)
> +
> +{
> + struct hw_icap_bit_header bit_header = { 0 };
> + struct platform_device *icap_leaf = NULL;
> + struct xrt_icap_ioctl_wr arg;
> + char *bitstream = NULL;
> + u64 bit_len;
> + int ret;
> +
> + ret = xrt_xclbin_get_section(xclbin, BITSTREAM, (void **), 
> _len);
> + if (ret || !bitstream) {
!bitstream check is unneeded
> + xrt_err(pdev, "bitstream not found");
> + return -ENOENT;
> + }
> + ret = xrt_xclbin_parse_bitstream_header(bitstream,
> + DMA_HWICAP_BITFILE_BUFFER_SIZE,
> + _header);
> + if (ret) {
> + ret = -EINVAL;
> + xrt_err(pdev, "invalid bitstream header");
> + goto done;
> + }
> + if (bit_header.header_length + bit_header.bitstream_length > bit_len) {
> + ret = -EINVAL;
> + xrt_err(pdev, "invalid bitstream length. header %d, bitstream 
> %d, section len %lld",
> + bit_header.header_length, bit_header.bitstream_length, 
> bit_len);
> + goto done;
> + }
> +
> + icap_leaf = xleaf_get_leaf_by_id(pdev, XRT_SUBDEV_ICAP, 
> PLATFORM_DEVID_NONE);
> + if (!icap_leaf) {
> + ret = -ENODEV;
> + xrt_err(pdev, "icap does not exist");
> + xrt_xclbin_free_header(_header);
> + goto done;
> + }
> + arg.xiiw_bit_data = bitstream + bit_header.header_length;
> + arg.xiiw_data_len = bit_header.bitstream_length;
> + ret = xleaf_ioctl(icap_leaf, XRT_ICAP_WRITE, );
> + if (ret)
> + xrt_err(pdev, "write bitstream failed, ret = %d", ret);
> +
> + xrt_xclbin_free_header(_header);
memory leak when something fails and goto done's
> +done:
previous general problem, use mutliple label in error handling blocks
> + if (icap_leaf)
> + xleaf_put_leaf(pdev, icap_leaf);
> + vfree(bitstream);
> +
> + return ret;
> +}
> +
> +/*
> + * There is no HW prep work we do here since we need the full
> + * xclbin for its sanity check.
> + */
> +static int xmgmt_pr_write_init(struct fpga_manager *mgr,
> +struct fpga_image_info *info,
> +const char *buf, size_t count)
> +{
> + const struct axlf *bin = (const struct axlf *)buf;
> + struct xfpga_class *obj = mgr->priv;
> +
> + if (!(info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + xrt_info(obj->pdev, "%s only supports partial 
> reconfiguration\n", obj->name);
> + return -EINVAL;
> + }
> +
> + if (count < sizeof(struct axlf))
> + return -EINVAL;
> +
> + if (count > bin->m_header.m_length)
> + return -EINVAL;
> +
> + xrt_info(obj->pdev, "Prepare download of xclbin %pUb of length %lld B",
> +  >m_header.uuid, bin->m_header.m_length);
> +
> + return 0;
> +}
> +
> +/*
> + * The implementation requries full xclbin image before we can start
> + * programming the hardware via ICAP subsystem. Full image is required
The full image
> + * for checking the validity of xclbin and walking the sections to
> + * discover the bitstream.
> + */
> +static int xmgmt_pr_write(struct fpga_manager *mgr,
> +   const 

Re: [PATCH V3 XRT Alveo 08/18] fpga: xrt: main platform driver for management function device

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> platform driver that handles IOCTLs, such as hot reset and xclbin download.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xmgmt-main.h |  37 ++
>  drivers/fpga/xrt/mgmt/main-impl.h |  37 ++
>  drivers/fpga/xrt/mgmt/main.c  | 693 ++
>  include/uapi/linux/xrt/xmgmt-ioctl.h  |  46 ++
>  4 files changed, 813 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xmgmt-main.h
>  create mode 100644 drivers/fpga/xrt/mgmt/main-impl.h
>  create mode 100644 drivers/fpga/xrt/mgmt/main.c
>  create mode 100644 include/uapi/linux/xrt/xmgmt-ioctl.h
>
> diff --git a/drivers/fpga/xrt/include/xmgmt-main.h 
> b/drivers/fpga/xrt/include/xmgmt-main.h
> new file mode 100644
> index ..1216d1881f8e
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xmgmt-main.h
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XMGMT_MAIN_H_
> +#define _XMGMT_MAIN_H_
> +
> +#include 
> +#include "xleaf.h"
> +
> +enum xrt_mgmt_main_ioctl_cmd {
> + /* section needs to be vfree'd by caller */
> + XRT_MGMT_MAIN_GET_AXLF_SECTION = XRT_XLEAF_CUSTOM_BASE, /* See comments 
> in xleaf.h */
the must free instructions should go with the pointer needing freeing
> + /* vbnv needs to be kfree'd by caller */
> + XRT_MGMT_MAIN_GET_VBNV,
> +};
> +
> +enum provider_kind {
> + XMGMT_BLP,
> + XMGMT_PLP,
> + XMGMT_ULP,
what do these three mean ?
> +};
> +
> +struct xrt_mgmt_main_ioctl_get_axlf_section {
> + enum provider_kind xmmigas_axlf_kind;
> + enum axlf_section_kind xmmigas_section_kind;
> + void *xmmigas_section;
> + u64 xmmigas_section_size;
> +};
> +
> +#endif   /* _XMGMT_MAIN_H_ */
> diff --git a/drivers/fpga/xrt/mgmt/main-impl.h 
> b/drivers/fpga/xrt/mgmt/main-impl.h
>From prefix used in the functions, a better name for this file would be xmgnt.h
> new file mode 100644
> index ..dd1b3e3773cc
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/main-impl.h
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Alveo Management Function Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Lizhi Hou 
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XMGMT_MAIN_IMPL_H_
> +#define _XMGMT_MAIN_IMPL_H_
> +
> +#include 
> +#include "xmgmt-main.h"
> +
> +struct fpga_manager;
> +int xmgmt_process_xclbin(struct platform_device *pdev,
> +  struct fpga_manager *fmgr,
> +  const struct axlf *xclbin,
> +  enum provider_kind kind);
> +void xmgmt_region_cleanup_all(struct platform_device *pdev);
> +
> +int bitstream_axlf_mailbox(struct platform_device *pdev, const void *xclbin);
the prefix should be consistent
> +int xmgmt_hot_reset(struct platform_device *pdev);
> +
> +/* Getting dtb for specified group. Caller should vfree returned dtb .*/
> +char *xmgmt_get_dtb(struct platform_device *pdev, enum provider_kind kind);
> +char *xmgmt_get_vbnv(struct platform_device *pdev);
> +int xmgmt_get_provider_uuid(struct platform_device *pdev,
> + enum provider_kind kind, uuid_t *uuid);
> +
> +int xmgmt_main_register_leaf(void);
> +void xmgmt_main_unregister_leaf(void);
is _main_ needed ?
> +
> +#endif   /* _XMGMT_MAIN_IMPL_H_ */
> diff --git a/drivers/fpga/xrt/mgmt/main.c b/drivers/fpga/xrt/mgmt/main.c
> new file mode 100644
> index ..66ffb4e7029d
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/main.c
> @@ -0,0 +1,693 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA MGMT PF entry point driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Sonal Santan 
> + */
> +
> +#include 
> +#include 
> +#include "xclbin-helper.h"
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include 
> +#include "xleaf/devctl.h"
> +#include "xmgmt-main.h"
> +#include "fmgr.h"
> +#include "xleaf/icap.h"
> +#include "xleaf/axigate.h"
> +#include "main-impl.h"
> +
> +#define XMGMT_MAIN "xmgmt_main"
> +
> +struct xmgmt_main {
> + struct platform_device *pdev;
> + struct axlf *firmware_blp;
> + struct axlf *firmware_plp;
> + struct axlf *firmware_ulp;
> + bool flash_ready;
> + bool devctl_ready;
could combine in a bitfield
> + struct fpga_manager *fmgr;
> + struct mutex busy_mutex; /* busy lock */
busy_mutex ? maybe just call this 'lock'
> +
> + uuid_t *blp_intf_uuids;
> + u32 blp_intf_uuid_num;
expand intf to interface
> +};
> +
> +/* Caller should be responsible for freeing the returned string. */
should be -> is
> +char *xmgmt_get_vbnv(struct platform_device *pdev)
what is 'vbnv' ?
> +{
> + struct xmgmt_main *xmm = platform_get_drvdata(pdev);
> + const 

Re: [PATCH V3 XRT Alveo 07/18] fpga: xrt: management physical function driver (root)

[Tom Rix]

A question i do not know the answer to.

Seems like 'golden' is linked to a manufacturing (diagnostics?) image.

If the public will never see it, should handling it here be done ?

Moritz, do you know ?


On 2/17/21 10:40 PM, Lizhi Hou wrote:
> The PCIE device driver which attaches to management function on Alveo
to the management
> devices. It instantiates one or more partition drivers which in turn
more fpga partition / group ?
> instantiate platform drivers. The instantiation of partition and platform
> drivers is completely data driven.
data driven ? everything is data driven.  do you mean dtb driven ?
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xroot.h | 114 +++
>  drivers/fpga/xrt/mgmt/root.c | 342 +++
>  2 files changed, 456 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xroot.h
>  create mode 100644 drivers/fpga/xrt/mgmt/root.c
>
> diff --git a/drivers/fpga/xrt/include/xroot.h 
> b/drivers/fpga/xrt/include/xroot.h
> new file mode 100644
> index ..752e10daa85e
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xroot.h
> @@ -0,0 +1,114 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_ROOT_H_
> +#define _XRT_ROOT_H_
> +
> +#include 
> +#include "subdev_id.h"
> +#include "events.h"
> +
> +typedef bool (*xrt_subdev_match_t)(enum xrt_subdev_id,
> + struct platform_device *, void *);
> +#define XRT_SUBDEV_MATCH_PREV((xrt_subdev_match_t)-1)
> +#define XRT_SUBDEV_MATCH_NEXT((xrt_subdev_match_t)-2)
> +
> +/*
> + * Root IOCTL calls.
> + */
> +enum xrt_root_ioctl_cmd {
> + /* Leaf actions. */
> + XRT_ROOT_GET_LEAF = 0,
> + XRT_ROOT_PUT_LEAF,
> + XRT_ROOT_GET_LEAF_HOLDERS,
> +
> + /* Group actions. */
> + XRT_ROOT_CREATE_GROUP,
> + XRT_ROOT_REMOVE_GROUP,
> + XRT_ROOT_LOOKUP_GROUP,
> + XRT_ROOT_WAIT_GROUP_BRINGUP,
> +
> + /* Event actions. */
> + XRT_ROOT_EVENT,
should this be XRT_ROOT_EVENT_SYNC ?
> + XRT_ROOT_EVENT_ASYNC,
> +
> + /* Device info. */
> + XRT_ROOT_GET_RESOURCE,
> + XRT_ROOT_GET_ID,
> +
> + /* Misc. */
> + XRT_ROOT_HOT_RESET,
> + XRT_ROOT_HWMON,
> +};
> +
> +struct xrt_root_ioctl_get_leaf {
> + struct platform_device *xpigl_pdev; /* caller's pdev */
xpigl_ ? unneeded suffix in element names
> + xrt_subdev_match_t xpigl_match_cb;
> + void *xpigl_match_arg;
> + struct platform_device *xpigl_leaf; /* target leaf pdev */
> +};
> +
> +struct xrt_root_ioctl_put_leaf {
> + struct platform_device *xpipl_pdev; /* caller's pdev */
> + struct platform_device *xpipl_leaf; /* target's pdev */

caller_pdev;

target_pdev;

> +};
> +
> +struct xrt_root_ioctl_lookup_group {
> + struct platform_device *xpilp_pdev; /* caller's pdev */
> + xrt_subdev_match_t xpilp_match_cb;
> + void *xpilp_match_arg;
> + int xpilp_grp_inst;
> +};
> +
> +struct xrt_root_ioctl_get_holders {
> + struct platform_device *xpigh_pdev; /* caller's pdev */
> + char *xpigh_holder_buf;
> + size_t xpigh_holder_buf_len;
> +};
> +
> +struct xrt_root_ioctl_get_res {
> + struct resource *xpigr_res;
> +};
> +
> +struct xrt_root_ioctl_get_id {
> + unsigned short  xpigi_vendor_id;
> + unsigned short  xpigi_device_id;
> + unsigned short  xpigi_sub_vendor_id;
> + unsigned short  xpigi_sub_device_id;
> +};
> +
> +struct xrt_root_ioctl_hwmon {
> + bool xpih_register;
> + const char *xpih_name;
> + void *xpih_drvdata;
> + const struct attribute_group **xpih_groups;
> + struct device *xpih_hwmon_dev;
> +};
> +
> +typedef int (*xrt_subdev_root_cb_t)(struct device *, void *, u32, void *);
This function pointer type is important, please add a comment about its use and 
expected parameters
> +int xrt_subdev_root_request(struct platform_device *self, u32 cmd, void 
> *arg);
> +
> +/*
> + * Defines physical function (MPF / UPF) specific operations
> + * needed in common root driver.
> + */
> +struct xroot_pf_cb {
> + void (*xpc_hot_reset)(struct pci_dev *pdev);
This is only ever set to xmgmt_root_hot_reset, why is this abstraction needed ?
> +};
> +
> +int xroot_probe(struct pci_dev *pdev, struct xroot_pf_cb *cb, void **root);
> +void xroot_remove(void *root);
> +bool xroot_wait_for_bringup(void *root);
> +int xroot_add_vsec_node(void *root, char *dtb);
> +int xroot_create_group(void *xr, char *dtb);
> +int xroot_add_simple_node(void *root, char *dtb, const char *endpoint);
> +void xroot_broadcast(void *root, enum xrt_events evt);
> +
> +#endif   /* _XRT_ROOT_H_ */
> diff --git a/drivers/fpga/xrt/mgmt/root.c b/drivers/fpga/xrt/mgmt/root.c
> new file mode 100644
> index ..583a37c9d30c
> --- /dev/null
> +++ b/drivers/fpga/xrt/mgmt/root.c
> @@ -0,0 +1,342 @@
> 

Re: [PATCH V3 XRT Alveo 06/18] fpga: xrt: platform driver infrastructure

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> infrastructure code providing APIs for managing leaf driver instance
> groups, facilitating inter-leaf driver calls and root calls, managing leaf
> driver device nodes.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/events.h|  48 ++
>  drivers/fpga/xrt/include/subdev_id.h |  43 ++
>  drivers/fpga/xrt/include/xleaf.h | 276 +
>  drivers/fpga/xrt/lib/cdev.c  | 231 +++
>  drivers/fpga/xrt/lib/subdev.c| 871 +++
>  drivers/fpga/xrt/lib/subdev_pool.h   |  53 ++
>  drivers/fpga/xrt/lib/xroot.c | 598 ++
>  7 files changed, 2120 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/events.h
>  create mode 100644 drivers/fpga/xrt/include/subdev_id.h
>  create mode 100644 drivers/fpga/xrt/include/xleaf.h
>  create mode 100644 drivers/fpga/xrt/lib/cdev.c
>  create mode 100644 drivers/fpga/xrt/lib/subdev.c
>  create mode 100644 drivers/fpga/xrt/lib/subdev_pool.h
>  create mode 100644 drivers/fpga/xrt/lib/xroot.c
>
> diff --git a/drivers/fpga/xrt/include/events.h 
> b/drivers/fpga/xrt/include/events.h
> new file mode 100644
> index ..2a9aae8bceb4
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/events.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
general problem with generic, low information comments
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_EVENTS_H_
> +#define _XRT_EVENTS_H_
> +
> +#include 
why is platform_device.h needed ?
> +#include "subdev_id.h"
> +
> +/*
> + * Event notification.
> + */
> +enum xrt_events {
> + XRT_EVENT_TEST = 0, /* for testing */
> + /*
> +  * Events related to specific subdev
> +  * Callback arg: struct xrt_event_arg_subdev
> +  */
> + XRT_EVENT_POST_CREATION,
> + XRT_EVENT_PRE_REMOVAL,
> + /*
> +  * Events related to change of the whole board
> +  * Callback arg: 
> +  */
> + XRT_EVENT_PRE_HOT_RESET,
> + XRT_EVENT_POST_HOT_RESET,
> + XRT_EVENT_PRE_GATE_CLOSE,
> + XRT_EVENT_POST_GATE_OPEN,
> +};
> +
> +struct xrt_event_arg_subdev {
> + enum xrt_subdev_id xevt_subdev_id;
> + int xevt_subdev_instance;
> +};
> +
> +struct xrt_event {
> + enum xrt_events xe_evt;
> + struct xrt_event_arg_subdev xe_subdev;
> +};
> +
> +#endif   /* _XRT_EVENTS_H_ */
> diff --git a/drivers/fpga/xrt/include/subdev_id.h 
> b/drivers/fpga/xrt/include/subdev_id.h
> new file mode 100644
> index ..6205a9f26196
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/subdev_id.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_SUBDEV_ID_H_
> +#define _XRT_SUBDEV_ID_H_
> +
> +/*
> + * Every subdev driver should have an ID for others to refer to it.
driver has an ID
> + * There can be unlimited number of instances of a subdev driver. A
unlimited? change to 'multiple'
> + *  tuple should be a unique identification of
tuple is a unique
> + * a specific instance of a subdev driver.
> + * NOTE: PLEASE do not change the order of IDs. Sub devices in the same
> + * group are initialized by this order.
why does the order matter? the enums are all initialized
> + */
> +enum xrt_subdev_id {
> + XRT_SUBDEV_GRP = 0,
> + XRT_SUBDEV_VSEC = 1,
> + XRT_SUBDEV_VSEC_GOLDEN = 2,
> + XRT_SUBDEV_DEVCTL = 3,
> + XRT_SUBDEV_AXIGATE = 4,
> + XRT_SUBDEV_ICAP = 5,
> + XRT_SUBDEV_TEST = 6,
> + XRT_SUBDEV_MGMT_MAIN = 7,
> + XRT_SUBDEV_QSPI = 8,
> + XRT_SUBDEV_MAILBOX = 9,
> + XRT_SUBDEV_CMC = 10,
> + XRT_SUBDEV_CALIB = 11,
> + XRT_SUBDEV_CLKFREQ = 12,
> + XRT_SUBDEV_CLOCK = 13,
> + XRT_SUBDEV_SRSR = 14,
> + XRT_SUBDEV_UCS = 15,
> + XRT_SUBDEV_NUM = 16, /* Total number of subdevs. */
> + XRT_ROOT = -1, /* Special ID for root driver. */
> +};
> +
> +#endif   /* _XRT_SUBDEV_ID_H_ */
> diff --git a/drivers/fpga/xrt/include/xleaf.h 
> b/drivers/fpga/xrt/include/xleaf.h
> new file mode 100644
> index ..10215a75d474
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xleaf.h
> @@ -0,0 +1,276 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *Cheng Zhen 
> + *Sonal Santan 
> + */
> +
> +#ifndef _XRT_XLEAF_H_
> +#define _XRT_XLEAF_H_
> +
> +#include 
not needed
> +#include 
> +#include 
> +#include 
> +#include 

not needed

check if includes are actually needed.

> +#include 
> +#include "libfdt.h"
> +#include "subdev_id.h"
> +#include "xroot.h"
> +#include "events.h"
> +
> +/* All subdev drivers should use below common 

Re: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region

[Tom Rix]

The first patch is a fix that is targeted for stable.

Tom

On 2/25/21 5:07 AM, Gong, Richard wrote:
> Hi Moritz,
>
> Sorry for asking.
>
> When you have chance, can you help review the version 5 patchset submitted on 
> 02/09/21?
>
> Regards,
> Richard
>
> -Original Message-
> From: richard.g...@linux.intel.com  
> Sent: Tuesday, February 9, 2021 4:20 PM
> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org; 
> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Gong, Richard 
> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>
> From: Richard Gong 
>
> This is 5th submission of Intel service layer and FPGA patches, which 
> includes the missing standalone patch in the 4th submission.
>
> This submission includes additional changes for Intel service layer driver to 
> get the firmware version running at FPGA SoC device. Then FPGA manager 
> driver, one of Intel service layer driver's client, can decide whether to 
> handle the newly added bitstream authentication function based on the 
> retrieved firmware version. So that we can maintain FPGA manager driver the 
> back compatible.
>
> Bitstream authentication makes sure a signed bitstream has valid signatures.
>
> The customer sends the bitstream via FPGA framework and overlay, the firmware 
> will authenticate the bitstream but not program the bitstream to device. If 
> the authentication passes, the bitstream will be programmed into QSPI flash 
> and will be expected to boot without issues.
>
> Extend Intel service layer, FPGA manager and region drivers to support the 
> bitstream authentication feature. 
>
> Richard Gong (7):
>   firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0
>   firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag
>   firmware: stratix10-svc: extend SVC driver to get the firmware version
>   fpga: fpga-mgr: add FPGA_MGR_BITSTREAM_AUTHENTICATE flag
>   fpga: of-fpga-region: add authenticate-fpga-config property
>   dt-bindings: fpga: add authenticate-fpga-config property
>   fpga: stratix10-soc: extend driver for bitstream authentication
>
>  .../devicetree/bindings/fpga/fpga-region.txt   | 10 
>  drivers/firmware/stratix10-svc.c   | 12 -
>  drivers/fpga/of-fpga-region.c  | 24 ++---
>  drivers/fpga/stratix10-soc.c   | 62 
> +++---
>  include/linux/firmware/intel/stratix10-smc.h   | 21 +++-
>  .../linux/firmware/intel/stratix10-svc-client.h| 11 +++-
>  include/linux/fpga/fpga-mgr.h  |  3 ++
>  7 files changed, 125 insertions(+), 18 deletions(-)
>
> --
> 2.7.4
>

Re: [PATCHv3] firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0

[Tom Rix]

Richard,

I see this is for stable.

Your mainline patchset looks ok with me, has it been accepted yet for mainline ?

Reviewed-by: Tom Rix 


On 2/23/21 6:15 AM, richard.g...@linux.intel.com wrote:
> From: Richard Gong 
>
> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
> aligns with the firmware settings.
>
> Cc:  # 5.9+
> Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and 
> timeout values")
> Signed-off-by: Richard Gong 
> ---
> v3: correct the missing item in the Fixes subject line
> v2: add tag Cc:  # 5.9+
> add 'Fixes: ... ' line in the comment
> ---
>  include/linux/firmware/intel/stratix10-svc-client.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
> b/include/linux/firmware/intel/stratix10-svc-client.h
> index a93d859..f843c6a 100644
> --- a/include/linux/firmware/intel/stratix10-svc-client.h
> +++ b/include/linux/firmware/intel/stratix10-svc-client.h
> @@ -56,7 +56,7 @@
>   * COMMAND_RECONFIG_FLAG_PARTIAL:
>   * Set to FPGA configuration type (full or partial).
>   */
> -#define COMMAND_RECONFIG_FLAG_PARTIAL1
> +#define COMMAND_RECONFIG_FLAG_PARTIAL0
>  
>  /**
>   * Timeout settings for service clients:

Re: [PATCH v11 0/2] UIO support for dfl devices

[Tom Rix]

Yilun,

Is there anything outstanding or remaining to be done ?

Tom

On 2/3/21 5:59 PM, Xu Yilun wrote:
> This patchset supports some dfl device drivers written in userspace.
>
> In the patchset v1, the "driver_override" interface should be used to bind
> the DFL UIO driver to DFL devices. But there is concern that the 
> "driver_override" interface is not OK itself.
>
> In v2, we use a new matching algorithem. The "driver_override" interface
> is abandoned, the DFL UIO driver matches any DFL device which could not be
> handled by other DFL drivers. So the DFL UIO driver could be used for new 
> DFL devices which are not supported by kernel. The concern is the UIO may 
> not be suitable as a default/generic driver for all dfl features, such as
> features with multiple interrupts.
>
> In v4, we specify each matching device in the id_table of the UIO driver,
> just the same as other dfl drivers do. Now the UIO driver supports Ether
> Group feature. To support more DFL features, their feature ids should be
> added to the driver's id_table.
>
> Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
> resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
> is suggested that we implement a driver in drivers/uio that directly calls
> UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
> now only binds the ether group feature, which has no irq. So the irq 
> support is not implemented yet.
>
>
> Main changes from v1:
> - switch to the new matching algorithem. It matches DFL devices which could
>   not be handled by other DFL drivers.
> - refacor the code about device resources filling.
> - add the documentation.
>
> Main changes from v2:
> - split the match ops changes in dfl.c to an independent patch.
> - move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
>   to driver/fpga/dfl.h
> - some minor fixes.
>
> Main changes from v3:
> - switch to specifying each matching device in the driver's id_table.
> - refactor the irq handling code.
>
> Main changes from v4:
> - refactor the irq handling code.
>
> Main changes from v5:
> - fix the res[] zero initialization issue.
> - improve the return code for probe().
> - some doc improvement.
>
> Main changes from v6:
> - use platform_device_register_resndata() for pdev creation.
>
> Main changes from v7:
> - some doc fixes.
>
> Main changes from v8:
> - switch to add a uio driver in drivers/uio
>
> Main changes from v9:
> - add this source file in MAINTAINERS
> - improve the Kconfig, add more descriptive Kconfig header, add detailed
>   path for opae uio example in Kconfig.
>
> Main changes from v10:
> - add description in doc that interrupt support is not implemented yet.
>
>
> Xu Yilun (2):
>   uio: uio_dfl: add userspace i/o driver for DFL bus
>   Documentation: fpga: dfl: Add description for DFL UIO support
>
>  Documentation/fpga/dfl.rst | 26 ++
>  MAINTAINERS|  1 +
>  drivers/uio/Kconfig| 17 
>  drivers/uio/Makefile   |  1 +
>  drivers/uio/uio_dfl.c  | 66 
> ++
>  5 files changed, 111 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
>

Re: [PATCH V3 XRT Alveo 05/18] fpga: xrt: group platform driver

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> group driver that manages life cycle of a bunch of leaf driver instances
> and bridges them with root.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/group.h |  27 
>  drivers/fpga/xrt/lib/group.c | 265 +++
>  2 files changed, 292 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/group.h
>  create mode 100644 drivers/fpga/xrt/lib/group.c
>
> diff --git a/drivers/fpga/xrt/include/group.h 
> b/drivers/fpga/xrt/include/group.h
> new file mode 100644
> index ..1874cdd5120d
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/group.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
A bit too generic, please add a description or remove.
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#ifndef _XRT_GROUP_H_
> +#define _XRT_GROUP_H_
> +
> +#include "xleaf.h"
This is patch 6, consider comments on patch 4.
> +
> +/*
> + * Group driver IOCTL calls.

Are these really ioctl calls?

Seems more like messages between nodes in a tree.

Consider changing to better jagon, maybe ioctl -> msg

> + */
> +enum xrt_group_ioctl_cmd {
> + XRT_GROUP_GET_LEAF = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h 
> */
XRT_LEAF_CUSTOM_BASE is a #define, while these are enums. To be consistent, the 
XRT_LEAF_CUSTOM_BASE should be an enum in xleaf, you can initialize it to 64 
there.
> + XRT_GROUP_PUT_LEAF,
> + XRT_GROUP_INIT_CHILDREN,
> + XRT_GROUP_FINI_CHILDREN,
> + XRT_GROUP_TRIGGER_EVENT,
> +};
> +
> +#endif   /* _XRT_GROUP_H_ */
> diff --git a/drivers/fpga/xrt/lib/group.c b/drivers/fpga/xrt/lib/group.c
> new file mode 100644
> index ..6ba56eea479b
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/group.c
> @@ -0,0 +1,265 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Group Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include 
> +#include 
> +#include "xleaf.h"
> +#include "subdev_pool.h"
> +#include "group.h"
> +#include "metadata.h"
> +#include "main.h"
> +
> +#define XRT_GRP "xrt_group"
> +
> +struct xrt_group {
> + struct platform_device *pdev;
> + struct xrt_subdev_pool leaves;
> + bool leaves_created;
> + struct mutex lock; /* lock for group */
> +};
> +
> +static int xrt_grp_root_cb(struct device *dev, void *parg,
> +u32 cmd, void *arg)
could 'cmd' be some enum type ?
> +{
> + int rc;
> + struct platform_device *pdev =
> + container_of(dev, struct platform_device, dev);
> + struct xrt_group *xg = (struct xrt_group *)parg;
> +
> + switch (cmd) {
> + case XRT_ROOT_GET_LEAF_HOLDERS: {
> + struct xrt_root_ioctl_get_holders *holders =
> + (struct xrt_root_ioctl_get_holders *)arg;
> + rc = xrt_subdev_pool_get_holders(>leaves,
> +  holders->xpigh_pdev,
> +  holders->xpigh_holder_buf,
> +  holders->xpigh_holder_buf_len);
> + break;
> + }
> + default:
> + /* Forward parent call to root. */
> + rc = xrt_subdev_root_request(pdev, cmd, arg);
> + break;
> + }
> +
> + return rc;
> +}
> +
> +static int xrt_grp_create_leaves(struct xrt_group *xg)
> +{
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(xg->pdev);
> + enum xrt_subdev_id did;
> + struct xrt_subdev_endpoints *eps = NULL;
> + int ep_count = 0, i, ret = 0, failed = 0;
> + unsigned long mlen;
> + char *dtb, *grp_dtb = NULL;
> + const char *ep_name;
> +
> + mutex_lock(>lock);
> +
> + if (xg->leaves_created) {
> + mutex_unlock(>lock);
This happens should be programming error, so print out some error message
> + return -EEXIST;
> + }
> +
> + xrt_info(xg->pdev, "bringing up leaves...");
> +
> + /* Create all leaves based on dtb. */
> + if (!pdata)
> + goto bail;
move to above the lock and fail with something like -EINVAL
> +
> + mlen = xrt_md_size(DEV(xg->pdev), pdata->xsp_dtb);
> + if (mlen == XRT_MD_INVALID_LENGTH) {
> + xrt_err(xg->pdev, "invalid dtb, len %ld", mlen);
> + goto bail;
> + }
> +
> + grp_dtb = vmalloc(mlen);
> + if (!grp_dtb)
> + goto bail;
failed is only set in the loop. This is an unreported -ENOMEM
> +
> + memcpy(grp_dtb, pdata->xsp_dtb, mlen);
> + for (did = 0; did < XRT_SUBDEV_NUM;) {
why isn't the did incremented ?
> + eps = eps ? eps + 1 : xrt_drv_get_endpoints(did);

this assumes the enpoints are in an array and accessed serially.

this is fragile.

convert to using just the 

Re: [PATCH V3 XRT Alveo 04/18] fpga: xrt: xrt-lib platform driver manager

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> xrt-lib kernel module infrastructure code to register and manage all
> leaf driver modules.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/lib/main.c | 274 
>  drivers/fpga/xrt/lib/main.h |  17 +++
>  2 files changed, 291 insertions(+)
>  create mode 100644 drivers/fpga/xrt/lib/main.c
>  create mode 100644 drivers/fpga/xrt/lib/main.h

Not sure if 'main' is a good base name for something going into a lib.

>
> diff --git a/drivers/fpga/xrt/lib/main.c b/drivers/fpga/xrt/lib/main.c
> new file mode 100644
> index ..36fb62710843
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/main.c
> @@ -0,0 +1,274 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Xilinx Alveo FPGA Support
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *   Cheng Zhen 
> + */
> +
> +#include 
> +#include "xleaf.h"
> +#include "xroot.h"
> +#include "main.h"
> +
> +#define XRT_IPLIB_MODULE_NAME"xrt-lib"
> +#define XRT_IPLIB_MODULE_VERSION "4.0.0"
> +#define XRT_MAX_DEVICE_NODES 128
> +#define XRT_DRVNAME(drv) ((drv)->driver.name)
> +
> +/*
> + * Subdev driver is known by ID to others. We map the ID to it's
by it's ID
> + * struct platform_driver, which contains it's binding name and driver/file 
> ops.
> + * We also map it to the endpoint name in DTB as well, if it's different
> + * than the driver's binding name.
> + */
> +struct xrt_drv_map {
> + struct list_head list;
> + enum xrt_subdev_id id;
> + struct platform_driver *drv;
> + struct xrt_subdev_endpoints *eps;
> + struct ida ida; /* manage driver instance and char dev minor */
> +};
> +
> +static DEFINE_MUTEX(xrt_lib_lock); /* global lock protecting xrt_drv_maps 
> list */
> +static LIST_HEAD(xrt_drv_maps);
> +struct class *xrt_class;
> +
> +static inline struct xrt_subdev_drvdata *
> +xrt_drv_map2drvdata(struct xrt_drv_map *map)
> +{
> + return (struct xrt_subdev_drvdata *)map->drv->id_table[0].driver_data;
> +}
> +
> +static struct xrt_drv_map *
> +xrt_drv_find_map_by_id_nolock(enum xrt_subdev_id id)

name could be by convention

__xrt_drv_find_map_id

> +{
> + const struct list_head *ptr;
> +
> + list_for_each(ptr, _drv_maps) {
> + struct xrt_drv_map *tmap = list_entry(ptr, struct xrt_drv_map, 
> list);
> +
> + if (tmap->id == id)
> + return tmap;
> + }
> + return NULL;
> +}
> +
> +static struct xrt_drv_map *
> +xrt_drv_find_map_by_id(enum xrt_subdev_id id)
> +{
> + struct xrt_drv_map *map;
> +
> + mutex_lock(_lib_lock);
> + map = xrt_drv_find_map_by_id_nolock(id);
> + mutex_unlock(_lib_lock);
> + /*
> +  * map should remain valid even after lock is dropped since a registered
even after the lock
> +  * driver should only be unregistered when driver module is being 
> unloaded,
> +  * which means that the driver should not be used by then.
> +  */
> + return map;
> +}
> +
> +static int xrt_drv_register_driver(struct xrt_drv_map *map)
> +{
> + struct xrt_subdev_drvdata *drvdata;
> + int rc = 0;
> + const char *drvname = XRT_DRVNAME(map->drv);
> +
> + rc = platform_driver_register(map->drv);
> + if (rc) {
> + pr_err("register %s platform driver failed\n", drvname);
> + return rc;
> + }
> +
> + drvdata = xrt_drv_map2drvdata(map);
> + if (drvdata) {
> + /* Initialize dev_t for char dev node. */
> + if (xleaf_devnode_enabled(drvdata)) {
> + rc = 
> alloc_chrdev_region(>xsd_file_ops.xsf_dev_t, 0,
> +  XRT_MAX_DEVICE_NODES, drvname);
> + if (rc) {
> + platform_driver_unregister(map->drv);
> + pr_err("failed to alloc dev minor for %s: 
> %d\n", drvname, rc);
> + return rc;
> + }
> + } else {
> + drvdata->xsd_file_ops.xsf_dev_t = (dev_t)-1;
> + }
> + }
> +
> + ida_init(>ida);
> +
> + pr_info("%s registered successfully\n", drvname);
> +
> + return 0;
> +}
> +
> +static void xrt_drv_unregister_driver(struct xrt_drv_map *map)
> +{
> + const char *drvname = XRT_DRVNAME(map->drv);
> + struct xrt_subdev_drvdata *drvdata;
> +
> + ida_destroy(>ida);
> +
> + drvdata = xrt_drv_map2drvdata(map);
> + if (drvdata && drvdata->xsd_file_ops.xsf_dev_t != (dev_t)-1) {
> + unregister_chrdev_region(drvdata->xsd_file_ops.xsf_dev_t,
> +  XRT_MAX_DEVICE_NODES);
> + }
> +
> + platform_driver_unregister(map->drv);
> +
> + pr_info("%s unregistered successfully\n", drvname);
> +}
> +
> +int xleaf_register_driver(enum xrt_subdev_id id,
> +   struct 

[tip: timers/urgent] clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined

[tip-bot2 for Tom Rix]

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID: 7da390694afbaed8e0f05717a541dfaf1077ba51
Gitweb:
https://git.kernel.org/tip/7da390694afbaed8e0f05717a541dfaf1077ba51
Author:Tom Rix 
AuthorDate:Mon, 18 Jan 2021 13:19:55 -08:00
Committer: Daniel Lezcano 
CommitterDate: Mon, 18 Jan 2021 22:28:59 +01:00

clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined

When DEBUG is defined this error occurs

drivers/clocksource/mxs_timer.c:138:1: error:
  expected ‘;’ before ‘}’ token

The preceding statement needs a semicolon.
Replace pr_info() with pr_debug() and remove the unneeded ifdef.

Fixes: eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' 
interface")
Signed-off-by: Tom Rix 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20210118211955.763609-1-t...@redhat.com
---
 drivers/clocksource/mxs_timer.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
index bc96a4c..e52e12d 100644
--- a/drivers/clocksource/mxs_timer.c
+++ b/drivers/clocksource/mxs_timer.c
@@ -131,10 +131,7 @@ static void mxs_irq_clear(char *state)
 
/* Clear pending interrupt */
timrot_irq_acknowledge();
-
-#ifdef DEBUG
-   pr_info("%s: changing mode to %s\n", __func__, state)
-#endif /* DEBUG */
+   pr_debug("%s: changing mode to %s\n", __func__, state);
 }
 
 static int mxs_shutdown(struct clock_event_device *evt)

Re: [PATCH V3 XRT Alveo 03/18] fpga: xrt: xclbin file helper functions

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Alveo FPGA firmware and partial reconfigure file are in xclbin format.
This code enumerates and extracts
>  Add
> code to enumerate and extract sections from xclbin files. xclbin.h is cross
> platform and used across all platforms and OS
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/xclbin-helper.h |  52 +++
>  drivers/fpga/xrt/lib/xclbin.c| 394 ++
>  include/uapi/linux/xrt/xclbin.h  | 408 +++
>  3 files changed, 854 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/xclbin-helper.h
>  create mode 100644 drivers/fpga/xrt/lib/xclbin.c
>  create mode 100644 include/uapi/linux/xrt/xclbin.h
>
> diff --git a/drivers/fpga/xrt/include/xclbin-helper.h 
> b/drivers/fpga/xrt/include/xclbin-helper.h
> new file mode 100644
> index ..68218efc9d0b
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/xclbin-helper.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *David Zhang 
> + *Sonal Santan 
> + */
> +
> +#ifndef _XRT_XCLBIN_H
> +#define _XRT_XCLBIN_H

The header guard should match the filename.

> +
> +#include 
> +#include 
> +#include 
> +
> +#define ICAP_XCLBIN_V2   "xclbin2"
> +#define DMA_HWICAP_BITFILE_BUFFER_SIZE 1024
> +#define MAX_XCLBIN_SIZE (1024 * 1024 * 1024) /* Assuming xclbin <= 1G, 
> always */
#defines should have a prefix, maybe XRT_ or XCLBIN_
> +
> +enum axlf_section_kind;
> +struct axlf;
> +
> +/**
> + * Bitstream header information as defined by Xilinx tools.
> + * Please note that this struct definition is not owned by the driver.
> + */
> +struct hw_icap_bit_header {

File headers usually have fixed length fields like uint32_t

Is this a structure the real header is converted into ?

> + unsigned int header_length; /* Length of header in 32 bit words */
> + unsigned int bitstream_length;  /* Length of bitstream to read in 
> bytes*/
> + unsigned char *design_name; /* Design name get from bitstream */
> + unsigned char *part_name;   /* Part name read from bitstream */
> + unsigned char *date;   /* Date read from bitstream header */
> + unsigned char *time;   /* Bitstream creation time */
> + unsigned int magic_length;  /* Length of the magic numbers */
> + unsigned char *version; /* Version string */
> +};
> +
> +const char *xrt_xclbin_kind_to_string(enum axlf_section_kind kind);

Only add decl's that are using in multiple files.

This is only defined in xclbin.c, why does it need to be in the header ?

> +int xrt_xclbin_get_section(const struct axlf *xclbin,
> +enum axlf_section_kind kind, void **data,
> +uint64_t *len);
> +int xrt_xclbin_get_metadata(struct device *dev, const struct axlf *xclbin, 
> char **dtb);
> +int xrt_xclbin_parse_bitstream_header(const unsigned char *data,
> +   unsigned int size,
> +   struct hw_icap_bit_header *header);
> +void xrt_xclbin_free_header(struct hw_icap_bit_header *header);
> +const char *xrt_clock_type2epname(enum CLOCK_TYPE type);
CLOCK_TYPE needs a prefix, something like XCLBIN_CLOCK_TYPE
> +
> +#endif /* _XRT_XCLBIN_H */
> diff --git a/drivers/fpga/xrt/lib/xclbin.c b/drivers/fpga/xrt/lib/xclbin.c
> new file mode 100644
> index ..47dc6ca25c1b
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xclbin.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA Driver XCLBIN parser
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors: David Zhang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "xclbin-helper.h"
> +#include "metadata.h"
> +
What is XHI ?  Maybe expand this, at the lease should comment
> +/* Used for parsing bitstream header */
> +#define XHI_EVEN_MAGIC_BYTE 0x0f
> +#define XHI_ODD_MAGIC_BYTE  0xf0
> +
> +/* Extra mode for IDLE */
> +#define XHI_OP_IDLE  -1
> +#define XHI_BIT_HEADER_FAILURE -1
> +
> +/* The imaginary module length register */
> +#define XHI_MLR  15
> +
> +static inline unsigned char xhi_data_and_inc(const unsigned char *d, int *i, 
> int sz)
could move to the *.h
> +{_
> + unsigned char data;
> +
> + if (*i >= sz)
> + return -1;
The return value of this funtion is not always checked, at the least add a 
dev_err here
> +
> + data = d[*i];
> + (*i)++;
> +
> + return data;
> +}
> +
> +static const struct axlf_section_header *
> +xrt_xclbin_get_section_hdr(const struct axlf *xclbin,
> +enum axlf_section_kind kind)
> +{
> + int i = 0;
> +
> + for (i = 0; i < xclbin->m_header.m_numSections; i++) {
> + if 

Re: [PATCH V3 XRT Alveo 18/18] fpga: xrt: Kconfig and Makefile updates for XRT drivers

[Tom Rix]

As I am looking through the files, I have this comment.

fpga/ is currently a single directory, while files could be organized in 
subdirectories like

dfl/pci.c

instead have the possible subdir name as a prefix to the filename.

dfl-pci.c

For consistency,

xrt/metadata/metadata.c

should be

xrt-metadata.c

Likewise the build infra needs to integrated within the existing files 
fpga/Kconfig,Makefile

This is a bigish refactor, so let's get a second opinion.

Moritz ?

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Update fpga Kconfig/Makefile and add Kconfig/Makefile for new drivers.
Expand the comment, there are several new configs that could use an explanation
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  MAINTAINERS| 11 +++
>  drivers/Makefile   |  1 +
>  drivers/fpga/Kconfig   |  2 ++
>  drivers/fpga/Makefile  |  4 
>  drivers/fpga/xrt/Kconfig   |  8 
>  drivers/fpga/xrt/lib/Kconfig   | 16 
>  drivers/fpga/xrt/lib/Makefile  | 30 ++
>  drivers/fpga/xrt/metadata/Kconfig  | 12 
>  drivers/fpga/xrt/metadata/Makefile | 16 
>  drivers/fpga/xrt/mgmt/Kconfig  | 15 +++
>  drivers/fpga/xrt/mgmt/Makefile | 19 +++
>  11 files changed, 134 insertions(+)
>  create mode 100644 drivers/fpga/xrt/Kconfig
>  create mode 100644 drivers/fpga/xrt/lib/Kconfig
>  create mode 100644 drivers/fpga/xrt/lib/Makefile
>  create mode 100644 drivers/fpga/xrt/metadata/Kconfig
>  create mode 100644 drivers/fpga/xrt/metadata/Makefile
>  create mode 100644 drivers/fpga/xrt/mgmt/Kconfig
>  create mode 100644 drivers/fpga/xrt/mgmt/Makefile
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d3e847f7f3dc..e6e147c2454c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6973,6 +6973,17 @@ F: Documentation/fpga/
>  F:   drivers/fpga/
>  F:   include/linux/fpga/
>  
> +FPGA XRT DRIVERS
> +M:   Lizhi Hou 
> +R:   Max Zhen 
> +R:   Sonal Santan 
> +L:   linux-f...@vger.kernel.org
> +S:   Maintained
> +W:   https://github.com/Xilinx/XRT
> +F:   Documentation/fpga/xrt.rst
> +F:   drivers/fpga/xrt/
> +F:   include/uapi/linux/xrt/
> +
>  FPU EMULATOR
>  M:   Bill Metzenthen 
>  S:   Maintained
> diff --git a/drivers/Makefile b/drivers/Makefile
> index fd11b9ac4cc3..e03912af8e48 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -178,6 +178,7 @@ obj-$(CONFIG_STM) += hwtracing/stm/
>  obj-$(CONFIG_ANDROID)+= android/
>  obj-$(CONFIG_NVMEM)  += nvmem/
>  obj-$(CONFIG_FPGA)   += fpga/
> +obj-y+= fpga/xrt/metadata/

This is wrong.

Move metadata building to fpga/ Makefile and pick an appropriate config, not 
just 'obj-y'

>  obj-$(CONFIG_FSI)+= fsi/
>  obj-$(CONFIG_TEE)+= tee/
>  obj-$(CONFIG_MULTIPLEXER)+= mux/
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 5645226ca3ce..aeca635b1f25 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -216,4 +216,6 @@ config FPGA_MGR_ZYNQMP_FPGA
> to configure the programmable logic(PL) through PS
> on ZynqMP SoC.
>  
> +source "drivers/fpga/xrt/Kconfig"
> +
>  endif # FPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index d8e21dfc6778..2b4453ff7c52 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -46,3 +46,7 @@ dfl-afu-objs += dfl-afu-error.o
>  
>  # Drivers for FPGAs which implement DFL
>  obj-$(CONFIG_FPGA_DFL_PCI)   += dfl-pci.o
> +
> +# XRT drivers for Alveo
> +obj-$(CONFIG_FPGA_XRT_LIB)   += xrt/lib/
> +obj-$(CONFIG_FPGA_XRT_XMGMT) += xrt/mgmt/

I don't see how mgmnt would work without lib.  If that is so

these configs could collapse to CONFIG_FPGA_XRT

> diff --git a/drivers/fpga/xrt/Kconfig b/drivers/fpga/xrt/Kconfig
> new file mode 100644
> index ..0e2c59589ddd
> --- /dev/null
> +++ b/drivers/fpga/xrt/Kconfig
> @@ -0,0 +1,8 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Xilinx Alveo FPGA device configuration
> +#
> +
> +source "drivers/fpga/xrt/metadata/Kconfig"
> +source "drivers/fpga/xrt/lib/Kconfig"
> +source "drivers/fpga/xrt/mgmt/Kconfig"
> diff --git a/drivers/fpga/xrt/lib/Kconfig b/drivers/fpga/xrt/lib/Kconfig
> new file mode 100644
> index ..eed5cb73f5e2
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# XRT Alveo FPGA device configuration
> +#
> +
> +config FPGA_XRT_LIB
> + tristate "XRT Alveo Driver Library"
> + depends on HWMON && PCI && HAS_IOMEM
> + select FPGA_XRT_METADATA
> + help
> +   Select this option to enable Xilinx XRT Alveo driver library. This
> +   library is core infrastructure of XRT Alveo FPGA drivers which
> +   provides functions for working with device nodes, 

Re: [PATCH V3 XRT Alveo 02/18] fpga: xrt: driver metadata helper functions

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> XRT drivers use device tree as metadata format to discover HW subsystems
> behind PCIe BAR. Thus libfdt functions are called for driver to parse
for the driver to parse the
> device tree blob.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  drivers/fpga/xrt/include/metadata.h  | 229 
>  drivers/fpga/xrt/metadata/metadata.c | 524 +++
>  2 files changed, 753 insertions(+)
>  create mode 100644 drivers/fpga/xrt/include/metadata.h
>  create mode 100644 drivers/fpga/xrt/metadata/metadata.c
>
> diff --git a/drivers/fpga/xrt/include/metadata.h 
> b/drivers/fpga/xrt/include/metadata.h
> new file mode 100644
> index ..b929bc469b73
> --- /dev/null
> +++ b/drivers/fpga/xrt/include/metadata.h
> @@ -0,0 +1,229 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Xilinx Runtime (XRT) driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + *  Lizhi Hou 
> + */
> +
> +#ifndef _XRT_METADATA_H
> +#define _XRT_METADATA_H
> +
> +#include 
> +#include 
> +#include 
> +
> +#define XRT_MD_INVALID_LENGTH (~0UL)
> +

These #defines could be in alphabetical order

Some #define with embedded acronyms could be expanded

ex/ XRT_MD_NODE_CMC_REG , what is CMC ?

> +#define XRT_MD_PROP_COMPATIBLE "compatible"
> +#define XRT_MD_PROP_PF_NUM "pcie_physical_function"
> +#define XRT_MD_PROP_BAR_IDX "pcie_bar_mapping"
> +#define XRT_MD_PROP_IO_OFFSET "reg"
> +#define XRT_MD_PROP_INTERRUPTS "interrupts"
> +#define XRT_MD_PROP_INTERFACE_UUID "interface_uuid"
> +#define XRT_MD_PROP_LOGIC_UUID "logic_uuid"
> +#define XRT_MD_PROP_VERSION_MAJOR "firmware_version_major"
> +
> +#define XRT_MD_PROP_HWICAP "axi_hwicap"
> +#define XRT_MD_PROP_PDI_CONFIG "pdi_config_mem"
> +
> +#define XRT_MD_NODE_ENDPOINTS "addressable_endpoints"
> +#define XRT_MD_INTERFACES_PATH "/interfaces"
> +
> +#define XRT_MD_NODE_FIRMWARE "firmware"
> +#define XRT_MD_NODE_INTERFACES "interfaces"
> +#define XRT_MD_NODE_PARTITION_INFO "partition_info"
> +
> +#define XRT_MD_NODE_FLASH "ep_card_flash_program_00"
> +#define XRT_MD_NODE_XVC_PUB "ep_debug_bscan_user_00"
> +#define XRT_MD_NODE_XVC_PRI "ep_debug_bscan_mgmt_00"
> +#define XRT_MD_NODE_SYSMON "ep_cmp_sysmon_00"
> +#define XRT_MD_NODE_AF_BLP_CTRL_MGMT "ep_firewall_blp_ctrl_mgmt_00"
> +#define XRT_MD_NODE_AF_BLP_CTRL_USER "ep_firewall_blp_ctrl_user_00"
> +#define XRT_MD_NODE_AF_CTRL_MGMT "ep_firewall_ctrl_mgmt_00"
> +#define XRT_MD_NODE_AF_CTRL_USER "ep_firewall_ctrl_user_00"
> +#define XRT_MD_NODE_AF_CTRL_DEBUG "ep_firewall_ctrl_debug_00"
> +#define XRT_MD_NODE_AF_DATA_H2C "ep_firewall_data_h2c_00"
> +#define XRT_MD_NODE_AF_DATA_C2H "ep_firewall_data_c2h_00"
> +#define XRT_MD_NODE_AF_DATA_P2P "ep_firewall_data_p2p_00"
> +#define XRT_MD_NODE_AF_DATA_M2M "ep_firewall_data_m2m_00"
> +#define XRT_MD_NODE_CMC_REG "ep_cmc_regmap_00"
> +#define XRT_MD_NODE_CMC_RESET "ep_cmc_reset_00"
> +#define XRT_MD_NODE_CMC_MUTEX "ep_cmc_mutex_00"
> +#define XRT_MD_NODE_CMC_FW_MEM "ep_cmc_firmware_mem_00"
> +#define XRT_MD_NODE_ERT_FW_MEM "ep_ert_firmware_mem_00"
> +#define XRT_MD_NODE_ERT_CQ_MGMT "ep_ert_command_queue_mgmt_00"
> +#define XRT_MD_NODE_ERT_CQ_USER "ep_ert_command_queue_user_00"
> +#define XRT_MD_NODE_MAILBOX_MGMT "ep_mailbox_mgmt_00"
> +#define XRT_MD_NODE_MAILBOX_USER "ep_mailbox_user_00"
> +#define XRT_MD_NODE_GATE_PLP "ep_pr_isolate_plp_00"
> +#define XRT_MD_NODE_GATE_ULP "ep_pr_isolate_ulp_00"
> +#define XRT_MD_NODE_PCIE_MON "ep_pcie_link_mon_00"
> +#define XRT_MD_NODE_DDR_CALIB "ep_ddr_mem_calib_00"
> +#define XRT_MD_NODE_CLK_KERNEL1 "ep_aclk_kernel_00"
> +#define XRT_MD_NODE_CLK_KERNEL2 "ep_aclk_kernel_01"
> +#define XRT_MD_NODE_CLK_KERNEL3 "ep_aclk_hbm_00"
> +#define XRT_MD_NODE_KDMA_CTRL "ep_kdma_ctrl_00"
> +#define XRT_MD_NODE_FPGA_CONFIG "ep_fpga_configuration_00"
> +#define XRT_MD_NODE_ERT_SCHED "ep_ert_sched_00"
> +#define XRT_MD_NODE_XDMA "ep_xdma_00"
> +#define XRT_MD_NODE_MSIX "ep_msix_00"
> +#define XRT_MD_NODE_QDMA "ep_qdma_00"
> +#define XRT_MD_XRT_MD_NODE_QDMA4 "ep_qdma4_00"
> +#define XRT_MD_NODE_STM "ep_stream_traffic_manager_00"
> +#define XRT_MD_NODE_STM4 "ep_stream_traffic_manager4_00"
> +#define XRT_MD_NODE_CLK_SHUTDOWN "ep_aclk_shutdown_00"
> +#define XRT_MD_NODE_ERT_BASE "ep_ert_base_address_00"
> +#define XRT_MD_NODE_ERT_RESET "ep_ert_reset_00"
> +#define XRT_MD_NODE_CLKFREQ_K1 "ep_freq_cnt_aclk_kernel_00"
> +#define XRT_MD_NODE_CLKFREQ_K2 "ep_freq_cnt_aclk_kernel_01"
> +#define XRT_MD_NODE_CLKFREQ_HBM "ep_freq_cnt_aclk_hbm_00"
> +#define XRT_MD_NODE_GAPPING "ep_gapping_demand_00"
> +#define XRT_MD_NODE_UCS_CONTROL_STATUS "ep_ucs_control_status_00"
> +#define XRT_MD_NODE_P2P "ep_p2p_00"
> +#define XRT_MD_NODE_REMAP_P2P "ep_remap_p2p_00"
> +#define XRT_MD_NODE_DDR4_RESET_GATE "ep_ddr_mem_srsr_gate_00"
> +#define XRT_MD_NODE_ADDR_TRANSLATOR "ep_remap_data_c2h_00"
> +#define XRT_MD_NODE_MAILBOX_XRT 

Re: [PATCH V3 XRT Alveo 01/18] Documentation: fpga: Add a document describing XRT Alveo drivers

[Tom Rix]

>From the documentation, there are a couple of big questions and a bunch of 
>word smithing.

pseudo-bus : do we need a bus ?

xrt-lib real platform devices that aren't fpga, do they need to move to another 
subsystem ?

Overall looks good, love the ascii art!

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Describe XRT driver architecture and provide basic overview of
> Xilinx Alveo platform.
>
> Signed-off-by: Sonal Santan 
> Signed-off-by: Max Zhen 
> Signed-off-by: Lizhi Hou 
> ---
>  Documentation/fpga/index.rst |   1 +
>  Documentation/fpga/xrt.rst   | 842 +++
>  2 files changed, 843 insertions(+)
>  create mode 100644 Documentation/fpga/xrt.rst
>
> diff --git a/Documentation/fpga/index.rst b/Documentation/fpga/index.rst
> index f80f95667ca2..30134357b70d 100644
> --- a/Documentation/fpga/index.rst
> +++ b/Documentation/fpga/index.rst
> @@ -8,6 +8,7 @@ fpga
>  :maxdepth: 1
>  
>  dfl
> +xrt
>  
>  .. only::  subproject and html
>  
> diff --git a/Documentation/fpga/xrt.rst b/Documentation/fpga/xrt.rst
> new file mode 100644
> index ..9bc2d2785cb9
> --- /dev/null
> +++ b/Documentation/fpga/xrt.rst
> @@ -0,0 +1,842 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==
> +XRTV2 Linux Kernel Driver Overview
> +==
> +
> +Authors:
> +
> +* Sonal Santan 
> +* Max Zhen 
> +* Lizhi Hou 
> +
> +XRTV2 drivers are second generation `XRT `_
> +drivers which support `Alveo 
> `_
> +PCIe platforms from Xilinx.
> +
> +XRTV2 drivers support *subsystem* style data driven platforms where driver's
where the driver's
> +configuration and behavior is determined by meta data provided by the 
> platform
> +(in *device tree* format). Primary management physical function (MPF) driver
> +is called **xmgmt**. Primary user physical function (UPF) driver is called
> +**xuser** and is under development. xrt driver framework and HW subsystem
> +drivers are packaged into a library module called **xrt-lib**, which is
> +shared by **xmgmt** and **xuser** (under development). The xrt driver 
> framework
xuser still under development ?
> +implements a pseudo-bus which is used to discover HW subsystems and 
> facilitate

A pseudo-bus.

It would be good if this was close to what was done for dfl here

https://lore.kernel.org/linux-fpga/1605159759-3439-1-git-send-email-yilun...@intel.com/

> +inter HW subsystem interaction.
> +
> +Driver Modules
> +==
> +
> +xrt-lib.ko
> +--
> +
> +Repository of all subsystem drivers and pure software modules that can 
> potentially

subsystem drivers

drivers in fpga/ should be for managing just the fpganess of the fpga.

soft devices ex/ a soft tty should go to their respective subsystem location

Are there any in this patchset you think might move ?

Maybe we can defer reviewing those now.

> +be shared between xmgmt and xuser. All these drivers are structured as Linux
> +*platform driver* and are instantiated by xmgmt (or xuser under development) 
> based
> +on meta data associated with hardware. The metadata is in the form of device 
> tree

with the hardware

form of a device tree

> +as mentioned before. Each platform driver statically defines a subsystem node
> +array by using node name or a string in its ``compatible`` property. And this
> +array is eventually translated to IOMEM resources of the platform device.
> +
> +The xrt-lib core infrastructure provides hooks to platform drivers for 
> device node
> +management, user file operations and ioctl callbacks. The core also provides 
> pseudo-bus
> +functionality for platform driver registration, discovery and inter platform 
> driver
> +ioctl calls.

core infrastructure.

The interfaces to the infrastructure are not in include/linux/fpga/

Maybe this needs to change.

> +
> +.. note::
> +   See code in ``include/xleaf.h``
> +
> +
> +xmgmt.ko
> +
> +
> +The xmgmt driver is a PCIe device driver driving MPF found on Xilinx's Alveo
> +PCIE device. It consists of one *root* driver, one or more *group* drivers
> +and one or more *xleaf* drivers. The root and MPF specific xleaf drivers are
> +in xmgmt.ko. The group driver and other xleaf drivers are in xrt-lib.ko.
I am not sure if *.ko is correct, these will also be intree.
> +
> +The instantiation of specific group driver or xleaf driver is completely data
of a specific
> +driven based on meta data (mostly in device tree format) found through VSEC
mostly ? what is the deviation from device tree ?
> +capability and inside firmware files, such as platform xsabin or user xclbin 
> file.
> +The root driver manages life cycle of multiple group drivers, which, in turn,
the life cycle
> +manages multiple xleaf drivers. This allows a single set of driver code to 
> support

set of drivers

drop 'code'

> +all kinds of subsystems exposed by different shells. The difference among all
> 

Re: [PATCH V3 XRT Alveo 00/18] XRT Alveo driver overview

[Tom Rix]

On 2/17/21 10:40 PM, Lizhi Hou wrote:
> Hello,
>
> This is V3 of patch series which adds management physical function driver for 
> Xilinx
> Alveo PCIe accelerator cards, 
> https://www.xilinx.com/products/boards-and-kits/alveo.html
> This driver is part of Xilinx Runtime (XRT) open source stack.
>
> XILINX ALVEO PLATFORM ARCHITECTURE

Thanks for refreshing this patchset.

It will take me a while to do the full review, so I thought I would give some 
early feed back.

It applies to char-misc-next, but will have conflicts with in-flight patches 
around the MAINTAINERS file. This is not a big deal.

The checkpatch is much better over v2, the complaints are

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21:
new file mode 100644

WARNING: From:/Signed-off-by: email address mismatch: 'From: Lizhi Hou 
' != 'Signed-off-by: Lizhi Hou '

MAINTAINERS warning i believe you address in the last patch.

In the next revisions, please fix the signoff.

The test robot is complaining about hppa64.  While it may be an unlikely 
config, it would be best to fix it.

Tom

>
> Alveo PCIe FPGA based platforms have a static *shell* partition and a partial
> re-configurable *user* partition. The shell partition is automatically loaded 
> from
> flash when host is booted and PCIe is enumerated by BIOS. Shell cannot be 
> changed
> till the next cold reboot. The shell exposes two PCIe physical functions:
>
> 1. management physical function
> 2. user physical function
>
> The patch series includes Documentation/xrt.rst which describes Alveo 
> platform,
> XRT driver architecture and deployment model in more detail.
>
> Users compile their high level design in C/C++/OpenCL or RTL into FPGA image 
> using
> Vitis https://www.xilinx.com/products/design-tools/vitis/vitis-platform.html
> tools. The compiled image is packaged as xclbin which contains partial 
> bitstream
> for the user partition and necessary metadata. Users can dynamically swap the 
> image
> running on the user partition in order to switch between different workloads 
> by
> loading different xclbins.
>
> XRT DRIVERS FOR XILINX ALVEO
>
> XRT Linux kernel driver *xmgmt* binds to management physical function of Alveo
> platform. The modular driver framework is organized into several platform 
> drivers
> which primarily handle the following functionality:
>
> 1.  Loading firmware container also called xsabin at driver attach time
> 2.  Loading of user compiled xclbin with FPGA Manager integration
> 3.  Clock scaling of image running on user partition
> 4.  In-band sensors: temp, voltage, power, etc.
> 5.  Device reset and rescan
>
> The platform drivers are packaged into *xrt-lib* helper module with well
> defined interfaces. The module provides a pseudo-bus implementation for the
> platform drivers. More details on the driver model can be found in
> Documentation/xrt.rst.
>
> User physical function driver is not included in this patch series.
>
> LIBFDT REQUIREMENT
>
> XRT driver infrastructure uses Device Tree as a metadata format to discover
> HW subsystems in the Alveo PCIe device. The Device Tree schema used by XRT
> is documented in Documentation/xrt.rst. Unlike previous V1 and V2 version
> of patch series, V3 version does not require export of libfdt symbols.
>
> TESTING AND VALIDATION
>
> xmgmt driver can be tested with full XRT open source stack which includes user
> space libraries, board utilities and (out of tree) first generation user 
> physical
> function driver xocl. XRT open source runtime stack is available at
> https://github.com/Xilinx/XRT
>
> Complete documentation for XRT open source stack including sections on 
> Alveo/XRT
> security and platform architecture can be found here:
>
> https://xilinx.github.io/XRT/master/html/index.html
> https://xilinx.github.io/XRT/master/html/security.html
> https://xilinx.github.io/XRT/master/html/platforms_partitions.html
>
> Changes since v2:
> - Streamlined the driver framework into *xleaf*, *group* and *xroot*
> - Updated documentation to show the driver model with examples
> - Addressed kernel test robot errors
> - Added a selftest for basic driver framework
> - Documented device tree schema
> - Removed need to export libfdt symbols
>
> Changes since v1:
> - Updated the driver to use fpga_region and fpga_bridge for FPGA
>   programming
> - Dropped platform drivers not related to PR programming to focus on XRT
>   core framework
> - Updated Documentation/fpga/xrt.rst with information on XRT core framework
> - Addressed checkpatch issues
> - Dropped xrt- prefix from some header files
>
> For reference V1 version of patch series can be found here:
>
> https://lore.kernel.org/lkml/20201217075046.28553-1-son...@xilinx.com/
> https://lore.kernel.org/lkml/20201217075046.28553-2-son...@xilinx.com/
> https://lore.kernel.org/lkml/20201217075046.28553-3-son...@xilinx.com/
> https://lore.kernel.org/lkml/20201217075046.28553-4-son...@xilinx.com/
> 

Re: [PATCH] ASoC: Intel: Skylake: Fix missing check in skl_pcm_trigger

[Tom Rix]

On 2/15/21 7:13 AM, Dinghao Liu wrote:
> When cmd == SNDRV_PCM_TRIGGER_STOP, we should also check
> the return value of skl_decoupled_trigger() just like what
> we have done in case SNDRV_PCM_TRIGGER_PAUSE_RELEASE.
>
> Signed-off-by: Dinghao Liu 
> ---
>  sound/soc/intel/skylake/skl-pcm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/sound/soc/intel/skylake/skl-pcm.c 
> b/sound/soc/intel/skylake/skl-pcm.c
> index b1ca64d2f7ea..a5b1f333a500 100644
> --- a/sound/soc/intel/skylake/skl-pcm.c
> +++ b/sound/soc/intel/skylake/skl-pcm.c
> @@ -516,6 +516,9 @@ static int skl_pcm_trigger(struct snd_pcm_substream 
> *substream, int cmd,
>   return ret;

Is there any additional error handling to be done for the

skl_stop_pipe that just happened ?

Tom

>  
>   ret = skl_decoupled_trigger(substream, cmd);
> + if (ret < 0)
> + return ret;
> +
>   if ((cmd == SNDRV_PCM_TRIGGER_SUSPEND) && !w->ignore_suspend) {
>   /* save the dpib and lpib positions */
>   stream->dpib = readl(bus->remap_addr +

Re: [PATCH v9 0/7] FPGA Security Manager Class Driver

[Tom Rix]

Russ, Moritz

This patchset still applies.

Updating the fpga is a fairly important feature.

Are there any dependencies we are waiting on ?

Tom

On 1/5/21 2:59 PM, Russ Weight wrote:
> The FPGA Security Manager class driver provides a common
> API for user-space tools to manage updates for secure FPGA
> devices. Device drivers that instantiate the FPGA Security
> Manager class driver will interact with a 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.
>
> A significant difference between the FPGA Manager and the FPGA 
> Security Manager is that the FPGA Manager does a live update (Partial
> Reconfiguration) to a device whereas the FPGA Security Manager
> updates the FLASH images for the Static Region and the BMC so that
> they will be loaded the next time the FPGA card boots. Security is
> enforced by hardware and firmware. The security manager interacts
> with the firmware to initiate an update, pass in the necessary data,
> and collect status on the update.
>
> The n3000bmc-secure driver is the first driver to use the FPGA
> Security Manager. This driver was previously submitted in the same
> patch set, but has been split out into a separate patch set starting
> with V2. Future devices will also make use of this common API for
> secure updates.
>
> In addition to managing secure updates of the FPGA and BMC images,
> the FPGA Security Manager update process may also be used to
> program root entry hashes and cancellation keys for the FPGA static
> region, the FPGA partial reconfiguration region, and the BMC.
> The image files are self-describing, and contain a header describing
> the image type.
>
> 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.
>
> The API includes a "name" sysfs file to export the name of the parent
> driver. It also includes an "update" sub-directory containing files that
> that can be used to instantiate and monitor a secure update.
>
> Changelog v8 -> v9:
>   - Rebased patches for 5.11-rc2
>   - Updated Date and KernelVersion in ABI documentation
>
> Changelog v7 -> v8:
>   - Fixed grammatical error in Documentation/fpga/fpga-sec-mgr.rst
>
> Changelog v6 -> v7:
>   - Changed dates in documentation file to December 2020
>   - Changed filename_store() to use kmemdup_nul() instead of
> kstrndup() and changed the count to not assume a line-return.
>
> Changelog v5 -> v6:
>   - Removed sysfs support and documentation for the display of the
> flash count, root entry hashes, and code-signing-key cancelation
> vectors from the class driver. This information can vary by device
> and will instead be displayed by the device-specific parent driver.
>
> Changelog v4 -> v5:
>   - Added the devm_fpga_sec_mgr_unregister() function, following recent
> changes to the fpga_manager() implementation.
>   - Changed most of the *_show() functions to use sysfs_emit()
> instead of sprintf(
>   - When checking the return values for functions of type enum
> fpga_sec_err err_code, test for FPGA_SEC_ERR_NONE instead of 0
>
> Changelog v3 -> v4:
>   - This driver is generic enough that it could be used for non Intel
> FPGA devices. Changed from "Intel FPGA Security Manager" to FPGA
> Security Manager" and removed unnecessary references to "Intel".
>   - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_
> Note that this also affects some filenames.
>
> Changelog v2 -> v3:
>   - Use dev_err() to report invalid progress in sec_progress()
>   - Use dev_err() to report invalid error code in sec_error()
>   - Modified sysfs handler check in check_sysfs_handler() to make
> it more readable.
>   - Removed unnecessary "goto done"
>   - Added a comment to explain imgr->driver_unload in
> ifpga_sec_mgr_unregister()
>
> Changelog v1 -> v2:
>   - Separated out the MAX10 BMC Security Engine to be submitted in
> a separate patch-set.
>   - Bumped documentation dates and versions
>   - Split ifpga_sec_mgr_register() into create() and register() functions
>   - Added devm_ifpga_sec_mgr_create()
>   - Added Documentation/fpga/ifpga-sec-mgr.rst 
>   - Changed progress state "read_file" to "reading"
>   - Added sec_error() function (similar to sec_progress())
>   - Removed references to bmc_flash_count & smbus_flash_count (not supported)
>   - Removed typedefs for imgr ops
>   - Removed explicit value assignments in enums
>   - Other minor code cleanup per review comments 
>
> Russ Weight (7):
>   fpga: sec-mgr: fpga security manager class driver
>   fpga: sec-mgr: enable secure updates
>   fpga: sec-mgr: 

Re: [PATCHv5 1/7] firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0

[Tom Rix]

On 2/15/21 6:41 AM, Richard Gong wrote:
> Hi Tom,
>
> On 2/13/21 9:44 AM, Tom Rix wrote:
>>
>> On 2/9/21 2:20 PM, richard.g...@linux.intel.com wrote:
>>> From: Richard Gong 
>>>
>>> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
>>> aligns with the firmware settings.
>>>
>>> Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and 
>>> timeout values")
>>> Signed-off-by: Richard Gong 
>>> ---
>>> v5: new add, add the missing standalone patch
>>> ---
>>>   include/linux/firmware/intel/stratix10-svc-client.h | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
>>> b/include/linux/firmware/intel/stratix10-svc-client.h
>>> index a93d859..f843c6a 100644
>>> --- a/include/linux/firmware/intel/stratix10-svc-client.h
>>> +++ b/include/linux/firmware/intel/stratix10-svc-client.h
>>> @@ -56,7 +56,7 @@
>>>    * COMMAND_RECONFIG_FLAG_PARTIAL:
>>>    * Set to FPGA configuration type (full or partial).
>>>    */
>>> -#define COMMAND_RECONFIG_FLAG_PARTIAL    1
>>> +#define COMMAND_RECONFIG_FLAG_PARTIAL    0
>>
>> Is this the stand alone fix split from v3's patch 1 ?
>>
>> https://lore.kernel.org/linux-fpga/ybfw50lpp%2fyeb...@kroah.com/
>> Yes, it is a stand-alone patch.

Thanks.

Reviewed-by: Tom Rix 

>
>> Tom
>>
>>>     /**
>>>    * Timeout settings for service clients:
>>
> Regards,
> Richard
>

Re: [PATCHv5 1/7] firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0

[Tom Rix]

On 2/9/21 2:20 PM, richard.g...@linux.intel.com wrote:
> From: Richard Gong 
>
> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
> aligns with the firmware settings.
>
> Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and 
> timeout values")
> Signed-off-by: Richard Gong 
> ---
> v5: new add, add the missing standalone patch
> ---
>  include/linux/firmware/intel/stratix10-svc-client.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
> b/include/linux/firmware/intel/stratix10-svc-client.h
> index a93d859..f843c6a 100644
> --- a/include/linux/firmware/intel/stratix10-svc-client.h
> +++ b/include/linux/firmware/intel/stratix10-svc-client.h
> @@ -56,7 +56,7 @@
>   * COMMAND_RECONFIG_FLAG_PARTIAL:
>   * Set to FPGA configuration type (full or partial).
>   */
> -#define COMMAND_RECONFIG_FLAG_PARTIAL1
> +#define COMMAND_RECONFIG_FLAG_PARTIAL0

Is this the stand alone fix split from v3's patch 1 ?

https://lore.kernel.org/linux-fpga/ybfw50lpp%2fyeb...@kroah.com/

Tom

>  
>  /**
>   * Timeout settings for service clients:

Re: [PATCH 2/2] clk: axi-clkgen: Add support for FPGA info

[Tom Rix]

On 2/10/21 2:15 AM, Alexandru Ardelean wrote:
> From: Mircea Caprioru 
>
> This patch adds support for vco maximum and minimum ranges in accordance
> with fpga speed grade, voltage, device package, technology and family. This
> new information is extracted from two new registers implemented in the ip
> core: ADI_REG_FPGA_INFO and ADI_REG_FPGA_VOLTAGE, which are stored in the
> 'include/linux/fpga/adi-axi-common.h' file as they are common to all ADI
> FPGA cores.
>
> Signed-off-by: Mircea Caprioru 
> Signed-off-by: Alexandru Ardelean 
> ---
>  drivers/clk/clk-axi-clkgen.c | 52 +++-
>  1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c
> index ac6ff736ac8f..e4d6c87f8a07 100644
> --- a/drivers/clk/clk-axi-clkgen.c
> +++ b/drivers/clk/clk-axi-clkgen.c
> @@ -8,6 +8,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -240,6 +241,50 @@ static void axi_clkgen_read(struct axi_clkgen 
> *axi_clkgen,
>   *val = readl(axi_clkgen->base + reg);
>  }
>  
> +static void axi_clkgen_setup_ranges(struct axi_clkgen *axi_clkgen)
> +{
> + struct axi_clkgen_limits *limits = _clkgen->limits;
> + unsigned int reg_value;
> + unsigned int tech, family, speed_grade, voltage;
> +
> + axi_clkgen_read(axi_clkgen, ADI_AXI_REG_FPGA_INFO, _value);
> + tech = ADI_AXI_INFO_FPGA_TECH(reg_value);
> + family = ADI_AXI_INFO_FPGA_FAMILY(reg_value);
> + speed_grade = ADI_AXI_INFO_FPGA_SPEED_GRADE(reg_value);
> +
> + axi_clkgen_read(axi_clkgen, ADI_AXI_REG_FPGA_VOLTAGE, _value);
> + voltage = ADI_AXI_INFO_FPGA_VOLTAGE(reg_value);
> +
> + switch (speed_grade) {
> + case ADI_AXI_FPGA_SPEED_GRADE_XILINX_1 ... 
> ADI_AXI_FPGA_SPEED_GRADE_XILINX_1LV:
> + limits->fvco_max = 120;
> + limits->fpfd_max = 45;
> + break;
> + case ADI_AXI_FPGA_SPEED_GRADE_XILINX_2 ... 
> ADI_AXI_FPGA_SPEED_GRADE_XILINX_2LV:
> + limits->fvco_max = 144;
> + limits->fpfd_max = 50;
> + if ((family == ADI_AXI_FPGA_FAMILY_XILINX_KINTEX) |
> + (family == ADI_AXI_FPGA_FAMILY_XILINX_ARTIX)) {
NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.
3a419c9317b157ef06ca347b7e6bbab846a3d605 clk: axi-clkgen: Add support for FPGA 
info
CHECK: Unnecessary parentheses around 'family == 
ADI_AXI_FPGA_FAMILY_XILINX_KINTEX'
#57: FILE: drivers/clk/clk-axi-clkgen.c:266:
+        if ((family == ADI_AXI_FPGA_FAMILY_XILINX_KINTEX) |
+            (family == ADI_AXI_FPGA_FAMILY_XILINX_ARTIX)) {

Please use checkpatch -strict to find this problem.

Likely the '|', should be '||'

Tom

> + if (voltage < 950) {
> + limits->fvco_max = 120;
> + limits->fpfd_max = 45;
> + }
> + }
> + break;
> + case ADI_AXI_FPGA_SPEED_GRADE_XILINX_3:
> + limits->fvco_max = 160;
> + limits->fpfd_max = 55;
> + break;
> + default:
> + break;
> + };
> +
> + if (tech == ADI_AXI_FPGA_TECH_XILINX_ULTRASCALE_PLUS) {
> + limits->fvco_max = 160;
> + limits->fvco_min = 80;
> + }
> +}
> +
>  static int axi_clkgen_wait_non_busy(struct axi_clkgen *axi_clkgen)
>  {
>   unsigned int timeout = 1;
> @@ -510,7 +555,7 @@ static int axi_clkgen_probe(struct platform_device *pdev)
>   struct clk_init_data init;
>   const char *parent_names[2];
>   const char *clk_name;
> - unsigned int i;
> + unsigned int i, ver;
>   int ret;
>  
>   dflt_limits = device_get_match_data(>dev);
> @@ -537,6 +582,11 @@ static int axi_clkgen_probe(struct platform_device *pdev)
>  
>   memcpy(_clkgen->limits, dflt_limits, sizeof(axi_clkgen->limits));
>  
> + axi_clkgen_read(axi_clkgen, ADI_AXI_REG_VERSION, );
> +
> + if (ADI_AXI_PCORE_VER_MAJOR(ver) > 0x04)
> + axi_clkgen_setup_ranges(axi_clkgen);
> +
>   clk_name = pdev->dev.of_node->name;
>   of_property_read_string(pdev->dev.of_node, "clock-output-names",
>   _name);

Re: [PATCH v9 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Tom Rix]

On 1/25/21 6:22 PM, Moritz Fischer wrote:
> On Mon, Jan 25, 2021 at 11:00:38AM -0800, Tom Rix wrote:
Snip
>>
>>> +   depends on FPGA_DFL
>>> +   help
>>> + Generic DFL (Device Feature List) driver for Userspace I/O devices.
>>> + It is useful to provide direct access to DFL devices from userspace.
>>> + A sample userspace application using this driver is available for
>>> + download in a git repository:
>>> +
>>> +   git clone https://github.com/OPAE/opae-sdk.git
>>> +
>>> + If you compile this as a module, it will be called uio_dfl.
> I'm not sure KConfig is the right place for this.

More than half of the other configs do this.

ex/

config UIO_MF624
    tristate "Humusoft MF624 DAQ PCI card driver"
    depends on PCI
    help
      Userspace I/O interface for the Humusoft MF624 PCI card.
      A sample userspace application using this driver is available
      (among other MF624 related information and software components)
      for download in a git repository:

        git clone git://rtime.felk.cvut.cz/mf6xx.git

      If you compile this as a module, it will be called uio_mf624.

Tom

>> opae-sdk is pretty large and uncovered in the Documentation/fpga/dfl.rst.
>>
>> Where in opae-sdk is this example ?
>>
>> If you can point me at the example, I will turn it into a selftest.
>>
>> Tom
>>
>>>  endif
>>> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
>>> index c285dd2..f2f416a1 100644
>>> --- a/drivers/uio/Makefile
>>> +++ b/drivers/uio/Makefile
>>> @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>>>  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>>>  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
>>>  obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
>>> +obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
>>> diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
>>> new file mode 100644
>>> index 000..89c0fc7
>>> --- /dev/null
>>> +++ b/drivers/uio/uio_dfl.c
>>> @@ -0,0 +1,66 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Generic DFL driver for Userspace I/O devicess
>>> + *
>>> + * Copyright (C) 2021 Intel Corporation, Inc.
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DRIVER_NAME "uio_dfl"
>>> +
>>> +static int uio_dfl_probe(struct dfl_device *ddev)
>>> +{
>>> +   struct resource *r = >mmio_res;
>>> +   struct device *dev = >dev;
>>> +   struct uio_info *uioinfo;
>>> +   struct uio_mem *uiomem;
>>> +   int ret;
>>> +
>>> +   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
>>> +   if (!uioinfo)
>>> +   return -ENOMEM;
>>> +
>>> +   uioinfo->name = DRIVER_NAME;
>>> +   uioinfo->version = "0";
>>> +
>>> +   uiomem = >mem[0];
>>> +   uiomem->memtype = UIO_MEM_PHYS;
>>> +   uiomem->addr = r->start & PAGE_MASK;
>>> +   uiomem->offs = r->start & ~PAGE_MASK;
>>> +   uiomem->size = (uiomem->offs + resource_size(r)
>>> +   + PAGE_SIZE - 1) & PAGE_MASK;
>>> +   uiomem->name = r->name;
>>> +
>>> +   /* Irq is yet to be supported */
>>> +   uioinfo->irq = UIO_IRQ_NONE;
>>> +
>>> +   ret = devm_uio_register_device(dev, uioinfo);
>>> +   if (ret)
>>> +   dev_err(dev, "unable to register uio device\n");
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +#define FME_FEATURE_ID_ETH_GROUP   0x10
>>> +
>>> +static const struct dfl_device_id uio_dfl_ids[] = {
>>> +   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
>>> +   { }
>>> +};
>>> +MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
>>> +
>>> +static struct dfl_driver uio_dfl_driver = {
>>> +   .drv = {
>>> +   .name = DRIVER_NAME,
>>> +   },
>>> +   .id_table   = uio_dfl_ids,
>>> +   .probe  = uio_dfl_probe,
>>> +};
>>> +module_dfl_driver(uio_dfl_driver);
>>> +
>>> +MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
>>> +MODULE_AUTHOR("Intel Corporation");
>>> +MODULE_LICENSE("GPL v2");

Re: [PATCHv2] PCI: Add Silicom Denmark vendor ID

[Tom Rix]

On 2/8/21 7:01 AM, Martin Hundebøll wrote:
> Update pci_ids.h with the vendor ID for Silicom Denmark. The define is
> going to be referenced in driver(s) for FPGA accelerated smart NICs.
>
> Signed-off-by: Martin Hundebøll 
Reviewed-by: Tom Rix 
> ---
>
> Changes since v1:
>  * Align commit message/shortlog with similar changes to pci_ids.h
>
>  include/linux/pci_ids.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index f968fcda338e..c119f0eb41b6 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2589,6 +2589,8 @@
>  
>  #define PCI_VENDOR_ID_REDHAT 0x1b36
>  
> +#define PCI_VENDOR_ID_SILICOM_DENMARK0x1c2c
> +
>  #define PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS  0x1c36
>  
>  #define PCI_VENDOR_ID_CIRCUITCO  0x1cc8

Re: [PATCH v3 1/1] fpga: dfl: afu: harden port enable logic

[Tom Rix]

On 2/3/21 3:06 PM, Russ Weight wrote:
>
> On 2/3/21 7:25 AM, Tom Rix wrote:
>> ..snip..
>>
>> On 2/2/21 3:06 PM, Russ Weight wrote:
>>> diff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl-afu.h
>>> index 576e94960086..e5020e2b1f3d 100644
>>> --- a/drivers/fpga/dfl-afu.h
>>> +++ b/drivers/fpga/dfl-afu.h
>>> @@ -80,7 +80,7 @@ struct dfl_afu {
>>>  };
>>>  
>>>  /* hold pdata->lock when call __afu_port_enable/disable */
>>> -void __afu_port_enable(struct platform_device *pdev);
>>> +int __afu_port_enable(struct platform_device *pdev);
>>>  int __afu_port_disable(struct platform_device *pdev);
>>>  
>> Should the '__' prefix be removed from __afu_port* ?
>>
>> This would make the function names consistent with the other decls
> The '__' prefix is used here to help highlight the fact that these functions 
> go not manage
> the locking themselves and must be called while holding the port mutex. There 
> are additional
> functions, such as__port_reset(), that are following this same convention. I 
> think these
> are OK as they are.

ok

Reviewed-by: Tom Rix 

Tom

>
> - Russ
>
>> Tom
>>
>>>  void afu_mmio_region_init(struct dfl_feature_platform_data *pdata);

Re: [PATCH v3 1/1] fpga: dfl: afu: harden port enable logic

[Tom Rix]

..snip..

On 2/2/21 3:06 PM, Russ Weight wrote:
> diff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl-afu.h
> index 576e94960086..e5020e2b1f3d 100644
> --- a/drivers/fpga/dfl-afu.h
> +++ b/drivers/fpga/dfl-afu.h
> @@ -80,7 +80,7 @@ struct dfl_afu {
>  };
>  
>  /* hold pdata->lock when call __afu_port_enable/disable */
> -void __afu_port_enable(struct platform_device *pdev);
> +int __afu_port_enable(struct platform_device *pdev);
>  int __afu_port_disable(struct platform_device *pdev);
>  

Should the '__' prefix be removed from __afu_port* ?

This would make the function names consistent with the other decls

Tom

>  void afu_mmio_region_init(struct dfl_feature_platform_data *pdata);

Re: [PATCH v10 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Tom Rix]

On 1/31/21 9:38 PM, Xu Yilun wrote:
> This patch supports the DFL drivers be written in userspace. This is
> realized by exposing the userspace I/O device interfaces.
>
> The driver now only binds the ether group feature, which has no irq. So
> the irq support is not implemented yet.
>
> Signed-off-by: Xu Yilun 
> ---
> v9: switch to add a uio driver in drivers/uio
> v10: add the source file in MAINTAINERS
>  more descriptive Kconfig header
>  add detailed path for opae uio example
> ---
>  MAINTAINERS   |  1 +
>  drivers/uio/Kconfig   | 17 +
>  drivers/uio/Makefile  |  1 +
>  drivers/uio/uio_dfl.c | 66 
> +++
>  4 files changed, 85 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 147d1d9..4d01a21 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6943,6 +6943,7 @@ S:  Maintained
>  F:   Documentation/ABI/testing/sysfs-bus-dfl*
>  F:   Documentation/fpga/dfl.rst
>  F:   drivers/fpga/dfl*
> +F:   drivers/uio/uio_dfl.c
>  F:   include/linux/dfl.h
>  F:   include/uapi/linux/fpga-dfl.h
>  
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81..5531f3a 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -165,4 +165,21 @@ config UIO_HV_GENERIC
> to network and storage devices from userspace.
>  
> If you compile this as a module, it will be called uio_hv_generic.
> +
> +config UIO_DFL
> + tristate "Generic driver for DFL (Device Feature List) bus"
> + depends on FPGA_DFL
> + help
> +   Generic DFL (Device Feature List) driver for Userspace I/O devices.
> +   It is useful to provide direct access to DFL devices from userspace.
> +   A sample userspace application using this driver is available for
> +   download in a git repository:
> +
> + git clone https://github.com/OPAE/opae-sdk.git
> +
> +   It could be found at:
> +
> + opae-sdk/tools/libopaeuio/

Yes, it is there.  Thanks!

Reviewed-by: Tom Rix 

> +
> +   If you compile this as a module, it will be called uio_dfl.
>  endif
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2..f2f416a1 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)  += uio_fsl_elbc_gpcm.o
>  obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> +obj-$(CONFIG_UIO_DFL)+= uio_dfl.o
> diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
> new file mode 100644
> index 000..89c0fc7
> --- /dev/null
> +++ b/drivers/uio/uio_dfl.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generic DFL driver for Userspace I/O devicess
> + *
> + * Copyright (C) 2021 Intel Corporation, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "uio_dfl"
> +
> +static int uio_dfl_probe(struct dfl_device *ddev)
> +{
> + struct resource *r = >mmio_res;
> + struct device *dev = >dev;
> + struct uio_info *uioinfo;
> + struct uio_mem *uiomem;
> + int ret;
> +
> + uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
> + if (!uioinfo)
> + return -ENOMEM;
> +
> + uioinfo->name = DRIVER_NAME;
> + uioinfo->version = "0";
> +
> + uiomem = >mem[0];
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = r->start & PAGE_MASK;
> + uiomem->offs = r->start & ~PAGE_MASK;
> + uiomem->size = (uiomem->offs + resource_size(r)
> + + PAGE_SIZE - 1) & PAGE_MASK;
> + uiomem->name = r->name;
> +
> + /* Irq is yet to be supported */
> + uioinfo->irq = UIO_IRQ_NONE;
> +
> + ret = devm_uio_register_device(dev, uioinfo);
> + if (ret)
> + dev_err(dev, "unable to register uio device\n");
> +
> + return ret;
> +}
> +
> +#define FME_FEATURE_ID_ETH_GROUP 0x10
> +
> +static const struct dfl_device_id uio_dfl_ids[] = {
> + { FME_ID, FME_FEATURE_ID_ETH_GROUP },
> + { }
> +};
> +MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
> +
> +static struct dfl_driver uio_dfl_driver = {
> + .drv = {
> + .name = DRIVER_NAME,
> + },
> + .id_table   = uio_dfl_ids,
> + .probe  = uio_dfl_probe,
> +};
> +module_dfl_driver(uio_dfl_driver);
> +
> +MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
> +MODULE_AUTHOR("Intel Corporation");
> +MODULE_LICENSE("GPL v2");

Re: [PATCHv1] firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0

[Tom Rix]

On 1/27/21 1:43 PM, richard.g...@linux.intel.com wrote:
> From: Richard Gong 
>
> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
> aligns with the firmware settings.

For fixes, you need to have a 'Fixes: ... ' line in the comment.

This lets folks doing the stable branch know how far back to apply the fix.

For this case, this is likely

Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and 
timeout values")

This should go right above your signoff.


By stand alone patch, this change should be split out from your current 

[PATCHv3 1/6] firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag

So the next rev out your patch set will have 7 patches, because 1/6 is being 
split into two patches.

I would recommend the fix be 1/7, to minimize chance of conflicts merging it 
with stable.

or

submit the split out fix first.

Tom

>
> Signed-off-by: Richard Gong 
> ---
>  include/linux/firmware/intel/stratix10-svc-client.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
> b/include/linux/firmware/intel/stratix10-svc-client.h
> index ebc2956..1ffb982 100644
> --- a/include/linux/firmware/intel/stratix10-svc-client.h
> +++ b/include/linux/firmware/intel/stratix10-svc-client.h
> @@ -51,12 +51,12 @@
>  #define SVC_STATUS_NO_SUPPORT6
>  
>  /*
> - * Flag bit for COMMAND_RECONFIG
> + * Flag for COMMAND_RECONFIG, in bit number
>   *
>   * COMMAND_RECONFIG_FLAG_PARTIAL:
> - * Set to FPGA configuration type (full or partial).
> + * Set for partial configuration.
>   */
> -#define COMMAND_RECONFIG_FLAG_PARTIAL1
> +#define COMMAND_RECONFIG_FLAG_PARTIAL0
>  
>  /*
>   * Timeout settings for service clients:

Re: [PATCH v2 0/3] clk: clk-axiclgen: add support for ZynqMP

[Tom Rix]

On 1/26/21 3:08 AM, Alexandru Ardelean wrote:
> Previous set:
>  
> https://lore.kernel.org/linux-clk/20201221144224.50814-1-alexandru.ardel...@analog.com/
>
> Changelog v1 -> v2:
> * split patch 'clk: axi-clkgen: add support for ZynqMP (UltraScale)'
>   into:
>- clk: axi-clkgen: remove ARCH dependency in Kconfig
>- clk: clk-axiclkgen: add ZynqMP PFD and VCO limits
> * essentially removed the 'adi,zynq-axi-clkgen-2.00.a' compat string
> * removed architecture dependency on build for driver; the driver should
>   be usable also on PCIe setups
>
> Alexandru Ardelean (3):
>   clk: axi-clkgen: remove ARCH dependency in Kconfig
>   clk: clk-axiclkgen: add ZynqMP PFD and VCO limits
>   dt-bindings: clock: adi,axi-clkgen: add compatible string for ZynqMP
> support
>
>  .../devicetree/bindings/clock/adi,axi-clkgen.yaml |  1 +
>  drivers/clk/Kconfig   |  1 -
>  drivers/clk/clk-axi-clkgen.c  | 11 +++
>  3 files changed, 12 insertions(+), 1 deletion(-)

This whole set looks fine.

Reviewed-by: Tom Rix 

Re: [PATCH v2 2/4] mfd: intel-m10-bmc: Simplify the legacy version reg definition

[Tom Rix]

On 1/25/21 10:50 PM, Xu Yilun wrote:
> The version register is the only one in the legacy I/O space to be
> accessed, so it is not necessary to define the legacy base & version
> register offset. A direct definition of the legacy version register
> address would be fine.
>
> Signed-off-by: Xu Yilun 
> ---
>  drivers/mfd/intel-m10-bmc.c   | 12 +---
>  include/linux/mfd/intel-m10-bmc.h |  2 +-
>  2 files changed, 6 insertions(+), 8 deletions(-)

Thanks for adding M10BMC_LEGACY_BUILD_VER

Reviewed-by: Tom Rix 

> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> index b84579b..aad86f0 100644
> --- a/drivers/mfd/intel-m10-bmc.c
> +++ b/drivers/mfd/intel-m10-bmc.c
> @@ -74,16 +74,14 @@ static int check_m10bmc_version(struct intel_m10bmc 
> *ddata)
>  
>   /*
>* This check is to filter out the very old legacy BMC versions,
> -  * M10BMC_LEGACY_SYS_BASE is the offset to this old block of mmio
> -  * registers. In the old BMC chips, the BMC version info is stored
> -  * in this old version register (M10BMC_LEGACY_SYS_BASE +
> -  * M10BMC_BUILD_VER), so its read out value would have not been
> -  * LEGACY_INVALID (0x). But in new BMC chips that the
> +  * 0x300400 is the offset to this old block of mmio registers. In the
> +  * old BMC chips, the BMC version info is stored in this old version
> +  * register (0x300400 + 0x68), so its read out value would have not
> +  * been LEGACY_INVALID (0x). But in new BMC chips that the
>* driver supports, the value of this register should be
>* LEGACY_INVALID.
>*/
> - ret = m10bmc_raw_read(ddata,
> -   M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER, );
> + ret = m10bmc_raw_read(ddata, M10BMC_LEGACY_BUILD_VER, );
>   if (ret)
>   return -ENODEV;
>  
> diff --git a/include/linux/mfd/intel-m10-bmc.h 
> b/include/linux/mfd/intel-m10-bmc.h
> index 06da62c..99f44b1 100644
> --- a/include/linux/mfd/intel-m10-bmc.h
> +++ b/include/linux/mfd/intel-m10-bmc.h
> @@ -9,7 +9,7 @@
>  
>  #include 
>  
> -#define M10BMC_LEGACY_SYS_BASE   0x300400
> +#define M10BMC_LEGACY_BUILD_VER  0x300468
>  #define M10BMC_SYS_BASE  0x300800
>  #define M10BMC_MEM_END   0x1fff
>  

Re: [PATCH v2 4/4] MAINTAINERS: Add entry for Intel MAX 10 mfd driver

[Tom Rix]

On 1/25/21 10:50 PM, Xu Yilun wrote:
> This patch adds maintainer info for Intel MAX 10 mfd driver.
>
> Signed-off-by: Xu Yilun 
> ---
>  MAINTAINERS | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5aa18cb..10985d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9132,6 +9132,15 @@ F: include/linux/mei_cl_bus.h
>  F:   include/uapi/linux/mei.h
>  F:   samples/mei/*
>  

I am interested in reviewing these files like I do with

FPGA DFL DRIVERS

So can you add

R:    Tom Rix 

if you have to rev this patchset ?

Else I will submit a followup.

Reviewed-by: Tom Rix 

> +INTEL MAX 10 BMC MFD DRIVER
> +M:   Xu Yilun 
> +S:   Maintained
> +F:   Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
> +F:   Documentation/hwmon/intel-m10-bmc-hwmon.rst
> +F:   drivers/hwmon/intel-m10-bmc-hwmon.c
> +F:   drivers/mfd/intel-m10-bmc.c
> +F:   include/linux/mfd/intel-m10-bmc.h
> +
>  INTEL MENLOW THERMAL DRIVER
>  M:   Sujith Thomas 
>  L:   platform-driver-...@vger.kernel.org

Re: [PATCH v2 3/4] mfd: intel-m10-bmc: Add access table configuration to the regmap

[Tom Rix]

On 1/25/21 10:50 PM, Xu Yilun wrote:
> From: Matthew Gerlach 
>
> This patch adds access tables to the MAX 10 BMC regmap. This prevents
> the host from accessing the unwanted I/O space. It also filters out the
> invalid outputs when reading the regmap debugfs interface.
>
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Xu Yilun 
> ---
> v2: no change.

v2: Use M10BMC_LEGACY_BUILD_VER

Looks good.

Reviewed-by: Tom Rix 


> ---
>  drivers/mfd/intel-m10-bmc.c   | 13 +
>  include/linux/mfd/intel-m10-bmc.h |  5 -
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> index aad86f0..4240e99 100644
> --- a/drivers/mfd/intel-m10-bmc.c
> +++ b/drivers/mfd/intel-m10-bmc.c
> @@ -23,10 +23,23 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
>   { .name = "n3000bmc-secure" },
>  };
>  
> +static const struct regmap_range m10bmc_regmap_range[] = {
> + regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
> + regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
> + regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
> +};
> +
> +static const struct regmap_access_table m10bmc_access_table = {
> + .yes_ranges = m10bmc_regmap_range,
> + .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
> +};
> +
>  static struct regmap_config intel_m10bmc_regmap_config = {
>   .reg_bits = 32,
>   .val_bits = 32,
>   .reg_stride = 4,
> + .wr_table = _access_table,
> + .rd_table = _access_table,
>   .max_register = M10BMC_MEM_END,
>  };
>  
> diff --git a/include/linux/mfd/intel-m10-bmc.h 
> b/include/linux/mfd/intel-m10-bmc.h
> index 99f44b1..dc2e858 100644
> --- a/include/linux/mfd/intel-m10-bmc.h
> +++ b/include/linux/mfd/intel-m10-bmc.h
> @@ -11,7 +11,10 @@
>  
>  #define M10BMC_LEGACY_BUILD_VER  0x300468
>  #define M10BMC_SYS_BASE  0x300800
> -#define M10BMC_MEM_END   0x1fff
> +#define M10BMC_SYS_END   0x300fff
> +#define M10BMC_FLASH_BASE0x1000
> +#define M10BMC_FLASH_END 0x1fff
> +#define M10BMC_MEM_END   M10BMC_FLASH_END
>  
>  /* Register offset of system registers */
>  #define NIOS2_FW_VERSION 0x0

Re: [PATCH v9 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Tom Rix]

On 1/25/21 6:40 PM, Xu Yilun wrote:
> On Mon, Jan 25, 2021 at 06:22:55PM -0800, Moritz Fischer wrote:
>> On Mon, Jan 25, 2021 at 11:00:38AM -0800, Tom Rix wrote:
>>> On 1/25/21 12:49 AM, Xu Yilun wrote:
>>>> This patch supports the DFL drivers be written in userspace. This is
>>>> realized by exposing the userspace I/O device interfaces.
>>>>
>>>> The driver now only binds the ether group feature, which has no irq. So
>>>> the irq support is not implemented yet.
>>>>
>>>> Signed-off-by: Xu Yilun 
>>>> ---
>>>> v9: switch to add a uio driver in drivers/uio
>>>> ---
>>>>  drivers/uio/Kconfig   | 13 ++
>>>>  drivers/uio/Makefile  |  1 +
>>>>  drivers/uio/uio_dfl.c | 66 
>>>> +++
>>> You should add this to the MAINTAINERS file.
>> This is covered by MAINTAINERS under drivers/uio.
> Yes. But is it OK I also add the file in "FPGA DFL DRIVERS"? So DFL
> developers would also be aware if there is change. It is a little
> different from other feature driver, it is like a generic driver for
> DFL bus.

I think the issue is which maintainer branch this gets merged into.

It would not be linux-fpga.

It is this sort of driver I want to add to FPGA SUBDEVICES list described here

https://lore.kernel.org/linux-fpga/96a9d3d9-6091-47c9-21f9-0cfdd9464...@redhat.com/

Where the driver is maintained in the subsystem but reviewed in linux-fpga.

Tom

>>>>  3 files changed, 80 insertions(+)
>>>>  create mode 100644 drivers/uio/uio_dfl.c
>>>>
>>>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>>>> index 202ee81..44778f8 100644
>>>> --- a/drivers/uio/Kconfig
>>>> +++ b/drivers/uio/Kconfig
>>>> @@ -165,4 +165,17 @@ config UIO_HV_GENERIC
>>>>  to network and storage devices from userspace.
>>>>  
>>>>  If you compile this as a module, it will be called uio_hv_generic.
>>>> +
>>>> +config UIO_DFL
>>>> +  tristate "Generic driver for DFL bus"
>>> The term 'DFL' will be unknown to folks in drivers/uio
>>>
>>> I think it would be better if DFL was always prefixed 'FPGA DFL'
>>>
>>>> +  depends on FPGA_DFL
>>>> +  help
>>>> +Generic DFL (Device Feature List) driver for Userspace I/O devices.
>>>> +It is useful to provide direct access to DFL devices from userspace.
>>>> +A sample userspace application using this driver is available for
>>>> +download in a git repository:
>>>> +
>>>> +  git clone https://github.com/OPAE/opae-sdk.git
>>>> +
>>>> +If you compile this as a module, it will be called uio_dfl.
>> I'm not sure KConfig is the right place for this.
> Do you mean the OPAE link? I see several uio drivers provide their
> userspace application link in Kconfig. I guess the uio drivers are
> selected for these applications so it may be better pointing out where
> they are.
>
> Thanks,
> Yilun
>

Re: [PATCH v9 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Tom Rix]

On 1/25/21 12:49 AM, Xu Yilun wrote:
> This patch supports the DFL drivers be written in userspace. This is
> realized by exposing the userspace I/O device interfaces.
>
> The driver now only binds the ether group feature, which has no irq. So
> the irq support is not implemented yet.
>
> Signed-off-by: Xu Yilun 
> ---
> v9: switch to add a uio driver in drivers/uio
> ---
>  drivers/uio/Kconfig   | 13 ++
>  drivers/uio/Makefile  |  1 +
>  drivers/uio/uio_dfl.c | 66 
> +++

You should add this to the MAINTAINERS file.

>  3 files changed, 80 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81..44778f8 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -165,4 +165,17 @@ config UIO_HV_GENERIC
> to network and storage devices from userspace.
>  
> If you compile this as a module, it will be called uio_hv_generic.
> +
> +config UIO_DFL
> + tristate "Generic driver for DFL bus"

The term 'DFL' will be unknown to folks in drivers/uio

I think it would be better if DFL was always prefixed 'FPGA DFL'

> + depends on FPGA_DFL
> + help
> +   Generic DFL (Device Feature List) driver for Userspace I/O devices.
> +   It is useful to provide direct access to DFL devices from userspace.
> +   A sample userspace application using this driver is available for
> +   download in a git repository:
> +
> + git clone https://github.com/OPAE/opae-sdk.git
> +
> +   If you compile this as a module, it will be called uio_dfl.

opae-sdk is pretty large and uncovered in the Documentation/fpga/dfl.rst.

Where in opae-sdk is this example ?

If you can point me at the example, I will turn it into a selftest.

Tom

>  endif
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2..f2f416a1 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)  += uio_fsl_elbc_gpcm.o
>  obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> +obj-$(CONFIG_UIO_DFL)+= uio_dfl.o
> diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
> new file mode 100644
> index 000..89c0fc7
> --- /dev/null
> +++ b/drivers/uio/uio_dfl.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generic DFL driver for Userspace I/O devicess
> + *
> + * Copyright (C) 2021 Intel Corporation, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "uio_dfl"
> +
> +static int uio_dfl_probe(struct dfl_device *ddev)
> +{
> + struct resource *r = >mmio_res;
> + struct device *dev = >dev;
> + struct uio_info *uioinfo;
> + struct uio_mem *uiomem;
> + int ret;
> +
> + uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
> + if (!uioinfo)
> + return -ENOMEM;
> +
> + uioinfo->name = DRIVER_NAME;
> + uioinfo->version = "0";
> +
> + uiomem = >mem[0];
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = r->start & PAGE_MASK;
> + uiomem->offs = r->start & ~PAGE_MASK;
> + uiomem->size = (uiomem->offs + resource_size(r)
> + + PAGE_SIZE - 1) & PAGE_MASK;
> + uiomem->name = r->name;
> +
> + /* Irq is yet to be supported */
> + uioinfo->irq = UIO_IRQ_NONE;
> +
> + ret = devm_uio_register_device(dev, uioinfo);
> + if (ret)
> + dev_err(dev, "unable to register uio device\n");
> +
> + return ret;
> +}
> +
> +#define FME_FEATURE_ID_ETH_GROUP 0x10
> +
> +static const struct dfl_device_id uio_dfl_ids[] = {
> + { FME_ID, FME_FEATURE_ID_ETH_GROUP },
> + { }
> +};
> +MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
> +
> +static struct dfl_driver uio_dfl_driver = {
> + .drv = {
> + .name = DRIVER_NAME,
> + },
> + .id_table   = uio_dfl_ids,
> + .probe  = uio_dfl_probe,
> +};
> +module_dfl_driver(uio_dfl_driver);
> +
> +MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
> +MODULE_AUTHOR("Intel Corporation");
> +MODULE_LICENSE("GPL v2");

Re: [PATCHv3 1/6] firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag

[Tom Rix]

On 1/25/21 12:56 PM, richard.g...@linux.intel.com wrote:
> From: Richard Gong 
>
> Add COMMAND_AUTHENTICATE_BITSTREAM command flag for new added bitstream
> authentication feature. Authenticating a bitstream is to make sure a signed
> bitstream has the valid signatures.
>
> Except for the actual configuration of the device, the bitstream
> authentication works the same way as FPGA configuration does. If the
> authentication passes, the signed bitstream will be programmed into QSPI
> flash memory and will be expected to boot without issues.
>
> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
> aligns with the firmware settings.
>
> Signed-off-by: Richard Gong 
> ---
> v3: no change
> v2: new added
> ---
>  include/linux/firmware/intel/stratix10-svc-client.h | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
> b/include/linux/firmware/intel/stratix10-svc-client.h
> index ebc2956..7ada1f2 100644
> --- a/include/linux/firmware/intel/stratix10-svc-client.h
> +++ b/include/linux/firmware/intel/stratix10-svc-client.h
> @@ -51,12 +51,17 @@
>  #define SVC_STATUS_NO_SUPPORT6
>  
>  /*

This patch fails to apply, i believe the conflict is because in mainline this 
is '/**' not '/*'

Please check or point me at the branch/tag you are using.

I am using char-misc-next.

Tom

Tom

Re: [PATCH v9 2/2] Documentation: fpga: dfl: Add description for DFL UIO support

[Tom Rix]

On 1/25/21 12:49 AM, Xu Yilun wrote:
> This patch adds description for UIO support for dfl devices on DFL
> bus.
>
> Signed-off-by: Xu Yilun 
> ---
> v2: no doc in v1, add it for v2.
> v3: some documentation fixes.
> v4: documentation change since the driver matching is changed.
> v5: no change.
> v6: improve the title of the userspace driver support section.
> some word improvement.
> v7: rebased to next-20210119
> v8: some doc fixes.
> v9: some doc change since we switch to the driver in drivers/uio.
> ---
>  Documentation/fpga/dfl.rst | 23 +++
>  1 file changed, 23 insertions(+)

This looks fine.

Reviewed-by: Tom Rix 

Re: [PATCH v3] selftests: drivers: fpga: A test for interrupt support

[Tom Rix]

On 1/23/21 8:24 PM, Moritz Fischer wrote:
> Tom,
>
> On Sun, Jan 17, 2021 at 08:18:15AM -0800, t...@redhat.com wrote:
>> From: Tom Rix 
>>
>> Check that the ioctl DFL_FPGA_PORT_ERR_GET_IRQ_NUM returns
>> an expected result.
>>
>> Tested on vf device 0xbcc1
>>
>> Sample run with
>>  # make -C tools/testing/selftests TARGETS=drivers/fpga run_tests
>>  ...
>>  TAP version 13
>>  1..1
>>  # selftests: drivers/fpga: intr
>>  # TAP version 13
>>  # 1..1
>>  # # Starting 1 tests from 1 test cases.
>>  # #  RUN   global.afu_intr ...
>>  # #OK  global.afu_intr
>>  # ok 1 global.afu_intr
>>  # # PASSED: 1 / 1 tests passed.
>>  # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
>>  ok 1 selftests: drivers/fpga: intr
>>
>> Signed-off-by: Tom Rix 
>> ---
>> v1: Convert to kselftest_harness.h framework
>> v2: reverse xmas tree variables
>> ---
>>  MAINTAINERS   |  1 +
>>  tools/testing/selftests/Makefile  |  1 +
>>  tools/testing/selftests/drivers/fpga/Makefile |  7 
>>  tools/testing/selftests/drivers/fpga/config   |  1 +
>>  tools/testing/selftests/drivers/fpga/intr.c   | 36 +++
>>  5 files changed, 46 insertions(+)
>>  create mode 100644 tools/testing/selftests/drivers/fpga/Makefile
>>  create mode 100644 tools/testing/selftests/drivers/fpga/config
>>  create mode 100644 tools/testing/selftests/drivers/fpga/intr.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index de610a06cb5c..7ed3ce58d95e 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6973,6 +6973,7 @@ F: Documentation/driver-api/fpga/
>>  F:  Documentation/fpga/
>>  F:  drivers/fpga/
>>  F:  include/linux/fpga/
>> +F:  tools/testing/selftests/drivers/fpga/
>>  
>>  FPGA SECURITY MANAGER DRIVERS
>>  M:  Russ Weight 
>> diff --git a/tools/testing/selftests/Makefile 
>> b/tools/testing/selftests/Makefile
>> index afbab4aeef3c..aad4763ec348 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -9,6 +9,7 @@ TARGETS += core
>>  TARGETS += cpufreq
>>  TARGETS += cpu-hotplug
>>  TARGETS += drivers/dma-buf
>> +TARGETS += drivers/fpga
>>  TARGETS += efivarfs
>>  TARGETS += exec
>>  TARGETS += filesystems
>> diff --git a/tools/testing/selftests/drivers/fpga/Makefile 
>> b/tools/testing/selftests/drivers/fpga/Makefile
>> new file mode 100644
>> index ..eba35c405d5b
>> --- /dev/null
>> +++ b/tools/testing/selftests/drivers/fpga/Makefile
>> @@ -0,0 +1,7 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +CFLAGS += -I../../../../../usr/include/
>> +CFLAGS += -I../../../../../include/uapi/
>> +
>> +TEST_GEN_PROGS := intr
>> +
>> +include ../../lib.mk
>> diff --git a/tools/testing/selftests/drivers/fpga/config 
>> b/tools/testing/selftests/drivers/fpga/config
>> new file mode 100644
>> index ..e2111b81d8d7
>> --- /dev/null
>> +++ b/tools/testing/selftests/drivers/fpga/config
>> @@ -0,0 +1 @@
>> +CONFIG_FPGA_DFL_AFU=m
>> diff --git a/tools/testing/selftests/drivers/fpga/intr.c 
>> b/tools/testing/selftests/drivers/fpga/intr.c
>> new file mode 100644
>> index ..927dcc757f0b
>> --- /dev/null
>> +++ b/tools/testing/selftests/drivers/fpga/intr.c
>> @@ -0,0 +1,36 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "../../kselftest_harness.h"
>> +
>> +TEST(afu_intr)
>> +{
>> +struct dfl_fpga_port_info port_info;
>> +uint32_t irq_num = UINT32_MAX;
>> +int devfd, status;
>> +
>> +devfd = open("/dev/dfl-port.0", O_RDONLY);
>> +if (devfd < 0)
>> +SKIP(0, "no fpga afu device 0");
>> +/*
>> + * From fpga-dl.h :
>> + * Currently hardware supports up to 1 irq.
>> + * Return: 0 on success, -errno on failure.
>> + */
>> +status = ioctl(devfd, DFL_FPGA_PORT_ERR_GET_IRQ_NUM, _num);
>> +ASSERT_EQ(0, status) {
>> +TH_LOG("ioctl() failed to get the number irqs");
>> +}
>> +ASSERT_LT(irq_num, 256) {
>> +TH_LOG("unexpeced number of irqs");
>> +}
>> +close(devfd);
>> +}
>> +
>> +TEST_HARNESS_MAIN
>> -- 
>> 2.27.0
>>
> Looks good to me, from FPGA perspective, needs Acked-by from Shua, though.
>
> Also, this does not apply to linux-next, or for-5.12 or char-misc-next,
> so I'm confused :)
>
> Once that's sorted, feel free to add

This applied to char-misc-next, at least a couple of days ago, I will check 
again

T

> Acked-by: Moritz Fischer 
>
> - Moritz
>

Re: [PATCH v2] MAINTAINERS: Add FPGA SUBDEVICES

[Tom Rix]

On 1/22/21 3:52 PM, Moritz Fischer wrote:
> On Fri, Jan 22, 2021 at 11:29:28AM -0800, t...@redhat.com wrote:
>> From: Tom Rix 
>>
>> Every FPGA has several subdevices in other subsystems.
>> The new FPGA subdevices section is necessary to ensure changes to
>> the subdevices files get reviewed within the context of the FPGA
>> subsystem.
>>
>> Signed-off-by: Tom Rix 
>> ---
>> v1: Add several more subdevices
>> ---
>>  MAINTAINERS | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 17ac5bdce521..96d6f00b0584 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6975,6 +6975,17 @@ F:drivers/fpga/
>>  F:  include/linux/fpga/
>>  F:  tools/testing/selftests/drivers/fpga/
>>  
>> +FPGA SUBDEVICES
>> +R:  Tom Rix 
>> +L:  linux-f...@vger.kernel.org
>> +S:  Maintained
>> +F:  Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
>> +F:  Documentation/hwmon/intel-m10-bmc-hwmon.rst
>> +F:  drivers/hwmon/intel-m10-bmc-hwmon.c
>> +F:  drivers/memory/dfl-emif.c
>> +F:  drivers/mfd/intel-m10-bmc.c
>> +F:  include/linux/mfd/intel-m10-bmc.h
>> +
>>  FPU EMULATOR
>>  M:  Bill Metzenthen 
>>  S:  Maintained
>> -- 
>> 2.27.0
>>
> All these subsystems have maintainers, I think that's up to them.
> Ideally each of those drivers behaves like a normal device in the
> corresponding subsystem and the way it's implemented doesn't matter.
>
> Plenty of other examples for that
>
> drivers/net/ethernet/xilinx/*

This device has a specific maintainer, the files listed above to do not.

So any review or maintenance falls to the subsystem maintainer who likely is 
not be aware of it fitting within an fpga card.  They certainly will not have 
the hardware to test if the changes effect the card.

So until they have specific maintainers, I would like to help fill that gap by 
making sure they at least have a review.  Sending the changes to the linux-fpga 
mailing list will allow others interested in their specific fpga card to also 
weigh in.

The specific reason for doing this now is several in-flight changes are being 
made to

include/linux/mfd/intel-m10-bmc.h

That effected a couple of fpga subdevices and conflicted with Russ' security 
manager patchset.  To help resolve the conflict I had to track down all the in 
flight changes.  If I had been on the reviewer list for the file or the patch 
had been mirrored to linux-fpga, I would have been notified of the changes 
earlier and finding the conflict would have not been as difficult.

Since we are pushing subdevices to the subsystem, I think we should also be 
encouraging subdevices to be maintained by the submitter and if they are not, 
they get added to the subdevices list so all the work is not done by the 
subsystem maintainers.

Tom

>
> for example.
>
> - Moritz
>

Re: [PATCH 2/2] mfd: intel-m10-bmc: add access table configuration to the regmap

[Tom Rix]

On 1/21/21 12:05 AM, Xu Yilun wrote:
> On Wed, Jan 20, 2021 at 07:32:53AM -0800, Tom Rix wrote:
>> On 1/19/21 6:34 PM, Xu Yilun wrote:
>>> From: Matthew Gerlach 
>>>
>>> This patch adds access tables to the MAX 10 BMC regmap. This prevents
>>> the host from accessing the unwanted I/O space. It also filters out the
>>> invalid outputs when reading the regmap debugfs interface.
>>>
>>> Signed-off-by: Matthew Gerlach 
>>> Signed-off-by: Xu Yilun 
>>> ---
>>>  drivers/mfd/intel-m10-bmc.c   | 14 ++
>>>  include/linux/mfd/intel-m10-bmc.h |  5 -
>>>  2 files changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
>>> index b84579b..0ae3053 100644
>>> --- a/drivers/mfd/intel-m10-bmc.c
>>> +++ b/drivers/mfd/intel-m10-bmc.c
>>> @@ -23,10 +23,24 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
>>> { .name = "n3000bmc-secure" },
>>>  };
>>>  
>>> +static const struct regmap_range m10bmc_regmap_range[] = {
>>> +   regmap_reg_range(M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER,
>>> +M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER),
>> If this is the only value in the legacy map to be accessed, could it have 
>> its own #define ?
>>
>> Something like
>>
>> #define M10BMC_LEGACY_BUILD_VER ?
> Yes, it could be more clear. I'll change it.
>
>>> +   regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
>>> +   regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
>>> +};
>>> +
>>> +static const struct regmap_access_table m10bmc_access_table = {
>>> +   .yes_ranges = m10bmc_regmap_range,
>>> +   .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
>>> +};
>>> +
>>>  static struct regmap_config intel_m10bmc_regmap_config = {
>>> .reg_bits = 32,
>>> .val_bits = 32,
>>> .reg_stride = 4,
>>> +   .wr_table = _access_table,
>>> +   .rd_table = _access_table,
>> The legacy build ver should only be read, so shouldn't these tables be 
>> different ?
> I'm not sure if a register could be regarded as writable if hardware
> ensures writing it has no effect but makes no harm. Usually these
> registers are marked as RO in spec.
>
> I think it could be quite common case in hardware design. But it could
> be trivial if we pick every such register out of wr_table. I just want
> to define the valid reg range.
>
> So could I keep the current implementation?

I mean that the write table would not have first element the read table has 
because it has the single ro entry.

The other ranges i am sure have ro's and are not worth breaking apart.

If something like

.wr_table = _access_table[1] doesn't work or looks to hacky, i don't 
mind leaving it as-is.

Tom

>
> Thanks,
> Yilun
>

Re: [PATCH v6 1/2] fpga: dfl: add the userspace I/O device support for DFL devices

[Tom Rix]

On 1/17/21 8:22 AM, Moritz Fischer wrote:
> Greg,
>
> On Sun, Jan 17, 2021 at 04:45:04PM +0100, Greg KH wrote:
>> On Wed, Jan 13, 2021 at 09:54:07AM +0800, Xu Yilun wrote:
>>> This patch supports the DFL drivers be written in userspace. This is
>>> realized by exposing the userspace I/O device interfaces.
>>>
>>> The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
>>> platform device with the DFL device's resources, and let the generic UIO
>>> platform device driver provide support to userspace access to kernel
>>> interrupts and memory locations.
>> Why doesn't the existing uio driver work for this, why do you need a new
>> one?
>>
>>> ---
>>>  drivers/fpga/Kconfig| 10 +
>>>  drivers/fpga/Makefile   |  1 +
>>>  drivers/fpga/dfl-uio-pdev.c | 93 
>>> +
>> uio drivers traditionally go in drivers/uio/ and start with "uio", so
>> shouldn't this be drivers/uio/uio_dfl_pdev.c to match the same naming
>> scheme?
> I had considered suggesting that, but ultimately this driver only
> creates a 'uio_pdrv_genirq' platform device, so it didn't seem like a
> good fit.
>> But again, you need to explain in detail, why the existing uio driver
>> doesn't work properly, or why you can't just add a few lines to an
>> existing one.
> Ultimately there are three options I see:
> 1) Do what Xu does, which is re-use the 'uio_pdrv_genirq' uio driver by
>   creating a platform device for it as sub-device of the dfl device that
>   we bind to uio_pdrv_genirq
> 2) Add a module_dfl_driver part to drivers/uio/uio_pdrv_genirq.c and
>   corresponding id table
> 3) Create a new uio_dfl_genirq kind of driver that uses the dfl bus and
>   that would make sense to then put into drivers/uio. (This would
>   duplicate code in uio_pdrv_genirq to some extend)
>
> Overall I think in terms of code re-use I think Xu's choice might be
> less new code as it simply wraps the uio platform device driver, and
> allows for defining the resources passed to the UIO driver to be defined
> by hardware through a DFL.
>
> I've seen the pattern that Xu proposed used in other places like the
> macb network driver where you'd have macb_main (the platform driver) and
> macb_pci that wraps it for a pci usage.
>
> - Moritz

Thinking of this problem more generally.

Every fpga will have a handful of sub devices.

Do we want to carry them in the fpga subsystem or carry them in the other 
subsystems ?

Consider the short term reviewing and long term maintenance of the sub devices 
by the subsystem maintainers.

It easier for them if the sub devices are in the other subsystems.


Applying this to specifically for dfl_uio.

No one from the uio subsystem reviewing this change is a problem.

I think this change needs to go to the uio subsystem.

And a new entry in the MAINTAINERS file to keep the fpga subsystem in the loop 
for reviews and acks

Tom

Re: [PATCH 1/2] mfd: intel-m10-bmc: fix the register access range

[Tom Rix]

A side note..

I think it would be good if the intel-m10-bmc.* files were tracked in the 
MAINTAINERS files.

I was surprised the Lee was the only reviewer.  Maybe Yilun or Matt should also 
be added.

On 1/19/21 6:34 PM, Xu Yilun wrote:
> This patch fixes the max register address of MAX 10 BMC. The range
> 0x2000 ~ 0x20fc are for control registers of the QSPI flash
> controller, which are not accessible to host.
>
> Signed-off-by: Xu Yilun 
> ---
>  include/linux/mfd/intel-m10-bmc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mfd/intel-m10-bmc.h 
> b/include/linux/mfd/intel-m10-bmc.h
> index c8ef2f1..06da62c 100644
> --- a/include/linux/mfd/intel-m10-bmc.h
> +++ b/include/linux/mfd/intel-m10-bmc.h
> @@ -11,7 +11,7 @@
>  
>  #define M10BMC_LEGACY_SYS_BASE   0x300400
>  #define M10BMC_SYS_BASE  0x300800
> -#define M10BMC_MEM_END   0x20fc
> +#define M10BMC_MEM_END   0x1fff
Reviewed-by: Tom Rix 
>  
>  /* Register offset of system registers */
>  #define NIOS2_FW_VERSION 0x0

Re: [PATCH 2/2] mfd: intel-m10-bmc: add access table configuration to the regmap

[Tom Rix]

On 1/19/21 6:34 PM, Xu Yilun wrote:
> From: Matthew Gerlach 
>
> This patch adds access tables to the MAX 10 BMC regmap. This prevents
> the host from accessing the unwanted I/O space. It also filters out the
> invalid outputs when reading the regmap debugfs interface.
>
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Xu Yilun 
> ---
>  drivers/mfd/intel-m10-bmc.c   | 14 ++
>  include/linux/mfd/intel-m10-bmc.h |  5 -
>  2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> index b84579b..0ae3053 100644
> --- a/drivers/mfd/intel-m10-bmc.c
> +++ b/drivers/mfd/intel-m10-bmc.c
> @@ -23,10 +23,24 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
>   { .name = "n3000bmc-secure" },
>  };
>  
> +static const struct regmap_range m10bmc_regmap_range[] = {
> + regmap_reg_range(M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER,
> +  M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER),

If this is the only value in the legacy map to be accessed, could it have its 
own #define ?

Something like

#define M10BMC_LEGACY_BUILD_VER ?

> + regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
> + regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
> +};
> +
> +static const struct regmap_access_table m10bmc_access_table = {
> + .yes_ranges = m10bmc_regmap_range,
> + .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
> +};
> +
>  static struct regmap_config intel_m10bmc_regmap_config = {
>   .reg_bits = 32,
>   .val_bits = 32,
>   .reg_stride = 4,
> + .wr_table = _access_table,
> + .rd_table = _access_table,

The legacy build ver should only be read, so shouldn't these tables be 
different ?

Tom

>   .max_register = M10BMC_MEM_END,
>  };
>  
> diff --git a/include/linux/mfd/intel-m10-bmc.h 
> b/include/linux/mfd/intel-m10-bmc.h
> index 06da62c..4ba88ed 100644
> --- a/include/linux/mfd/intel-m10-bmc.h
> +++ b/include/linux/mfd/intel-m10-bmc.h
> @@ -11,7 +11,10 @@
>  
>  #define M10BMC_LEGACY_SYS_BASE   0x300400
>  #define M10BMC_SYS_BASE  0x300800
> -#define M10BMC_MEM_END   0x1fff
> +#define M10BMC_SYS_END   0x300fff
> +#define M10BMC_FLASH_BASE0x1000
> +#define M10BMC_FLASH_END 0x1fff
> +#define M10BMC_MEM_END   M10BMC_FLASH_END
>  
>  /* Register offset of system registers */
>  #define NIOS2_FW_VERSION 0x0

Re: [PATCH v2] iio: imu: bmi160: add mutex_lock for avoiding race

[Tom Rix]

On 1/19/21 5:48 PM, Guoqing Chi wrote:
> On Tue, 19 Jan 2021 06:54:45 -0800
> Tom Rix  wrote:
>
>> On 1/19/21 3:22 AM, Guoqing Chi wrote:
>>> From: chiguoqing 
>>>
>>> Adding mutex_lock, when read and write reg need to use this lock to
>>> avoid race.
>>>
>>> Signed-off-by: Guoqing Chi 
>>> ---
>>> v2:Follow write function to fix read function.
>>> Adding mutex init in core probe function.
>>> Adding break in switch case at read and write function.
>>>
>>>  drivers/iio/imu/bmi160/bmi160.h  |  2 ++
>>>  drivers/iio/imu/bmi160/bmi160_core.c | 34
>>> +++- 2 files changed, 25 insertions(+), 11
>>> deletions(-)
>>>
>>> diff --git a/drivers/iio/imu/bmi160/bmi160.h
>>> b/drivers/iio/imu/bmi160/bmi160.h index 32c2ea2d7112..0c189a8b5b53
>>> 100644 --- a/drivers/iio/imu/bmi160/bmi160.h
>>> +++ b/drivers/iio/imu/bmi160/bmi160.h
>>> @@ -3,9 +3,11 @@
>>>  #define BMI160_H_
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  struct bmi160_data {
>>> +   struct mutex lock;
>>> struct regmap *regmap;
>>> struct iio_trigger *trig;
>>> struct regulator_bulk_data supplies[2];
>>> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c
>>> b/drivers/iio/imu/bmi160/bmi160_core.c index
>>> 290b5ef83f77..e303378f4841 100644 ---
>>> a/drivers/iio/imu/bmi160/bmi160_core.c +++
>>> b/drivers/iio/imu/bmi160/bmi160_core.c @@ -452,26 +452,32 @@ static
>>> int bmi160_read_raw(struct iio_dev *indio_dev, int ret;
>>> struct bmi160_data *data = iio_priv(indio_dev);
>>>  
>>> +   mutex_lock(>lock);
>>> switch (mask) {
>>> case IIO_CHAN_INFO_RAW:
>>> ret = bmi160_get_data(data, chan->type,
>>> chan->channel2, val);
>>> -   if (ret)
>>> -   return ret;
>>> -   return IIO_VAL_INT;
>>> +   if (!ret)
>>> +   ret = IIO_VAL_INT;
>>> +   break;
>>> case IIO_CHAN_INFO_SCALE:
>>> *val = 0;
>>> ret = bmi160_get_scale(data,
>>>bmi160_to_sensor(chan->type),
>>> val2);
>>> -   return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
>>> +   if (!ret)
>>> +   ret = IIO_VAL_INT_PLUS_MICRO;  
>> Looking better, another question..
>>
>> Why does the write() function return the results directly while the
>> read() function
>>
>> translates them to other values ?
>>
>> Tom
> It is original design in this driver. In order to
> differentiate raw to scale and SAMP_FREQ, while the scale and SAMP_FREQ
> are needless. I think log information can be added for this purpose,
> and return results directly.
> It is not change the return values for my modify.It's best to keep the
> original design.Is that all right?

Ok.

Reviewed-by: Tom Rix 

> Guoqing Chi
>>> +   break;
>>> case IIO_CHAN_INFO_SAMP_FREQ:
>>> ret = bmi160_get_odr(data,
>>> bmi160_to_sensor(chan->type), val, val2);
>>> -   return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
>>> +   if (!ret)
>>> +   ret = IIO_VAL_INT_PLUS_MICRO;
>>> +   break;
>>> default:
>>> -   return -EINVAL;
>>> +   ret = -EINVAL;
>>> }
>>> +   mutex_unlock(>lock);
>>>  
>>> -   return 0;
>>> +   return ret;
>>>  }
>>>  
>>>  static int bmi160_write_raw(struct iio_dev *indio_dev,
>>> @@ -479,19 +485,24 @@ static int bmi160_write_raw(struct iio_dev
>>> *indio_dev, int val, int val2, long mask)
>>>  {
>>> struct bmi160_data *data = iio_priv(indio_dev);
>>> +   int result;
>>>  
>>> +   mutex_lock(>lock);
>>> switch (mask) {
>>> case IIO_CHAN_INFO_SCALE:
>>> -   return bmi160_set_scale(data,
>>> +   result = bmi160_set_scale(data,
>>> bmi160_to_sensor(chan->type),
>>> val2);
>>> +   break;
>>> case IIO_CHAN_INFO_SAMP_FREQ:
>>> -   return bmi160_set_odr(data,
>>> bmi160_to_sensor(chan->type),
>>> +   result = bmi160_set_odr(data,
>>> bmi160_to_sensor(chan->type), val, val2);
>>> +   break;
>>> default:
>>> -   return -EINVAL;
>>> +   result = -EINVAL;
>>> }
>>> +   mutex_unlock(>lock);
>>>  
>>> -   return 0;
>>> +   return result;
>>>  }
>>>  
>>>  static
>>> @@ -838,6 +849,7 @@ int bmi160_core_probe(struct device *dev,
>>> struct regmap *regmap, return -ENOMEM;
>>>  
>>> data = iio_priv(indio_dev);
>>> +   mutex_init(>lock);
>>> dev_set_drvdata(dev, indio_dev);
>>> data->regmap = regmap;
>>>

Re: [PATCH] spi: altera: Fix memory leak on error path

[Tom Rix]

On 1/20/21 12:26 AM, Pan Bian wrote:
> Release master that have been previously allocated if the number of
> chipselect is invalid.
>
> Fixes: 8e04187c1bc7 ("spi: altera: add SPI core parameters support via 
> platform data.")
> Signed-off-by: Pan Bian 
> ---
>  drivers/spi/spi-altera.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
> index cbc4c28c1541..62ea0c9e321b 100644
> --- a/drivers/spi/spi-altera.c
> +++ b/drivers/spi/spi-altera.c
> @@ -254,7 +254,8 @@ static int altera_spi_probe(struct platform_device *pdev)
>   dev_err(>dev,
>   "Invalid number of chipselect: %hu\n",
>   pdata->num_chipselect);
> - return -EINVAL;
> + err = -EINVAL;
> + goto exit;
>           }
>  
>   master->num_chipselect = pdata->num_chipselect;
Reviewed-by: Tom Rix 

Re: [PATCH v7 0/6] Intel MAX10 BMC Secure Update Driver

[Tom Rix]

On 1/5/21 3:08 PM, Russ Weight wrote:

...

>  .../testing/sysfs-driver-intel-m10-bmc-secure |  61 ++
>  MAINTAINERS   |   2 +
>  drivers/fpga/Kconfig  |  11 +
>  drivers/fpga/Makefile |   3 +
>  drivers/fpga/intel-m10-bmc-secure.c   | 543 ++
>  include/linux/mfd/intel-m10-bmc.h |  85 +++

I am having trouble pulling this into my testing branch where i am tracking 
some other changes to intel-m10-bmc.h

https://lore.kernel.org/lkml/20210114231648.199685-1-russell.h.wei...@intel.com/

https://lore.kernel.org/lkml/160628-12748-3-git-send-email-yilun...@intel.com/

so I am wondering if it makes sense to split the intel-m10-bmc.h change out of 
this patchset and sent as a single patch to mfd subsystem ?  The change is a 
bunch of #defines that don't do anything on their own, but will conflict with 
other similar additions to the h file.

Tom

>  6 files changed, 705 insertions(+)
>  create mode 100644 
> Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
>  create mode 100644 drivers/fpga/intel-m10-bmc-secure.c
>

Re: [PATCH v2] iio: imu: bmi160: add mutex_lock for avoiding race

[Tom Rix]

On 1/19/21 3:22 AM, Guoqing Chi wrote:
> From: chiguoqing 
>
> Adding mutex_lock, when read and write reg need to use this lock to
> avoid race.
>
> Signed-off-by: Guoqing Chi 
> ---
> v2:Follow write function to fix read function.
> Adding mutex init in core probe function.
> Adding break in switch case at read and write function.
>
>  drivers/iio/imu/bmi160/bmi160.h  |  2 ++
>  drivers/iio/imu/bmi160/bmi160_core.c | 34 +++-
>  2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h
> index 32c2ea2d7112..0c189a8b5b53 100644
> --- a/drivers/iio/imu/bmi160/bmi160.h
> +++ b/drivers/iio/imu/bmi160/bmi160.h
> @@ -3,9 +3,11 @@
>  #define BMI160_H_
>  
>  #include 
> +#include 
>  #include 
>  
>  struct bmi160_data {
> + struct mutex lock;
>   struct regmap *regmap;
>   struct iio_trigger *trig;
>   struct regulator_bulk_data supplies[2];
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c 
> b/drivers/iio/imu/bmi160/bmi160_core.c
> index 290b5ef83f77..e303378f4841 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -452,26 +452,32 @@ static int bmi160_read_raw(struct iio_dev *indio_dev,
>   int ret;
>   struct bmi160_data *data = iio_priv(indio_dev);
>  
> + mutex_lock(>lock);
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
>   ret = bmi160_get_data(data, chan->type, chan->channel2, val);
> - if (ret)
> - return ret;
> - return IIO_VAL_INT;
> + if (!ret)
> + ret = IIO_VAL_INT;
> + break;
>   case IIO_CHAN_INFO_SCALE:
>   *val = 0;
>   ret = bmi160_get_scale(data,
>  bmi160_to_sensor(chan->type), val2);
> - return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
> + if (!ret)
> + ret = IIO_VAL_INT_PLUS_MICRO;

Looking better, another question..

Why does the write() function return the results directly while the read() 
function

translates them to other values ?

Tom

> + break;
>   case IIO_CHAN_INFO_SAMP_FREQ:
>   ret = bmi160_get_odr(data, bmi160_to_sensor(chan->type),
>val, val2);
> - return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
> + if (!ret)
> + ret = IIO_VAL_INT_PLUS_MICRO;
> + break;
>   default:
> - return -EINVAL;
> + ret = -EINVAL;
>   }
> + mutex_unlock(>lock);
>  
> - return 0;
> + return ret;
>  }
>  
>  static int bmi160_write_raw(struct iio_dev *indio_dev,
> @@ -479,19 +485,24 @@ static int bmi160_write_raw(struct iio_dev *indio_dev,
>   int val, int val2, long mask)
>  {
>   struct bmi160_data *data = iio_priv(indio_dev);
> + int result;
>  
> + mutex_lock(>lock);
>   switch (mask) {
>   case IIO_CHAN_INFO_SCALE:
> - return bmi160_set_scale(data,
> + result = bmi160_set_scale(data,
>   bmi160_to_sensor(chan->type), val2);
> + break;
>   case IIO_CHAN_INFO_SAMP_FREQ:
> - return bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> + result = bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> val, val2);
> + break;
>   default:
> - return -EINVAL;
> + result = -EINVAL;
>   }
> + mutex_unlock(>lock);
>  
> - return 0;
> + return result;
>  }
>  
>  static
> @@ -838,6 +849,7 @@ int bmi160_core_probe(struct device *dev, struct regmap 
> *regmap,
>   return -ENOMEM;
>  
>   data = iio_priv(indio_dev);
> + mutex_init(>lock);
>   dev_set_drvdata(dev, indio_dev);
>   data->regmap = regmap;
>  

Re: [PATCH] clocksource: mxs_timer: add missing semicolon when DEBUG is defined

[Tom Rix]

On 1/18/21 7:15 AM, Daniel Lezcano wrote:
> On 18/01/2021 14:49, t...@redhat.com wrote:
>> From: Tom Rix 
>>
>> When DEBUG is defined this error occurs
>>
>> drivers/clocksource/mxs_timer.c:138:1: error:
>>   expected ‘;’ before ‘}’ token
>>
>> The preceding statement needs a semicolon.
>>
>> Fixes: eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' 
>> interface")
>> Signed-off-by: Tom Rix 
>> ---
>>  drivers/clocksource/mxs_timer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/mxs_timer.c 
>> b/drivers/clocksource/mxs_timer.c
>> index bc96a4cbf26c..55aa6b72d075 100644
>> --- a/drivers/clocksource/mxs_timer.c
>> +++ b/drivers/clocksource/mxs_timer.c
>> @@ -133,7 +133,7 @@ static void mxs_irq_clear(char *state)
>>  timrot_irq_acknowledge();
>>  
>>  #ifdef DEBUG
>> -pr_info("%s: changing mode to %s\n", __func__, state)
>> +pr_info("%s: changing mode to %s\n", __func__, state);
>>  #endif /* DEBUG */
> Mind to replace by pr_debug and remove the #ifdef ?
ok.
>
>>  }
>>  
>>
>

Re: [PATCH] iio: imu: bmi160: add mutex_lock for avoiding race

[Tom Rix]

On 1/18/21 2:05 AM, chiguoqing wrote:
> Adding mutex_lock, when read and write reg need to use this lock to
> avoid race.
>
> Signed-off-by: Guoqing Chi 
> ---
>  drivers/iio/imu/bmi160/bmi160.h  |  2 ++
>  drivers/iio/imu/bmi160/bmi160_core.c | 17 +
>  2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h
> index 32c2ea2d7112..0c189a8b5b53 100644
> --- a/drivers/iio/imu/bmi160/bmi160.h
> +++ b/drivers/iio/imu/bmi160/bmi160.h
> @@ -3,9 +3,11 @@
>  #define BMI160_H_
>  
>  #include 
> +#include 
>  #include 
>  
>  struct bmi160_data {
> + struct mutex lock;
where is the mutex_init() ?
>   struct regmap *regmap;
>   struct iio_trigger *trig;
>   struct regulator_bulk_data supplies[2];
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c 
> b/drivers/iio/imu/bmi160/bmi160_core.c
> index 290b5ef83f77..b626e067c612 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -454,18 +454,24 @@ static int bmi160_read_raw(struct iio_dev *indio_dev,

how the read and write functions lock and return are not consistent.

to me, the write function looks better, so change the read function to look 
more like the write function

Tom

>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> + mutex_lock(>lock);
>   ret = bmi160_get_data(data, chan->type, chan->channel2, val);
> + mutex_unlock(>lock);
>   if (ret)
>   return ret;
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_SCALE:
>   *val = 0;
> + mutex_lock(>lock);
>   ret = bmi160_get_scale(data,
>  bmi160_to_sensor(chan->type), val2);
> + mutex_unlock(>lock);
>   return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
>   case IIO_CHAN_INFO_SAMP_FREQ:
> + mutex_lock(>lock);
>   ret = bmi160_get_odr(data, bmi160_to_sensor(chan->type),
>val, val2);
> + mutex_unlock(>lock);
>   return ret ? ret : IIO_VAL_INT_PLUS_MICRO;
>   default:
>   return -EINVAL;
> @@ -479,19 +485,22 @@ static int bmi160_write_raw(struct iio_dev *indio_dev,
>   int val, int val2, long mask)
>  {
>   struct bmi160_data *data = iio_priv(indio_dev);
> + int result;
>  
> + mutex_lock(>lock);
>   switch (mask) {
>   case IIO_CHAN_INFO_SCALE:
> - return bmi160_set_scale(data,
> + result = bmi160_set_scale(data,
>   bmi160_to_sensor(chan->type), val2);
>   case IIO_CHAN_INFO_SAMP_FREQ:
> - return bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> + result = bmi160_set_odr(data, bmi160_to_sensor(chan->type),
> val, val2);
>   default:
> - return -EINVAL;
> + result = -EINVAL;
>   }
> + mutex_unlock(>lock);
>  
> - return 0;
> + return result;
>  }
>  
>  static