* [PATCH 1/8] fpga: dfl: refactor cci_enumerate_feature_devs()
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 2/8] fpga: dfl-pci: locate DFLs by PCIe vendor specific capability Moritz Fischer
` (7 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Matthew Gerlach, Wu Hao
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
In preparation of looking for dfls based on a vendor specific pci
capability, move the code for the default method of finding the first
dfl at offset 0 of Bar 0 to its own function.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Acked-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
drivers/fpga/dfl-pci.c | 84 +++++++++++++++++++++++-------------------
1 file changed, 47 insertions(+), 37 deletions(-)
diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index a2203d03c9e2..5100695e27cd 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -119,49 +119,20 @@ static int *cci_pci_create_irq_table(struct pci_dev *pcidev, unsigned int nvec)
return table;
}
-/* enumerate feature devices under pci device */
-static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
+/* default method of finding dfls starting at offset 0 of bar 0 */
+static int find_dfls_by_default(struct pci_dev *pcidev,
+ struct dfl_fpga_enum_info *info)
{
- struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
- int port_num, bar, i, nvec, ret = 0;
- struct dfl_fpga_enum_info *info;
- struct dfl_fpga_cdev *cdev;
+ int port_num, bar, i, ret = 0;
resource_size_t start, len;
void __iomem *base;
- int *irq_table;
u32 offset;
u64 v;
- /* allocate enumeration info via pci_dev */
- info = dfl_fpga_enum_info_alloc(&pcidev->dev);
- if (!info)
- return -ENOMEM;
-
- /* add irq info for enumeration if the device support irq */
- nvec = cci_pci_alloc_irq(pcidev);
- if (nvec < 0) {
- dev_err(&pcidev->dev, "Fail to alloc irq %d.\n", nvec);
- ret = nvec;
- goto enum_info_free_exit;
- } else if (nvec) {
- irq_table = cci_pci_create_irq_table(pcidev, nvec);
- if (!irq_table) {
- ret = -ENOMEM;
- goto irq_free_exit;
- }
-
- ret = dfl_fpga_enum_info_add_irq(info, nvec, irq_table);
- kfree(irq_table);
- if (ret)
- goto irq_free_exit;
- }
-
- /* start to find Device Feature List in Bar 0 */
+ /* start to find Device Feature List from Bar 0 */
base = cci_pci_ioremap_bar0(pcidev);
- if (!base) {
- ret = -ENOMEM;
- goto irq_free_exit;
- }
+ if (!base)
+ return -ENOMEM;
/*
* PF device has FME and Ports/AFUs, and VF device only has one
@@ -208,12 +179,51 @@ static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
dfl_fpga_enum_info_add_dfl(info, start, len);
} else {
ret = -ENODEV;
- goto irq_free_exit;
}
/* release I/O mappings for next step enumeration */
pcim_iounmap_regions(pcidev, BIT(0));
+ return ret;
+}
+
+/* enumerate feature devices under pci device */
+static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
+{
+ struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
+ struct dfl_fpga_enum_info *info;
+ struct dfl_fpga_cdev *cdev;
+ int nvec, ret = 0;
+ int *irq_table;
+
+ /* allocate enumeration info via pci_dev */
+ info = dfl_fpga_enum_info_alloc(&pcidev->dev);
+ if (!info)
+ return -ENOMEM;
+
+ /* add irq info for enumeration if the device support irq */
+ nvec = cci_pci_alloc_irq(pcidev);
+ if (nvec < 0) {
+ dev_err(&pcidev->dev, "Fail to alloc irq %d.\n", nvec);
+ ret = nvec;
+ goto enum_info_free_exit;
+ } else if (nvec) {
+ irq_table = cci_pci_create_irq_table(pcidev, nvec);
+ if (!irq_table) {
+ ret = -ENOMEM;
+ goto irq_free_exit;
+ }
+
+ ret = dfl_fpga_enum_info_add_irq(info, nvec, irq_table);
+ kfree(irq_table);
+ if (ret)
+ goto irq_free_exit;
+ }
+
+ ret = find_dfls_by_default(pcidev, info);
+ if (ret)
+ goto irq_free_exit;
+
/* start enumeration with prepared enumeration information */
cdev = dfl_fpga_feature_devs_enumerate(info);
if (IS_ERR(cdev)) {
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 2/8] fpga: dfl-pci: locate DFLs by PCIe vendor specific capability
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
2021-01-07 4:37 ` [PATCH 1/8] fpga: dfl: refactor cci_enumerate_feature_devs() Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 3/8] fpga: dfl: fix the definitions of type & feature_id for dfl devices Moritz Fischer
` (6 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer, Matthew Gerlach
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
A PCIe vendor specific extended capability is introduced by Intel to
specify the start of a number of DFLs.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
Documentation/fpga/dfl.rst | 27 ++++++++++++
drivers/fpga/dfl-pci.c | 87 +++++++++++++++++++++++++++++++++++++-
2 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 0404fe6ffc74..ea8cefc18bdb 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -501,6 +501,33 @@ Developer only needs to provide a sub feature driver with matched feature id.
FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
could be a reference.
+Location of DFLs on a PCI Device
+===========================
+The original method for finding a DFL on a PCI device assumed the start of the
+first DFL to offset 0 of bar 0. If the first node of the DFL is an FME,
+then further DFLs in the port(s) are specified in FME header registers.
+Alternatively, a PCIe vendor specific capability structure can be used to
+specify the location of all the DFLs on the device, providing flexibility
+for the type of starting node in the DFL. Intel has reserved the
+VSEC ID of 0x43 for this purpose. The vendor specific
+data begins with a 4 byte vendor specific register for the number of DFLs followed 4 byte
+Offset/BIR vendor specific registers for each DFL. Bits 2:0 of Offset/BIR register
+indicates the BAR, and bits 31:3 form the 8 byte aligned offset where bits 2:0 are
+zero.
+
+ +----------------------------+
+ |31 Number of DFLS 0|
+ +----------------------------+
+ |31 Offset 3|2 BIR 0|
+ +----------------------------+
+ . . .
+ +----------------------------+
+ |31 Offset 3|2 BIR 0|
+ +----------------------------+
+
+Being able to specify more than one DFL per BAR has been considered, but it
+was determined the use case did not provide value. Specifying a single DFL
+per BAR simplifies the implementation and allows for extra error checking.
Open discussion
===============
diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index 5100695e27cd..04e47e266f26 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -27,6 +27,14 @@
#define DRV_VERSION "0.8"
#define DRV_NAME "dfl-pci"
+#define PCI_VSEC_ID_INTEL_DFLS 0x43
+
+#define PCI_VNDR_DFLS_CNT 0x8
+#define PCI_VNDR_DFLS_RES 0xc
+
+#define PCI_VNDR_DFLS_RES_BAR_MASK GENMASK(2, 0)
+#define PCI_VNDR_DFLS_RES_OFF_MASK GENMASK(31, 3)
+
struct cci_drvdata {
struct dfl_fpga_cdev *cdev; /* container device */
};
@@ -119,6 +127,80 @@ static int *cci_pci_create_irq_table(struct pci_dev *pcidev, unsigned int nvec)
return table;
}
+static int find_dfls_by_vsec(struct pci_dev *pcidev, struct dfl_fpga_enum_info *info)
+{
+ u32 bir, offset, vndr_hdr, dfl_cnt, dfl_res;
+ int dfl_res_off, i, bars, voff = 0;
+ resource_size_t start, len;
+
+ while ((voff = pci_find_next_ext_capability(pcidev, voff, PCI_EXT_CAP_ID_VNDR))) {
+ vndr_hdr = 0;
+ pci_read_config_dword(pcidev, voff + PCI_VNDR_HEADER, &vndr_hdr);
+
+ if (PCI_VNDR_HEADER_ID(vndr_hdr) == PCI_VSEC_ID_INTEL_DFLS &&
+ pcidev->vendor == PCI_VENDOR_ID_INTEL)
+ break;
+ }
+
+ if (!voff) {
+ dev_dbg(&pcidev->dev, "%s no DFL VSEC found\n", __func__);
+ return -ENODEV;
+ }
+
+ dfl_cnt = 0;
+ pci_read_config_dword(pcidev, voff + PCI_VNDR_DFLS_CNT, &dfl_cnt);
+ if (dfl_cnt > PCI_STD_NUM_BARS) {
+ dev_err(&pcidev->dev, "%s too many DFLs %d > %d\n",
+ __func__, dfl_cnt, PCI_STD_NUM_BARS);
+ return -EINVAL;
+ }
+
+ dfl_res_off = voff + PCI_VNDR_DFLS_RES;
+ if (dfl_res_off + (dfl_cnt * sizeof(u32)) > PCI_CFG_SPACE_EXP_SIZE) {
+ dev_err(&pcidev->dev, "%s DFL VSEC too big for PCIe config space\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ for (i = 0, bars = 0; i < dfl_cnt; i++, dfl_res_off += sizeof(u32)) {
+ dfl_res = GENMASK(31, 0);
+ pci_read_config_dword(pcidev, dfl_res_off, &dfl_res);
+
+ bir = dfl_res & PCI_VNDR_DFLS_RES_BAR_MASK;
+ if (bir >= PCI_STD_NUM_BARS) {
+ dev_err(&pcidev->dev, "%s bad bir number %d\n",
+ __func__, bir);
+ return -EINVAL;
+ }
+
+ if (bars & BIT(bir)) {
+ dev_err(&pcidev->dev, "%s DFL for BAR %d already specified\n",
+ __func__, bir);
+ return -EINVAL;
+ }
+
+ bars |= BIT(bir);
+
+ len = pci_resource_len(pcidev, bir);
+ offset = dfl_res & PCI_VNDR_DFLS_RES_OFF_MASK;
+ if (offset >= len) {
+ dev_err(&pcidev->dev, "%s bad offset %u >= %pa\n",
+ __func__, offset, &len);
+ return -EINVAL;
+ }
+
+ dev_dbg(&pcidev->dev, "%s BAR %d offset 0x%x\n", __func__, bir, offset);
+
+ len -= offset;
+
+ start = pci_resource_start(pcidev, bir) + offset;
+
+ dfl_fpga_enum_info_add_dfl(info, start, len);
+ }
+
+ return 0;
+}
+
/* default method of finding dfls starting at offset 0 of bar 0 */
static int find_dfls_by_default(struct pci_dev *pcidev,
struct dfl_fpga_enum_info *info)
@@ -220,7 +302,10 @@ static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
goto irq_free_exit;
}
- ret = find_dfls_by_default(pcidev, info);
+ ret = find_dfls_by_vsec(pcidev, info);
+ if (ret == -ENODEV)
+ ret = find_dfls_by_default(pcidev, info);
+
if (ret)
goto irq_free_exit;
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 3/8] fpga: dfl: fix the definitions of type & feature_id for dfl devices
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
2021-01-07 4:37 ` [PATCH 1/8] fpga: dfl: refactor cci_enumerate_feature_devs() Moritz Fischer
2021-01-07 4:37 ` [PATCH 2/8] fpga: dfl-pci: locate DFLs by PCIe vendor specific capability Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 4/8] fpga: dfl: move dfl_device_id to mod_devicetable.h Moritz Fischer
` (5 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh; +Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer, Xu Yilun
From: Xu Yilun <yilun.xu@intel.com>
The value of the field dfl_device.type comes from the 12 bits register
field DFH_ID according to DFL spec. So this patch changes the definition
of the type field to u16.
Also it is not necessary to illustrate the valid bits of the type field
in comments. Instead we should explicitly define the possible values in
the enumeration type for it, because they are shared by hardware spec.
We should not let the compiler decide these values.
Similar changes are also applied to dfl_device.feature_id.
This patch also fixed the MODALIAS format according to the changes
above.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
drivers/fpga/dfl.c | 3 +--
drivers/fpga/dfl.h | 14 +++++++-------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index b450870b75ed..5a6ba3b2fa05 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -298,8 +298,7 @@ static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct dfl_device *ddev = to_dfl_dev(dev);
- /* The type has 4 valid bits and feature_id has 12 valid bits */
- return add_uevent_var(env, "MODALIAS=dfl:t%01Xf%03X",
+ return add_uevent_var(env, "MODALIAS=dfl:t%04Xf%04X",
ddev->type, ddev->feature_id);
}
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 5dc758f655b7..ac373b1fcff9 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -520,19 +520,19 @@ long dfl_feature_ioctl_set_irq(struct platform_device *pdev,
* enum dfl_id_type - define the DFL FIU types
*/
enum dfl_id_type {
- FME_ID,
- PORT_ID,
+ FME_ID = 0,
+ PORT_ID = 1,
DFL_ID_MAX,
};
/**
* struct dfl_device_id - dfl device identifier
- * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
- * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
+ * @type: DFL FIU type of the device. See enum dfl_id_type.
+ * @feature_id: feature identifier local to its DFL FIU type.
* @driver_data: driver specific data.
*/
struct dfl_device_id {
- u8 type;
+ u16 type;
u16 feature_id;
unsigned long driver_data;
};
@@ -543,7 +543,7 @@ struct dfl_device_id {
* @dev: generic device interface.
* @id: id of the dfl device.
* @type: type of DFL FIU of the device. See enum dfl_id_type.
- * @feature_id: 16 bits feature identifier local to its DFL FIU type.
+ * @feature_id: feature identifier local to its DFL FIU type.
* @mmio_res: mmio resource of this dfl device.
* @irqs: list of Linux IRQ numbers of this dfl device.
* @num_irqs: number of IRQs supported by this dfl device.
@@ -553,7 +553,7 @@ struct dfl_device_id {
struct dfl_device {
struct device dev;
int id;
- u8 type;
+ u16 type;
u16 feature_id;
struct resource mmio_res;
int *irqs;
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 4/8] fpga: dfl: move dfl_device_id to mod_devicetable.h
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (2 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 3/8] fpga: dfl: fix the definitions of type & feature_id for dfl devices Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 5/8] fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE() Moritz Fischer
` (4 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Xu Yilun, Wu Hao, Matthew Gerlach, Russ Weight
From: Xu Yilun <yilun.xu@intel.com>
In order to support MODULE_DEVICE_TABLE() for dfl device driver, this
patch moves struct dfl_device_id to mod_devicetable.h
Some brief description for DFL (Device Feature List) is added to make
the DFL known to the whole kernel.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Acked-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
drivers/fpga/dfl.h | 13 +------------
include/linux/mod_devicetable.h | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index ac373b1fcff9..549c7900dcfd 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -22,6 +22,7 @@
#include <linux/interrupt.h>
#include <linux/iopoll.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/uuid.h>
@@ -525,18 +526,6 @@ enum dfl_id_type {
DFL_ID_MAX,
};
-/**
- * struct dfl_device_id - dfl device identifier
- * @type: DFL FIU type of the device. See enum dfl_id_type.
- * @feature_id: feature identifier local to its DFL FIU type.
- * @driver_data: driver specific data.
- */
-struct dfl_device_id {
- u16 type;
- u16 feature_id;
- unsigned long driver_data;
-};
-
/**
* struct dfl_device - represent an dfl device on dfl bus
*
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index c425290b21e2..b8dae34eca10 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -846,4 +846,28 @@ struct auxiliary_device_id {
kernel_ulong_t driver_data;
};
+/*
+ * DFL (Device Feature List)
+ *
+ * DFL defines a linked list of feature headers within the device MMIO space to
+ * provide an extensible way of adding features. Software can walk through these
+ * predefined data structures to enumerate features. It is now used in the FPGA.
+ * See Documentation/fpga/dfl.rst for more information.
+ *
+ * The dfl bus type is introduced to match the individual feature devices (dfl
+ * devices) for specific dfl drivers.
+ */
+
+/**
+ * struct dfl_device_id - dfl device identifier
+ * @type: DFL FIU type of the device. See enum dfl_id_type.
+ * @feature_id: feature identifier local to its DFL FIU type.
+ * @driver_data: driver specific data.
+ */
+struct dfl_device_id {
+ __u16 type;
+ __u16 feature_id;
+ kernel_ulong_t driver_data;
+};
+
#endif /* LINUX_MOD_DEVICETABLE_H */
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 5/8] fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE()
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (3 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 4/8] fpga: dfl: move dfl_device_id to mod_devicetable.h Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 6/8] fpga: dfl: move dfl bus related APIs to include/linux/dfl.h Moritz Fischer
` (3 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Xu Yilun, Wu Hao, Matthew Gerlach, Russ Weight
From: Xu Yilun <yilun.xu@intel.com>
Device Feature List (DFL) is a linked list of feature headers within the
device MMIO space. It is used by FPGA to enumerate multiple sub features
within it. Each feature can be uniquely identified by DFL type and
feature id, which can be read out from feature headers.
A dfl bus helps DFL framework modularize DFL device drivers for
different sub features. The dfl bus matches its devices and drivers by
DFL type and feature id.
This patch adds dfl bus support to MODULE_DEVICE_TABLE() by adding info
about struct dfl_device_id in devicetable-offsets.c and add a dfl entry
point in file2alias.c.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Acked-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
scripts/mod/devicetable-offsets.c | 4 ++++
scripts/mod/file2alias.c | 13 +++++++++++++
2 files changed, 17 insertions(+)
diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-offsets.c
index e377f52dbfa3..1b14f3cde4e5 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -246,5 +246,9 @@ int main(void)
DEVID(auxiliary_device_id);
DEVID_FIELD(auxiliary_device_id, name);
+ DEVID(dfl_device_id);
+ DEVID_FIELD(dfl_device_id, type);
+ DEVID_FIELD(dfl_device_id, feature_id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index fb4827027536..7ebabeb1e9c9 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1375,6 +1375,18 @@ static int do_auxiliary_entry(const char *filename, void *symval, char *alias)
return 1;
}
+/* Looks like: dfl:tNfN */
+static int do_dfl_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, dfl_device_id, type);
+ DEF_FIELD(symval, dfl_device_id, feature_id);
+
+ sprintf(alias, "dfl:t%04Xf%04X", type, feature_id);
+
+ add_wildcard(alias);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1450,6 +1462,7 @@ static const struct devtable devtable[] = {
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
{"mhi", SIZE_mhi_device_id, do_mhi_entry},
{"auxiliary", SIZE_auxiliary_device_id, do_auxiliary_entry},
+ {"dfl", SIZE_dfl_device_id, do_dfl_entry},
};
/* Create MODULE_ALIAS() statements.
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 6/8] fpga: dfl: move dfl bus related APIs to include/linux/dfl.h
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (4 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 5/8] fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE() Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 7/8] fpga: dfl: add support for N3000 Nios private feature Moritz Fischer
` (2 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Xu Yilun, Wu Hao
From: Xu Yilun <yilun.xu@intel.com>
Now the dfl drivers could be made as independent modules and put in
different folders according to their functionalities. In order for
scattered dfl device drivers to include dfl bus APIs, move the
dfl bus APIs to a new header file in the public folder.
[mdf@kernel.org: Fixed up header guards to match filename]
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Acked-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
MAINTAINERS | 1 +
drivers/fpga/dfl.c | 1 +
drivers/fpga/dfl.h | 72 -------------------------------------
include/linux/dfl.h | 86 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 88 insertions(+), 72 deletions(-)
create mode 100644 include/linux/dfl.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66428c9..a044b58eb9ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6957,6 +6957,7 @@ S: Maintained
F: Documentation/ABI/testing/sysfs-bus-dfl
F: Documentation/fpga/dfl.rst
F: drivers/fpga/dfl*
+F: include/linux/dfl.h
F: include/uapi/linux/fpga-dfl.h
FPGA MANAGER FRAMEWORK
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 5a6ba3b2fa05..511b20ff35a3 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -10,6 +10,7 @@
* Wu Hao <hao.wu@intel.com>
* Xiao Guangrong <guangrong.xiao@linux.intel.com>
*/
+#include <linux/dfl.h>
#include <linux/fpga-dfl.h>
#include <linux/module.h>
#include <linux/uaccess.h>
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 549c7900dcfd..2b82c96ba56c 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -517,76 +517,4 @@ long dfl_feature_ioctl_set_irq(struct platform_device *pdev,
struct dfl_feature *feature,
unsigned long arg);
-/**
- * enum dfl_id_type - define the DFL FIU types
- */
-enum dfl_id_type {
- FME_ID = 0,
- PORT_ID = 1,
- DFL_ID_MAX,
-};
-
-/**
- * struct dfl_device - represent an dfl device on dfl bus
- *
- * @dev: generic device interface.
- * @id: id of the dfl device.
- * @type: type of DFL FIU of the device. See enum dfl_id_type.
- * @feature_id: feature identifier local to its DFL FIU type.
- * @mmio_res: mmio resource of this dfl device.
- * @irqs: list of Linux IRQ numbers of this dfl device.
- * @num_irqs: number of IRQs supported by this dfl device.
- * @cdev: pointer to DFL FPGA container device this dfl device belongs to.
- * @id_entry: matched id entry in dfl driver's id table.
- */
-struct dfl_device {
- struct device dev;
- int id;
- u16 type;
- u16 feature_id;
- struct resource mmio_res;
- int *irqs;
- unsigned int num_irqs;
- struct dfl_fpga_cdev *cdev;
- const struct dfl_device_id *id_entry;
-};
-
-/**
- * struct dfl_driver - represent an dfl device driver
- *
- * @drv: driver model structure.
- * @id_table: pointer to table of device IDs the driver is interested in.
- * { } member terminated.
- * @probe: mandatory callback for device binding.
- * @remove: callback for device unbinding.
- */
-struct dfl_driver {
- struct device_driver drv;
- const struct dfl_device_id *id_table;
-
- int (*probe)(struct dfl_device *dfl_dev);
- void (*remove)(struct dfl_device *dfl_dev);
-};
-
-#define to_dfl_dev(d) container_of(d, struct dfl_device, dev)
-#define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
-
-/*
- * use a macro to avoid include chaining to get THIS_MODULE.
- */
-#define dfl_driver_register(drv) \
- __dfl_driver_register(drv, THIS_MODULE)
-int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner);
-void dfl_driver_unregister(struct dfl_driver *dfl_drv);
-
-/*
- * module_dfl_driver() - Helper macro for drivers that don't do
- * anything special in module init/exit. This eliminates a lot of
- * boilerplate. Each module may only use this macro once, and
- * calling it replaces module_init() and module_exit().
- */
-#define module_dfl_driver(__dfl_driver) \
- module_driver(__dfl_driver, dfl_driver_register, \
- dfl_driver_unregister)
-
#endif /* __FPGA_DFL_H */
diff --git a/include/linux/dfl.h b/include/linux/dfl.h
new file mode 100644
index 000000000000..6cc10982351a
--- /dev/null
+++ b/include/linux/dfl.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for DFL driver and device API
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ */
+
+#ifndef __LINUX_DFL_H
+#define __LINUX_DFL_H
+
+#include <linux/device.h>
+#include <linux/mod_devicetable.h>
+
+/**
+ * enum dfl_id_type - define the DFL FIU types
+ */
+enum dfl_id_type {
+ FME_ID = 0,
+ PORT_ID = 1,
+ DFL_ID_MAX,
+};
+
+/**
+ * struct dfl_device - represent an dfl device on dfl bus
+ *
+ * @dev: generic device interface.
+ * @id: id of the dfl device.
+ * @type: type of DFL FIU of the device. See enum dfl_id_type.
+ * @feature_id: feature identifier local to its DFL FIU type.
+ * @mmio_res: mmio resource of this dfl device.
+ * @irqs: list of Linux IRQ numbers of this dfl device.
+ * @num_irqs: number of IRQs supported by this dfl device.
+ * @cdev: pointer to DFL FPGA container device this dfl device belongs to.
+ * @id_entry: matched id entry in dfl driver's id table.
+ */
+struct dfl_device {
+ struct device dev;
+ int id;
+ u16 type;
+ u16 feature_id;
+ struct resource mmio_res;
+ int *irqs;
+ unsigned int num_irqs;
+ struct dfl_fpga_cdev *cdev;
+ const struct dfl_device_id *id_entry;
+};
+
+/**
+ * struct dfl_driver - represent an dfl device driver
+ *
+ * @drv: driver model structure.
+ * @id_table: pointer to table of device IDs the driver is interested in.
+ * { } member terminated.
+ * @probe: mandatory callback for device binding.
+ * @remove: callback for device unbinding.
+ */
+struct dfl_driver {
+ struct device_driver drv;
+ const struct dfl_device_id *id_table;
+
+ int (*probe)(struct dfl_device *dfl_dev);
+ void (*remove)(struct dfl_device *dfl_dev);
+};
+
+#define to_dfl_dev(d) container_of(d, struct dfl_device, dev)
+#define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
+
+/*
+ * use a macro to avoid include chaining to get THIS_MODULE.
+ */
+#define dfl_driver_register(drv) \
+ __dfl_driver_register(drv, THIS_MODULE)
+int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner);
+void dfl_driver_unregister(struct dfl_driver *dfl_drv);
+
+/*
+ * module_dfl_driver() - Helper macro for drivers that don't do
+ * anything special in module init/exit. This eliminates a lot of
+ * boilerplate. Each module may only use this macro once, and
+ * calling it replaces module_init() and module_exit().
+ */
+#define module_dfl_driver(__dfl_driver) \
+ module_driver(__dfl_driver, dfl_driver_register, \
+ dfl_driver_unregister)
+
+#endif /* __LINUX_DFL_H */
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 7/8] fpga: dfl: add support for N3000 Nios private feature
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (5 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 6/8] fpga: dfl: move dfl bus related APIs to include/linux/dfl.h Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 4:37 ` [PATCH 8/8] memory: dfl-emif: add the DFL EMIF private feature driver Moritz Fischer
2021-01-07 16:09 ` [PATCH 0/8] FPGA DFL Changes for 5.12 Tom Rix
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Xu Yilun, Wu Hao, Matthew Gerlach, Russ Weight, YueHaibing
From: Xu Yilun <yilun.xu@intel.com>
This patch adds support for the Nios handshake private feature on Intel
PAC (Programmable Acceleration Card) N3000.
The Nios is the embedded processor on the FPGA card. This private feature
provides a handshake interface to FPGA Nios firmware, which receives
retimer configuration command from host and executes via an internal SPI
master (spi-altera). When Nios finishes the configuration, host takes over
the ownership of the SPI master to control an Intel MAX10 BMC (Board
Management Controller) Chip on the SPI bus.
For Nios firmware handshake part, this driver requests the retimer
configuration for Nios firmware on probe, and adds some sysfs nodes for
user to query the onboard retimer's working mode and Nios firmware
version.
For SPI part, this driver adds a spi-altera platform device as well as
the MAX10 BMC spi slave info. A spi-altera driver will be matched to
handle the following SPI work.
[mdf@kernel.org: Fixed up ABI doc kernel release]
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Tom Rix <trix@redhat.com>
---
.../testing/sysfs-bus-dfl-devices-n3000-nios | 47 ++
MAINTAINERS | 2 +-
drivers/fpga/Kconfig | 11 +
drivers/fpga/Makefile | 2 +
drivers/fpga/dfl-n3000-nios.c | 588 ++++++++++++++++++
5 files changed, 649 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
create mode 100644 drivers/fpga/dfl-n3000-nios.c
diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
new file mode 100644
index 000000000000..5335d742bcaf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
@@ -0,0 +1,47 @@
+What: /sys/bus/dfl/devices/dfl_dev.X/fec_mode
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. Returns the FEC mode of the 25G links of the
+ ethernet retimers configured by Nios firmware. "rs" for Reed
+ Solomon FEC, "kr" for Fire Code FEC, "no" for NO FEC.
+ "not supported" if the FEC mode setting is not supported, this
+ happens when the Nios firmware version major < 3, or no link is
+ configured to 25G.
+ Format: string
+
+What: /sys/bus/dfl/devices/dfl_dev.X/retimer_A_mode
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. Returns the enumeration value of the working mode of
+ the retimer A configured by the Nios firmware. The value is
+ read out from shared registers filled by the Nios firmware. Now
+ the values could be:
+
+ - "0": Reset
+ - "1": 4x10G
+ - "2": 4x25G
+ - "3": 2x25G
+ - "4": 2x25G+2x10G
+ - "5": 1x25G
+
+ If the Nios firmware is updated in future to support more
+ retimer modes, more enumeration value is expected.
+ Format: 0x%x
+
+What: /sys/bus/dfl/devices/dfl_dev.X/retimer_B_mode
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. Returns the enumeration value of the working mode of
+ the retimer B configured by the Nios firmware. The value format
+ is the same as retimer_A_mode.
+
+What: /sys/bus/dfl/devices/dfl_dev.X/nios_fw_version
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. Returns the version of the Nios firmware in the
+ FPGA. Its format is "major.minor.patch".
+ Format: %x.%x.%x
diff --git a/MAINTAINERS b/MAINTAINERS
index a044b58eb9ac..aebb26a7d8f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6954,7 +6954,7 @@ M: Wu Hao <hao.wu@intel.com>
R: Tom Rix <trix@redhat.com>
L: linux-fpga@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-bus-dfl
+F: Documentation/ABI/testing/sysfs-bus-dfl*
F: Documentation/fpga/dfl.rst
F: drivers/fpga/dfl*
F: include/linux/dfl.h
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5645226ca3ce..5ff9438b7b46 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -192,6 +192,17 @@ config FPGA_DFL_AFU
to the FPGA infrastructure via a Port. There may be more than one
Port/AFU per DFL based FPGA device.
+config FPGA_DFL_NIOS_INTEL_PAC_N3000
+ tristate "FPGA DFL NIOS Driver for Intel PAC N3000"
+ depends on FPGA_DFL
+ select REGMAP
+ help
+ This is the driver for the N3000 Nios private feature on Intel
+ PAC (Programmable Acceleration Card) N3000. It communicates
+ with the embedded Nios processor to configure the retimers on
+ the card. It also instantiates the SPI master (spi-altera) for
+ the card's BMC (Board Management Controller).
+
config FPGA_DFL_PCI
tristate "FPGA DFL PCIe Device Driver"
depends on PCI && FPGA_DFL
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index d8e21dfc6778..18dc9885883a 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -44,5 +44,7 @@ dfl-fme-objs += dfl-fme-perf.o
dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o
dfl-afu-objs += dfl-afu-error.o
+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
diff --git a/drivers/fpga/dfl-n3000-nios.c b/drivers/fpga/dfl-n3000-nios.c
new file mode 100644
index 000000000000..7a95366f6516
--- /dev/null
+++ b/drivers/fpga/dfl-n3000-nios.c
@@ -0,0 +1,588 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL device driver for Nios private feature on Intel PAC (Programmable
+ * Acceleration Card) N3000
+ *
+ * Copyright (C) 2019-2020 Intel Corporation, Inc.
+ *
+ * Authors:
+ * Wu Hao <hao.wu@intel.com>
+ * Xu Yilun <yilun.xu@intel.com>
+ */
+#include <linux/bitfield.h>
+#include <linux/dfl.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stddef.h>
+#include <linux/spi/altera.h>
+#include <linux/spi/spi.h>
+#include <linux/types.h>
+
+/*
+ * N3000 Nios private feature registers, named as NIOS_SPI_XX on spec.
+ * NS is the abbreviation of NIOS_SPI.
+ */
+#define N3000_NS_PARAM 0x8
+#define N3000_NS_PARAM_SHIFT_MODE_MSK BIT_ULL(1)
+#define N3000_NS_PARAM_SHIFT_MODE_MSB 0
+#define N3000_NS_PARAM_SHIFT_MODE_LSB 1
+#define N3000_NS_PARAM_DATA_WIDTH GENMASK_ULL(7, 2)
+#define N3000_NS_PARAM_NUM_CS GENMASK_ULL(13, 8)
+#define N3000_NS_PARAM_CLK_POL BIT_ULL(14)
+#define N3000_NS_PARAM_CLK_PHASE BIT_ULL(15)
+#define N3000_NS_PARAM_PERIPHERAL_ID GENMASK_ULL(47, 32)
+
+#define N3000_NS_CTRL 0x10
+#define N3000_NS_CTRL_WR_DATA GENMASK_ULL(31, 0)
+#define N3000_NS_CTRL_ADDR GENMASK_ULL(44, 32)
+#define N3000_NS_CTRL_CMD_MSK GENMASK_ULL(63, 62)
+#define N3000_NS_CTRL_CMD_NOP 0
+#define N3000_NS_CTRL_CMD_RD 1
+#define N3000_NS_CTRL_CMD_WR 2
+
+#define N3000_NS_STAT 0x18
+#define N3000_NS_STAT_RD_DATA GENMASK_ULL(31, 0)
+#define N3000_NS_STAT_RW_VAL BIT_ULL(32)
+
+/* Nios handshake registers, indirect access */
+#define N3000_NIOS_INIT 0x1000
+#define N3000_NIOS_INIT_DONE BIT(0)
+#define N3000_NIOS_INIT_START BIT(1)
+/* Mode for retimer A, link 0, the same below */
+#define N3000_NIOS_INIT_REQ_FEC_MODE_A0_MSK GENMASK(9, 8)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_A1_MSK GENMASK(11, 10)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_A2_MSK GENMASK(13, 12)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_A3_MSK GENMASK(15, 14)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_B0_MSK GENMASK(17, 16)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_B1_MSK GENMASK(19, 18)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_B2_MSK GENMASK(21, 20)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_B3_MSK GENMASK(23, 22)
+#define N3000_NIOS_INIT_REQ_FEC_MODE_NO 0x0
+#define N3000_NIOS_INIT_REQ_FEC_MODE_KR 0x1
+#define N3000_NIOS_INIT_REQ_FEC_MODE_RS 0x2
+
+#define N3000_NIOS_FW_VERSION 0x1004
+#define N3000_NIOS_FW_VERSION_PATCH GENMASK(23, 20)
+#define N3000_NIOS_FW_VERSION_MINOR GENMASK(27, 24)
+#define N3000_NIOS_FW_VERSION_MAJOR GENMASK(31, 28)
+
+/* The retimers we use on Intel PAC N3000 is Parkvale, abbreviated to PKVL */
+#define N3000_NIOS_PKVL_A_MODE_STS 0x1020
+#define N3000_NIOS_PKVL_B_MODE_STS 0x1024
+#define N3000_NIOS_PKVL_MODE_STS_GROUP_MSK GENMASK(15, 8)
+#define N3000_NIOS_PKVL_MODE_STS_GROUP_OK 0x0
+#define N3000_NIOS_PKVL_MODE_STS_ID_MSK GENMASK(7, 0)
+/* When GROUP MASK field == GROUP_OK */
+#define N3000_NIOS_PKVL_MODE_ID_RESET 0x0
+#define N3000_NIOS_PKVL_MODE_ID_4X10G 0x1
+#define N3000_NIOS_PKVL_MODE_ID_4X25G 0x2
+#define N3000_NIOS_PKVL_MODE_ID_2X25G 0x3
+#define N3000_NIOS_PKVL_MODE_ID_2X25G_2X10G 0x4
+#define N3000_NIOS_PKVL_MODE_ID_1X25G 0x5
+
+#define N3000_NIOS_REGBUS_RETRY_COUNT 10000 /* loop count */
+
+#define N3000_NIOS_INIT_TIMEOUT 10000000 /* usec */
+#define N3000_NIOS_INIT_TIME_INTV 100000 /* usec */
+
+#define N3000_NIOS_INIT_REQ_FEC_MODE_MSK_ALL \
+ (N3000_NIOS_INIT_REQ_FEC_MODE_A0_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_A1_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_A2_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_A3_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_B0_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_B1_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_B2_MSK | \
+ N3000_NIOS_INIT_REQ_FEC_MODE_B3_MSK)
+
+#define N3000_NIOS_INIT_REQ_FEC_MODE_NO_ALL \
+ (FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_NO))
+
+#define N3000_NIOS_INIT_REQ_FEC_MODE_KR_ALL \
+ (FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_KR))
+
+#define N3000_NIOS_INIT_REQ_FEC_MODE_RS_ALL \
+ (FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_A3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B0_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B1_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B2_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS) | \
+ FIELD_PREP(N3000_NIOS_INIT_REQ_FEC_MODE_B3_MSK, \
+ N3000_NIOS_INIT_REQ_FEC_MODE_RS))
+
+struct n3000_nios {
+ void __iomem *base;
+ struct regmap *regmap;
+ struct device *dev;
+ struct platform_device *altera_spi;
+};
+
+static ssize_t nios_fw_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct n3000_nios *nn = dev_get_drvdata(dev);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(nn->regmap, N3000_NIOS_FW_VERSION, &val);
+ if (ret)
+ return ret;
+
+ return sysfs_emit(buf, "%x.%x.%x\n",
+ (u8)FIELD_GET(N3000_NIOS_FW_VERSION_MAJOR, val),
+ (u8)FIELD_GET(N3000_NIOS_FW_VERSION_MINOR, val),
+ (u8)FIELD_GET(N3000_NIOS_FW_VERSION_PATCH, val));
+}
+static DEVICE_ATTR_RO(nios_fw_version);
+
+#define IS_MODE_STATUS_OK(mode_stat) \
+ (FIELD_GET(N3000_NIOS_PKVL_MODE_STS_GROUP_MSK, (mode_stat)) == \
+ N3000_NIOS_PKVL_MODE_STS_GROUP_OK)
+
+#define IS_RETIMER_FEC_SUPPORTED(retimer_mode) \
+ ((retimer_mode) != N3000_NIOS_PKVL_MODE_ID_RESET && \
+ (retimer_mode) != N3000_NIOS_PKVL_MODE_ID_4X10G)
+
+static int get_retimer_mode(struct n3000_nios *nn, unsigned int mode_stat_reg,
+ unsigned int *retimer_mode)
+{
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(nn->regmap, mode_stat_reg, &val);
+ if (ret)
+ return ret;
+
+ if (!IS_MODE_STATUS_OK(val))
+ return -EFAULT;
+
+ *retimer_mode = FIELD_GET(N3000_NIOS_PKVL_MODE_STS_ID_MSK, val);
+
+ return 0;
+}
+
+static ssize_t retimer_A_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct n3000_nios *nn = dev_get_drvdata(dev);
+ unsigned int mode;
+ int ret;
+
+ ret = get_retimer_mode(nn, N3000_NIOS_PKVL_A_MODE_STS, &mode);
+ if (ret)
+ return ret;
+
+ return sysfs_emit(buf, "0x%x\n", mode);
+}
+static DEVICE_ATTR_RO(retimer_A_mode);
+
+static ssize_t retimer_B_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct n3000_nios *nn = dev_get_drvdata(dev);
+ unsigned int mode;
+ int ret;
+
+ ret = get_retimer_mode(nn, N3000_NIOS_PKVL_B_MODE_STS, &mode);
+ if (ret)
+ return ret;
+
+ return sysfs_emit(buf, "0x%x\n", mode);
+}
+static DEVICE_ATTR_RO(retimer_B_mode);
+
+static ssize_t fec_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ unsigned int val, retimer_a_mode, retimer_b_mode, fec_modes;
+ struct n3000_nios *nn = dev_get_drvdata(dev);
+ int ret;
+
+ /* FEC mode setting is not supported in early FW versions */
+ ret = regmap_read(nn->regmap, N3000_NIOS_FW_VERSION, &val);
+ if (ret)
+ return ret;
+
+ if (FIELD_GET(N3000_NIOS_FW_VERSION_MAJOR, val) < 3)
+ return sysfs_emit(buf, "not supported\n");
+
+ /* If no 25G links, FEC mode setting is not supported either */
+ ret = get_retimer_mode(nn, N3000_NIOS_PKVL_A_MODE_STS, &retimer_a_mode);
+ if (ret)
+ return ret;
+
+ ret = get_retimer_mode(nn, N3000_NIOS_PKVL_B_MODE_STS, &retimer_b_mode);
+ if (ret)
+ return ret;
+
+ if (!IS_RETIMER_FEC_SUPPORTED(retimer_a_mode) &&
+ !IS_RETIMER_FEC_SUPPORTED(retimer_b_mode))
+ return sysfs_emit(buf, "not supported\n");
+
+ /* get the valid FEC mode for 25G links */
+ ret = regmap_read(nn->regmap, N3000_NIOS_INIT, &val);
+ if (ret)
+ return ret;
+
+ /*
+ * FEC mode should always be the same for all links, as we set them
+ * in this way.
+ */
+ fec_modes = (val & N3000_NIOS_INIT_REQ_FEC_MODE_MSK_ALL);
+ if (fec_modes == N3000_NIOS_INIT_REQ_FEC_MODE_NO_ALL)
+ return sysfs_emit(buf, "no\n");
+ else if (fec_modes == N3000_NIOS_INIT_REQ_FEC_MODE_KR_ALL)
+ return sysfs_emit(buf, "kr\n");
+ else if (fec_modes == N3000_NIOS_INIT_REQ_FEC_MODE_RS_ALL)
+ return sysfs_emit(buf, "rs\n");
+
+ return -EFAULT;
+}
+static DEVICE_ATTR_RO(fec_mode);
+
+static struct attribute *n3000_nios_attrs[] = {
+ &dev_attr_nios_fw_version.attr,
+ &dev_attr_retimer_A_mode.attr,
+ &dev_attr_retimer_B_mode.attr,
+ &dev_attr_fec_mode.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(n3000_nios);
+
+static int n3000_nios_init_done_check(struct n3000_nios *nn)
+{
+ unsigned int val, state_a, state_b;
+ struct device *dev = nn->dev;
+ int ret, ret2;
+
+ /*
+ * The SPI is shared by the Nios core inside the FPGA, Nios will use
+ * this SPI master to do some one time initialization after power up,
+ * and then release the control to OS. The driver needs to poll on
+ * INIT_DONE to see when driver could take the control.
+ *
+ * Please note that after Nios firmware version 3.0.0, INIT_START is
+ * introduced, so driver needs to trigger START firstly and then check
+ * INIT_DONE.
+ */
+
+ ret = regmap_read(nn->regmap, N3000_NIOS_FW_VERSION, &val);
+ if (ret)
+ return ret;
+
+ /*
+ * If Nios version register is totally uninitialized(== 0x0), then the
+ * Nios firmware is missing. So host could take control of SPI master
+ * safely, but initialization work for Nios is not done. To restore the
+ * card, we need to reprogram a new Nios firmware via the BMC chip on
+ * SPI bus. So the driver doesn't error out, it continues to create the
+ * spi controller device and spi_board_info for BMC.
+ */
+ if (val == 0) {
+ dev_err(dev, "Nios version reg = 0x%x, skip INIT_DONE check, but the retimer may be uninitialized\n",
+ val);
+ return 0;
+ }
+
+ if (FIELD_GET(N3000_NIOS_FW_VERSION_MAJOR, val) >= 3) {
+ /* read NIOS_INIT to check if retimer initialization is done */
+ ret = regmap_read(nn->regmap, N3000_NIOS_INIT, &val);
+ if (ret)
+ return ret;
+
+ /* check if retimers are initialized already */
+ if (val & (N3000_NIOS_INIT_DONE | N3000_NIOS_INIT_START))
+ goto nios_init_done;
+
+ /* configure FEC mode per module param */
+ val = N3000_NIOS_INIT_START;
+
+ /*
+ * When the retimer is to be set to 10G mode, there is no FEC
+ * mode setting, so the REQ_FEC_MODE field will be ignored by
+ * Nios firmware in this case. But we should still fill the FEC
+ * mode field cause host could not get the retimer working mode
+ * until the Nios init is done.
+ *
+ * For now the driver doesn't support the retimer FEC mode
+ * switching per user's request. It is always set to Reed
+ * Solomon FEC.
+ *
+ * The driver will set the same FEC mode for all links.
+ */
+ val |= N3000_NIOS_INIT_REQ_FEC_MODE_RS_ALL;
+
+ ret = regmap_write(nn->regmap, N3000_NIOS_INIT, val);
+ if (ret)
+ return ret;
+ }
+
+nios_init_done:
+ /* polls on NIOS_INIT_DONE */
+ ret = regmap_read_poll_timeout(nn->regmap, N3000_NIOS_INIT, val,
+ val & N3000_NIOS_INIT_DONE,
+ N3000_NIOS_INIT_TIME_INTV,
+ N3000_NIOS_INIT_TIMEOUT);
+ if (ret)
+ dev_err(dev, "NIOS_INIT_DONE %s\n",
+ (ret == -ETIMEDOUT) ? "timed out" : "check error");
+
+ ret2 = regmap_read(nn->regmap, N3000_NIOS_PKVL_A_MODE_STS, &state_a);
+ if (ret2)
+ return ret2;
+
+ ret2 = regmap_read(nn->regmap, N3000_NIOS_PKVL_B_MODE_STS, &state_b);
+ if (ret2)
+ return ret2;
+
+ if (!ret) {
+ /*
+ * After INIT_DONE is detected, it still needs to check if the
+ * Nios firmware reports any error during the retimer
+ * configuration.
+ */
+ if (IS_MODE_STATUS_OK(state_a) && IS_MODE_STATUS_OK(state_b))
+ return 0;
+
+ /*
+ * If the retimer configuration is failed, the Nios firmware
+ * will still release the spi controller for host to
+ * communicate with the BMC. It makes possible for people to
+ * reprogram a new Nios firmware and restore the card. So the
+ * driver doesn't error out, it continues to create the spi
+ * controller device and spi_board_info for BMC.
+ */
+ dev_err(dev, "NIOS_INIT_DONE OK, but err on retimer init\n");
+ }
+
+ dev_err(nn->dev, "PKVL_A_MODE_STS 0x%x\n", state_a);
+ dev_err(nn->dev, "PKVL_B_MODE_STS 0x%x\n", state_b);
+
+ return ret;
+}
+
+static struct spi_board_info m10_n3000_info = {
+ .modalias = "m10-n3000",
+ .max_speed_hz = 12500000,
+ .bus_num = 0,
+ .chip_select = 0,
+};
+
+static int create_altera_spi_controller(struct n3000_nios *nn)
+{
+ struct altera_spi_platform_data pdata = { 0 };
+ struct platform_device_info pdevinfo = { 0 };
+ void __iomem *base = nn->base;
+ u64 v;
+
+ v = readq(base + N3000_NS_PARAM);
+
+ pdata.mode_bits = SPI_CS_HIGH;
+ if (FIELD_GET(N3000_NS_PARAM_CLK_POL, v))
+ pdata.mode_bits |= SPI_CPOL;
+ if (FIELD_GET(N3000_NS_PARAM_CLK_PHASE, v))
+ pdata.mode_bits |= SPI_CPHA;
+
+ pdata.num_chipselect = FIELD_GET(N3000_NS_PARAM_NUM_CS, v);
+ pdata.bits_per_word_mask =
+ SPI_BPW_RANGE_MASK(1, FIELD_GET(N3000_NS_PARAM_DATA_WIDTH, v));
+
+ pdata.num_devices = 1;
+ pdata.devices = &m10_n3000_info;
+
+ dev_dbg(nn->dev, "%s cs %u bpm 0x%x mode 0x%x\n", __func__,
+ pdata.num_chipselect, pdata.bits_per_word_mask,
+ pdata.mode_bits);
+
+ pdevinfo.name = "subdev_spi_altera";
+ pdevinfo.id = PLATFORM_DEVID_AUTO;
+ pdevinfo.parent = nn->dev;
+ pdevinfo.data = &pdata;
+ pdevinfo.size_data = sizeof(pdata);
+
+ nn->altera_spi = platform_device_register_full(&pdevinfo);
+ return PTR_ERR_OR_ZERO(nn->altera_spi);
+}
+
+static void destroy_altera_spi_controller(struct n3000_nios *nn)
+{
+ platform_device_unregister(nn->altera_spi);
+}
+
+static int n3000_nios_poll_stat_timeout(void __iomem *base, u64 *v)
+{
+ int loops;
+
+ /*
+ * We don't use the time based timeout here for performance.
+ *
+ * The regbus read/write is on the critical path of Intel PAC N3000
+ * image programing. The time based timeout checking will add too much
+ * overhead on it. Usually the state changes in 1 or 2 loops on the
+ * test server, and we set 10000 times loop here for safety.
+ */
+ for (loops = N3000_NIOS_REGBUS_RETRY_COUNT; loops > 0 ; loops--) {
+ *v = readq(base + N3000_NS_STAT);
+ if (*v & N3000_NS_STAT_RW_VAL)
+ break;
+ cpu_relax();
+ }
+
+ return (loops > 0) ? 0 : -ETIMEDOUT;
+}
+
+static int n3000_nios_reg_write(void *context, unsigned int reg, unsigned int val)
+{
+ struct n3000_nios *nn = context;
+ u64 v;
+ int ret;
+
+ v = FIELD_PREP(N3000_NS_CTRL_CMD_MSK, N3000_NS_CTRL_CMD_WR) |
+ FIELD_PREP(N3000_NS_CTRL_ADDR, reg) |
+ FIELD_PREP(N3000_NS_CTRL_WR_DATA, val);
+ writeq(v, nn->base + N3000_NS_CTRL);
+
+ ret = n3000_nios_poll_stat_timeout(nn->base, &v);
+ if (ret)
+ dev_err(nn->dev, "fail to write reg 0x%x val 0x%x: %d\n",
+ reg, val, ret);
+
+ return ret;
+}
+
+static int n3000_nios_reg_read(void *context, unsigned int reg, unsigned int *val)
+{
+ struct n3000_nios *nn = context;
+ u64 v;
+ int ret;
+
+ v = FIELD_PREP(N3000_NS_CTRL_CMD_MSK, N3000_NS_CTRL_CMD_RD) |
+ FIELD_PREP(N3000_NS_CTRL_ADDR, reg);
+ writeq(v, nn->base + N3000_NS_CTRL);
+
+ ret = n3000_nios_poll_stat_timeout(nn->base, &v);
+ if (ret)
+ dev_err(nn->dev, "fail to read reg 0x%x: %d\n", reg, ret);
+ else
+ *val = FIELD_GET(N3000_NS_STAT_RD_DATA, v);
+
+ return ret;
+}
+
+static const struct regmap_config n3000_nios_regbus_cfg = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+
+ .reg_write = n3000_nios_reg_write,
+ .reg_read = n3000_nios_reg_read,
+};
+
+static int n3000_nios_probe(struct dfl_device *ddev)
+{
+ struct device *dev = &ddev->dev;
+ struct n3000_nios *nn;
+ int ret;
+
+ nn = devm_kzalloc(dev, sizeof(*nn), GFP_KERNEL);
+ if (!nn)
+ return -ENOMEM;
+
+ dev_set_drvdata(&ddev->dev, nn);
+
+ nn->dev = dev;
+
+ nn->base = devm_ioremap_resource(&ddev->dev, &ddev->mmio_res);
+ if (IS_ERR(nn->base))
+ return PTR_ERR(nn->base);
+
+ nn->regmap = devm_regmap_init(dev, NULL, nn, &n3000_nios_regbus_cfg);
+ if (IS_ERR(nn->regmap))
+ return PTR_ERR(nn->regmap);
+
+ ret = n3000_nios_init_done_check(nn);
+ if (ret)
+ return ret;
+
+ ret = create_altera_spi_controller(nn);
+ if (ret)
+ dev_err(dev, "altera spi controller create failed: %d\n", ret);
+
+ return ret;
+}
+
+static void n3000_nios_remove(struct dfl_device *ddev)
+{
+ struct n3000_nios *nn = dev_get_drvdata(&ddev->dev);
+
+ destroy_altera_spi_controller(nn);
+}
+
+#define FME_FEATURE_ID_N3000_NIOS 0xd
+
+static const struct dfl_device_id n3000_nios_ids[] = {
+ { FME_ID, FME_FEATURE_ID_N3000_NIOS },
+ { }
+};
+MODULE_DEVICE_TABLE(dfl, n3000_nios_ids);
+
+static struct dfl_driver n3000_nios_driver = {
+ .drv = {
+ .name = "dfl-n3000-nios",
+ .dev_groups = n3000_nios_groups,
+ },
+ .id_table = n3000_nios_ids,
+ .probe = n3000_nios_probe,
+ .remove = n3000_nios_remove,
+};
+
+module_dfl_driver(n3000_nios_driver);
+
+MODULE_DESCRIPTION("Driver for Nios private feature on Intel PAC N3000");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 8/8] memory: dfl-emif: add the DFL EMIF private feature driver
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (6 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 7/8] fpga: dfl: add support for N3000 Nios private feature Moritz Fischer
@ 2021-01-07 4:37 ` Moritz Fischer
2021-01-07 16:09 ` [PATCH 0/8] FPGA DFL Changes for 5.12 Tom Rix
8 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-07 4:37 UTC (permalink / raw)
To: gregkh
Cc: linux-fpga, linux-kernel, trix, moritzf, Moritz Fischer,
Xu Yilun, Russ Weight, Krzysztof Kozlowski
From: Xu Yilun <yilun.xu@intel.com>
This driver is for the EMIF private feature implemented under FPGA
Device Feature List (DFL) framework. It is used to expose memory
interface status information as well as memory clearing control.
The purpose of memory clearing block is to zero out all private memory
when FPGA is to be reprogrammed. This gives users a reliable method to
prevent potential data leakage.
[mdf@kernel.org: Fixed up ABI doc]
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
.../ABI/testing/sysfs-bus-dfl-devices-emif | 25 +++
drivers/memory/Kconfig | 9 +
drivers/memory/Makefile | 2 +
drivers/memory/dfl-emif.c | 207 ++++++++++++++++++
4 files changed, 243 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
create mode 100644 drivers/memory/dfl-emif.c
diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
new file mode 100644
index 000000000000..817d14126d4d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
@@ -0,0 +1,25 @@
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_cal_fail
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. It indicates if the calibration failed on this
+ memory interface. "1" for calibration failure, "0" for OK.
+ Format: %u
+
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_init_done
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Read-only. It indicates if the initialization completed on
+ this memory interface. "1" for initialization complete, "0"
+ for not yet.
+ Format: %u
+
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_clear
+Date: Oct 2020
+KernelVersion: 5.12
+Contact: Xu Yilun <yilun.xu@intel.com>
+Description: Write-only. Writing "1" to this file will zero out all memory
+ data in this memory interface. Writing of other values is
+ invalid.
+ Format: %u
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 3ea6913df176..3c9a9882ef28 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -137,6 +137,15 @@ config TI_EMIF_SRAM
sequence so this driver provides several relocatable PM functions
for the SoC PM code to use.
+config FPGA_DFL_EMIF
+ tristate "FPGA DFL EMIF Driver"
+ depends on FPGA_DFL && HAS_IOMEM
+ help
+ This driver is for the EMIF private feature implemented under
+ FPGA Device Feature List (DFL) framework. It is used to expose
+ memory interface status information as well as memory clearing
+ control.
+
config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
default y if PLAT_ORION
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e71cf7b99641..bc7663ed1c25 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
+obj-$(CONFIG_FPGA_DFL_EMIF) += dfl-emif.o
+
ti-emif-sram-objs := ti-emif-pm.o ti-emif-sram-pm.o
AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
diff --git a/drivers/memory/dfl-emif.c b/drivers/memory/dfl-emif.c
new file mode 100644
index 000000000000..3f719816771d
--- /dev/null
+++ b/drivers/memory/dfl-emif.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL device driver for EMIF private feature
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ *
+ */
+#include <linux/bitfield.h>
+#include <linux/dfl.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define FME_FEATURE_ID_EMIF 0x9
+
+#define EMIF_STAT 0x8
+#define EMIF_STAT_INIT_DONE_SFT 0
+#define EMIF_STAT_CALC_FAIL_SFT 8
+#define EMIF_STAT_CLEAR_BUSY_SFT 16
+#define EMIF_CTRL 0x10
+#define EMIF_CTRL_CLEAR_EN_SFT 0
+#define EMIF_CTRL_CLEAR_EN_MSK GENMASK_ULL(3, 0)
+
+#define EMIF_POLL_INVL 10000 /* us */
+#define EMIF_POLL_TIMEOUT 5000000 /* us */
+
+struct dfl_emif {
+ struct device *dev;
+ void __iomem *base;
+ spinlock_t lock; /* Serialises access to EMIF_CTRL reg */
+};
+
+struct emif_attr {
+ struct device_attribute attr;
+ u32 shift;
+ u32 index;
+};
+
+#define to_emif_attr(dev_attr) \
+ container_of(dev_attr, struct emif_attr, attr)
+
+static ssize_t emif_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct emif_attr *eattr = to_emif_attr(attr);
+ struct dfl_emif *de = dev_get_drvdata(dev);
+ u64 val;
+
+ val = readq(de->base + EMIF_STAT);
+
+ return sysfs_emit(buf, "%u\n",
+ !!(val & BIT_ULL(eattr->shift + eattr->index)));
+}
+
+static ssize_t emif_clear_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct emif_attr *eattr = to_emif_attr(attr);
+ struct dfl_emif *de = dev_get_drvdata(dev);
+ u64 clear_busy_msk, clear_en_msk, val;
+ void __iomem *base = de->base;
+
+ if (!sysfs_streq(buf, "1"))
+ return -EINVAL;
+
+ clear_busy_msk = BIT_ULL(EMIF_STAT_CLEAR_BUSY_SFT + eattr->index);
+ clear_en_msk = BIT_ULL(EMIF_CTRL_CLEAR_EN_SFT + eattr->index);
+
+ spin_lock(&de->lock);
+ /* The CLEAR_EN field is WO, but other fields are RW */
+ val = readq(base + EMIF_CTRL);
+ val &= ~EMIF_CTRL_CLEAR_EN_MSK;
+ val |= clear_en_msk;
+ writeq(val, base + EMIF_CTRL);
+ spin_unlock(&de->lock);
+
+ if (readq_poll_timeout(base + EMIF_STAT, val,
+ !(val & clear_busy_msk),
+ EMIF_POLL_INVL, EMIF_POLL_TIMEOUT)) {
+ dev_err(de->dev, "timeout, fail to clear\n");
+ return -ETIMEDOUT;
+ }
+
+ return count;
+}
+
+#define emif_state_attr(_name, _shift, _index) \
+ static struct emif_attr emif_attr_##inf##_index##_##_name = \
+ { .attr = __ATTR(inf##_index##_##_name, 0444, \
+ emif_state_show, NULL), \
+ .shift = (_shift), .index = (_index) }
+
+#define emif_clear_attr(_index) \
+ static struct emif_attr emif_attr_##inf##_index##_clear = \
+ { .attr = __ATTR(inf##_index##_clear, 0200, \
+ NULL, emif_clear_store), \
+ .index = (_index) }
+
+emif_state_attr(init_done, EMIF_STAT_INIT_DONE_SFT, 0);
+emif_state_attr(init_done, EMIF_STAT_INIT_DONE_SFT, 1);
+emif_state_attr(init_done, EMIF_STAT_INIT_DONE_SFT, 2);
+emif_state_attr(init_done, EMIF_STAT_INIT_DONE_SFT, 3);
+
+emif_state_attr(cal_fail, EMIF_STAT_CALC_FAIL_SFT, 0);
+emif_state_attr(cal_fail, EMIF_STAT_CALC_FAIL_SFT, 1);
+emif_state_attr(cal_fail, EMIF_STAT_CALC_FAIL_SFT, 2);
+emif_state_attr(cal_fail, EMIF_STAT_CALC_FAIL_SFT, 3);
+
+emif_clear_attr(0);
+emif_clear_attr(1);
+emif_clear_attr(2);
+emif_clear_attr(3);
+
+static struct attribute *dfl_emif_attrs[] = {
+ &emif_attr_inf0_init_done.attr.attr,
+ &emif_attr_inf0_cal_fail.attr.attr,
+ &emif_attr_inf0_clear.attr.attr,
+
+ &emif_attr_inf1_init_done.attr.attr,
+ &emif_attr_inf1_cal_fail.attr.attr,
+ &emif_attr_inf1_clear.attr.attr,
+
+ &emif_attr_inf2_init_done.attr.attr,
+ &emif_attr_inf2_cal_fail.attr.attr,
+ &emif_attr_inf2_clear.attr.attr,
+
+ &emif_attr_inf3_init_done.attr.attr,
+ &emif_attr_inf3_cal_fail.attr.attr,
+ &emif_attr_inf3_clear.attr.attr,
+
+ NULL,
+};
+
+static umode_t dfl_emif_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct dfl_emif *de = dev_get_drvdata(kobj_to_dev(kobj));
+ struct emif_attr *eattr = container_of(attr, struct emif_attr,
+ attr.attr);
+ u64 val;
+
+ /*
+ * This device supports upto 4 memory interfaces, but not all
+ * interfaces are used on different platforms. The read out value of
+ * CLEAN_EN field (which is a bitmap) could tell how many interfaces
+ * are available.
+ */
+ val = FIELD_GET(EMIF_CTRL_CLEAR_EN_MSK, readq(de->base + EMIF_CTRL));
+
+ return (val & BIT_ULL(eattr->index)) ? attr->mode : 0;
+}
+
+static const struct attribute_group dfl_emif_group = {
+ .is_visible = dfl_emif_visible,
+ .attrs = dfl_emif_attrs,
+};
+
+static const struct attribute_group *dfl_emif_groups[] = {
+ &dfl_emif_group,
+ NULL,
+};
+
+static int dfl_emif_probe(struct dfl_device *ddev)
+{
+ struct device *dev = &ddev->dev;
+ struct dfl_emif *de;
+
+ de = devm_kzalloc(dev, sizeof(*de), GFP_KERNEL);
+ if (!de)
+ return -ENOMEM;
+
+ de->base = devm_ioremap_resource(dev, &ddev->mmio_res);
+ if (IS_ERR(de->base))
+ return PTR_ERR(de->base);
+
+ de->dev = dev;
+ spin_lock_init(&de->lock);
+ dev_set_drvdata(dev, de);
+
+ return 0;
+}
+
+static const struct dfl_device_id dfl_emif_ids[] = {
+ { FME_ID, FME_FEATURE_ID_EMIF },
+ { }
+};
+MODULE_DEVICE_TABLE(dfl, dfl_emif_ids);
+
+static struct dfl_driver dfl_emif_driver = {
+ .drv = {
+ .name = "dfl-emif",
+ .dev_groups = dfl_emif_groups,
+ },
+ .id_table = dfl_emif_ids,
+ .probe = dfl_emif_probe,
+};
+module_dfl_driver(dfl_emif_driver);
+
+MODULE_DESCRIPTION("DFL EMIF driver");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
--
2.30.0
^ permalink raw reply related [flat|nested] 27+ messages in thread* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
` (7 preceding siblings ...)
2021-01-07 4:37 ` [PATCH 8/8] memory: dfl-emif: add the DFL EMIF private feature driver Moritz Fischer
@ 2021-01-07 16:09 ` Tom Rix
2021-01-07 16:14 ` Greg KH
2021-01-10 15:46 ` Tom Rix
8 siblings, 2 replies; 27+ messages in thread
From: Tom Rix @ 2021-01-07 16:09 UTC (permalink / raw)
To: Moritz Fischer, gregkh; +Cc: linux-fpga, linux-kernel, moritzf
On 1/6/21 8:37 PM, Moritz Fischer wrote:
> This is a resend of the previous (unfortunately late) patchset of
> changes for FPGA DFL.
Is there something I can do to help ?
I am paid to look after linux-fpga, so i have plenty of time.
Some ideas of what i am doing now privately i can do publicly.
1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
2. an in-flight dev branch for the outstanding patches
Tom
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-07 16:09 ` [PATCH 0/8] FPGA DFL Changes for 5.12 Tom Rix
@ 2021-01-07 16:14 ` Greg KH
2021-01-07 17:01 ` Tom Rix
2021-01-10 15:46 ` Tom Rix
1 sibling, 1 reply; 27+ messages in thread
From: Greg KH @ 2021-01-07 16:14 UTC (permalink / raw)
To: Tom Rix; +Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf
On Thu, Jan 07, 2021 at 08:09:12AM -0800, Tom Rix wrote:
>
> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> > This is a resend of the previous (unfortunately late) patchset of
> > changes for FPGA DFL.
>
> Is there something I can do to help ?
This is all now merged in my tree, so there's not much left to do here
:)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-07 16:14 ` Greg KH
@ 2021-01-07 17:01 ` Tom Rix
0 siblings, 0 replies; 27+ messages in thread
From: Tom Rix @ 2021-01-07 17:01 UTC (permalink / raw)
To: Greg KH; +Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf
On 1/7/21 8:14 AM, Greg KH wrote:
> On Thu, Jan 07, 2021 at 08:09:12AM -0800, Tom Rix wrote:
>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>> This is a resend of the previous (unfortunately late) patchset of
>>> changes for FPGA DFL.
>> Is there something I can do to help ?
> This is all now merged in my tree, so there's not much left to do here
> :)
Yes this patchset is done now.
I am offering to help in an ongoing manner, something like 10hr/week would be easy as i already spend about 30hr/week doing stuff in the kernel in addition to reviewing linux-fpga.
Tom
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-07 16:09 ` [PATCH 0/8] FPGA DFL Changes for 5.12 Tom Rix
2021-01-07 16:14 ` Greg KH
@ 2021-01-10 15:46 ` Tom Rix
2021-01-10 17:05 ` Moritz Fischer
1 sibling, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-10 15:46 UTC (permalink / raw)
To: Moritz Fischer, gregkh, linux-fpga
Cc: linux-kernel, moritzf, Rikard Falkeborn, Zheng Yongjun,
Russ Weight, Gerlach, Matthew, Sonal Santan, Xu Yilun,
Richard Gong
On 1/7/21 8:09 AM, Tom Rix wrote:
> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>> This is a resend of the previous (unfortunately late) patchset of
>> changes for FPGA DFL.
> Is there something I can do to help ?
>
> I am paid to look after linux-fpga, so i have plenty of time.
>
> Some ideas of what i am doing now privately i can do publicly.
>
> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>
> 2. an in-flight dev branch for the outstanding patches
I have setup these branches based on Greg's char-misc-next
fpga-next, which is char-misc-next base for fpga-testing
fpga-testing, all the in-flight patches that would apply with automatic merge conflict resolution
These are respectively
https://github.com/trixirt/linux-fpga/tree/fpga-next
https://github.com/trixirt/linux-fpga/tree/fpga-testing
There are two trivial changes, that could go to 5.12 now.
fpga: dfl: fme: Constify static attribute_group structs
fpga: Use DEFINE_SPINLOCK() for spinlock
respectively
https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeborn@gmail.com/
https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongjun3@huawei.com/
There are a couple of patchsets that conflict
https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.weight@intel.com/
https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerlach@linux.intel.com/
Which I will follow up on.
And the xilinx patchset
https://lore.kernel.org/linux-fpga/20201217075046.28553-1-sonals@xilinx.com/
Which is being split/worked on offline.
If I have missed any patchset, poke me.
Tom
>
> Tom
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-10 15:46 ` Tom Rix
@ 2021-01-10 17:05 ` Moritz Fischer
2021-01-10 19:43 ` Tom Rix
0 siblings, 1 reply; 27+ messages in thread
From: Moritz Fischer @ 2021-01-10 17:05 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, gregkh, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
Tom,
On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>
> On 1/7/21 8:09 AM, Tom Rix wrote:
> > On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >> This is a resend of the previous (unfortunately late) patchset of
> >> changes for FPGA DFL.
> > Is there something I can do to help ?
> >
> > I am paid to look after linux-fpga, so i have plenty of time.
> >
> > Some ideas of what i am doing now privately i can do publicly.
> >
> > 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
Is it not? It currently points to v5.11-rc1. If I start applying patches
that require the changes that went into Greg's branch I can merge.
> >
> > 2. an in-flight dev branch for the outstanding patches
>
> I have setup these branches based on Greg's char-misc-next
>
> fpga-next, which is char-misc-next base for fpga-testing
>
> fpga-testing, all the in-flight patches that would apply with automatic merge conflict resolution
>
> These are respectively
>
> https://github.com/trixirt/linux-fpga/tree/fpga-next
>
> https://github.com/trixirt/linux-fpga/tree/fpga-testing
Feel free to have your own repos/branches etc, but I'd like to keep the
offical trees on kernel.org.
Tbh I'd much rather see the patchwork instance be cleaned up if you want
to do stuff.
>
>
> There are two trivial changes, that could go to 5.12 now.
>
> fpga: dfl: fme: Constify static attribute_group structs
>
> fpga: Use DEFINE_SPINLOCK() for spinlock
>
> respectively
>
> https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeborn@gmail.com/
>
> https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongjun3@huawei.com/
I was going to pick them up monday ...
>
>
> There are a couple of patchsets that conflict
>
> https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.weight@intel.com/
>
> https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerlach@linux.intel.com/
Conflict between what and what?
> And the xilinx patchset
>
> https://lore.kernel.org/linux-fpga/20201217075046.28553-1-sonals@xilinx.com/
>
> Which is being split/worked on offline.
I'm not sure what that means.
>
>
> If I have missed any patchset, poke me.
>
> Tom
- Moritz
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-10 17:05 ` Moritz Fischer
@ 2021-01-10 19:43 ` Tom Rix
2021-01-11 6:57 ` Greg KH
0 siblings, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-10 19:43 UTC (permalink / raw)
To: Moritz Fischer
Cc: gregkh, linux-fpga, linux-kernel, moritzf, Rikard Falkeborn,
Zheng Yongjun, Russ Weight, Gerlach, Matthew, Sonal Santan,
Xu Yilun, Richard Gong
On 1/10/21 9:05 AM, Moritz Fischer wrote:
> Tom,
>
> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>> This is a resend of the previous (unfortunately late) patchset of
>>>> changes for FPGA DFL.
>>> Is there something I can do to help ?
>>>
>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>
>>> Some ideas of what i am doing now privately i can do publicly.
>>>
>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> Is it not? It currently points to v5.11-rc1. If I start applying patches
> that require the changes that went into Greg's branch I can merge.
I mean the window between when we have staged patches and when they go into Greg's branch.
We don't have any now, maybe those two trival ones.
Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
There are no outstanding fixes so all changes would go to -next.
>>> 2. an in-flight dev branch for the outstanding patches
>> I have setup these branches based on Greg's char-misc-next
>>
>> fpga-next, which is char-misc-next base for fpga-testing
>>
>> fpga-testing, all the in-flight patches that would apply with automatic merge conflict resolution
>>
>> These are respectively
>>
>> https://github.com/trixirt/linux-fpga/tree/fpga-next
>>
>> https://github.com/trixirt/linux-fpga/tree/fpga-testing
> Feel free to have your own repos/branches etc, but I'd like to keep the
> offical trees on kernel.org.
Is there a way for me to move these to kernel.org ?
>
> Tbh I'd much rather see the patchwork instance be cleaned up if you want
> to do stuff.
Please point me at the wreckage and I will clean it up.
>>
>> There are two trivial changes, that could go to 5.12 now.
>>
>> fpga: dfl: fme: Constify static attribute_group structs
>>
>> fpga: Use DEFINE_SPINLOCK() for spinlock
>>
>> respectively
>>
>> https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeborn@gmail.com/
>>
>> https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongjun3@huawei.com/
> I was going to pick them up monday ...
>>
>> There are a couple of patchsets that conflict
>>
>> https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.weight@intel.com/
>>
>> https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerlach@linux.intel.com/
> Conflict between what and what?
There are basic git am ... applying problems.
By having a -testing branch it is easier to see where the conficts with all the outstanding patchsets.
>
>> And the xilinx patchset
>>
>> https://lore.kernel.org/linux-fpga/20201217075046.28553-1-sonals@xilinx.com/
>>
>> Which is being split/worked on offline.
> I'm not sure what that means.
Don't worry about this until a new patchset lands.
Tom
>>
>> If I have missed any patchset, poke me.
>>
>> Tom
> - Moritz
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-10 19:43 ` Tom Rix
@ 2021-01-11 6:57 ` Greg KH
2021-01-11 14:40 ` Tom Rix
0 siblings, 1 reply; 27+ messages in thread
From: Greg KH @ 2021-01-11 6:57 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>
> On 1/10/21 9:05 AM, Moritz Fischer wrote:
> > Tom,
> >
> > On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> >> On 1/7/21 8:09 AM, Tom Rix wrote:
> >>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >>>> This is a resend of the previous (unfortunately late) patchset of
> >>>> changes for FPGA DFL.
> >>> Is there something I can do to help ?
> >>>
> >>> I am paid to look after linux-fpga, so i have plenty of time.
> >>>
> >>> Some ideas of what i am doing now privately i can do publicly.
> >>>
> >>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> > Is it not? It currently points to v5.11-rc1. If I start applying patches
> > that require the changes that went into Greg's branch I can merge.
>
> I mean the window between when we have staged patches and when they go into Greg's branch.
>
> We don't have any now, maybe those two trival ones.
>
> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
Ick, no! NEVER rebase a public branch. Why does it matter the speed of
my branch vs. anyone elses? Git handles merges very well.
Just like Linus's branches move much faster than mine, and I don't
rebase my branches, you shouldn't rebase yours.
Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
git pulls, so why does it matter at all for any of this?
What is the problem you are trying to solve here?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 6:57 ` Greg KH
@ 2021-01-11 14:40 ` Tom Rix
2021-01-11 14:54 ` Greg KH
0 siblings, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-11 14:40 UTC (permalink / raw)
To: Greg KH
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On 1/10/21 10:57 PM, Greg KH wrote:
> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
>>> Tom,
>>>
>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>>>> This is a resend of the previous (unfortunately late) patchset of
>>>>>> changes for FPGA DFL.
>>>>> Is there something I can do to help ?
>>>>>
>>>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>>>
>>>>> Some ideas of what i am doing now privately i can do publicly.
>>>>>
>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
>>> that require the changes that went into Greg's branch I can merge.
>> I mean the window between when we have staged patches and when they go into Greg's branch.
>>
>> We don't have any now, maybe those two trival ones.
>>
>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> my branch vs. anyone elses? Git handles merges very well.
>
> Just like Linus's branches move much faster than mine, and I don't
> rebase my branches, you shouldn't rebase yours.
>
> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> git pulls, so why does it matter at all for any of this?
>
> What is the problem you are trying to solve here?
This 5.12 fpga patchset not making it into 5.11.
At some point before the 5.11 window, I tried it on next and it failed to merge.
This points to needing some c/i so it does not happen again.
Tom
>
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 14:40 ` Tom Rix
@ 2021-01-11 14:54 ` Greg KH
2021-01-11 15:55 ` Tom Rix
0 siblings, 1 reply; 27+ messages in thread
From: Greg KH @ 2021-01-11 14:54 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>
> On 1/10/21 10:57 PM, Greg KH wrote:
> > On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >> On 1/10/21 9:05 AM, Moritz Fischer wrote:
> >>> Tom,
> >>>
> >>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> >>>> On 1/7/21 8:09 AM, Tom Rix wrote:
> >>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >>>>>> This is a resend of the previous (unfortunately late) patchset of
> >>>>>> changes for FPGA DFL.
> >>>>> Is there something I can do to help ?
> >>>>>
> >>>>> I am paid to look after linux-fpga, so i have plenty of time.
> >>>>>
> >>>>> Some ideas of what i am doing now privately i can do publicly.
> >>>>>
> >>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> >>> Is it not? It currently points to v5.11-rc1. If I start applying patches
> >>> that require the changes that went into Greg's branch I can merge.
> >> I mean the window between when we have staged patches and when they go into Greg's branch.
> >>
> >> We don't have any now, maybe those two trival ones.
> >>
> >> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
> > Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> > my branch vs. anyone elses? Git handles merges very well.
> >
> > Just like Linus's branches move much faster than mine, and I don't
> > rebase my branches, you shouldn't rebase yours.
> >
> > Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> > git pulls, so why does it matter at all for any of this?
> >
> > What is the problem you are trying to solve here?
>
> This 5.12 fpga patchset not making it into 5.11.
Ok, but isn't it the responsibility of the submitter to make sure they
apply properly when sending them out?
> At some point before the 5.11 window, I tried it on next and it failed to merge.
>
> This points to needing some c/i so it does not happen again.
"again"? Merges and the like are a totally normal thing and happen all
the time, I still fail to understand what you are trying to "solve" for
here...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 14:54 ` Greg KH
@ 2021-01-11 15:55 ` Tom Rix
2021-01-11 16:09 ` Greg KH
0 siblings, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-11 15:55 UTC (permalink / raw)
To: Greg KH
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On 1/11/21 6:54 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>> On 1/10/21 10:57 PM, Greg KH wrote:
>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
>>>>> Tom,
>>>>>
>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
>>>>>>>> changes for FPGA DFL.
>>>>>>> Is there something I can do to help ?
>>>>>>>
>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>>>>>
>>>>>>> Some ideas of what i am doing now privately i can do publicly.
>>>>>>>
>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
>>>>> that require the changes that went into Greg's branch I can merge.
>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
>>>>
>>>> We don't have any now, maybe those two trival ones.
>>>>
>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>> my branch vs. anyone elses? Git handles merges very well.
>>>
>>> Just like Linus's branches move much faster than mine, and I don't
>>> rebase my branches, you shouldn't rebase yours.
>>>
>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>> git pulls, so why does it matter at all for any of this?
>>>
>>> What is the problem you are trying to solve here?
>> This 5.12 fpga patchset not making it into 5.11.
> Ok, but isn't it the responsibility of the submitter to make sure they
> apply properly when sending them out?
>
>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>
>> This points to needing some c/i so it does not happen again.
> "again"? Merges and the like are a totally normal thing and happen all
> the time, I still fail to understand what you are trying to "solve" for
> here...
What can I do to help make your merges as easy as possible ?
Does the patchwork infra Moritz was speaking of earlier need fixing help?
Any other things ?
Tom
>
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 15:55 ` Tom Rix
@ 2021-01-11 16:09 ` Greg KH
2021-01-11 16:43 ` Tom Rix
0 siblings, 1 reply; 27+ messages in thread
From: Greg KH @ 2021-01-11 16:09 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>
> On 1/11/21 6:54 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >> On 1/10/21 10:57 PM, Greg KH wrote:
> >>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
> >>>>> Tom,
> >>>>>
> >>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> >>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
> >>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >>>>>>>> This is a resend of the previous (unfortunately late) patchset of
> >>>>>>>> changes for FPGA DFL.
> >>>>>>> Is there something I can do to help ?
> >>>>>>>
> >>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
> >>>>>>>
> >>>>>>> Some ideas of what i am doing now privately i can do publicly.
> >>>>>>>
> >>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> >>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
> >>>>> that require the changes that went into Greg's branch I can merge.
> >>>> I mean the window between when we have staged patches and when they go into Greg's branch.
> >>>>
> >>>> We don't have any now, maybe those two trival ones.
> >>>>
> >>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
> >>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>> my branch vs. anyone elses? Git handles merges very well.
> >>>
> >>> Just like Linus's branches move much faster than mine, and I don't
> >>> rebase my branches, you shouldn't rebase yours.
> >>>
> >>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>> git pulls, so why does it matter at all for any of this?
> >>>
> >>> What is the problem you are trying to solve here?
> >> This 5.12 fpga patchset not making it into 5.11.
> > Ok, but isn't it the responsibility of the submitter to make sure they
> > apply properly when sending them out?
> >
> >> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>
> >> This points to needing some c/i so it does not happen again.
> > "again"? Merges and the like are a totally normal thing and happen all
> > the time, I still fail to understand what you are trying to "solve" for
> > here...
>
> What can I do to help make your merges as easy as possible ?
I have not had any problems with merges, I've only had "problems"
rejecting patches for their content.
Try helping out with patch reviews if you want, finding and fixing
things before I review them is usually a good idea :)
> Does the patchwork infra Moritz was speaking of earlier need fixing help?
No idea, I don't use it.
> Any other things ?
What problems are you trying to solve here? What's wrong with how this
subsystem is working that you are feeling needs to be addressed?
confused,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 16:09 ` Greg KH
@ 2021-01-11 16:43 ` Tom Rix
2021-01-11 18:21 ` Greg KH
0 siblings, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-11 16:43 UTC (permalink / raw)
To: Greg KH
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On 1/11/21 8:09 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>> On 1/11/21 6:54 AM, Greg KH wrote:
>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>>>> On 1/10/21 10:57 PM, Greg KH wrote:
>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
>>>>>>> Tom,
>>>>>>>
>>>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>>>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
>>>>>>>>>> changes for FPGA DFL.
>>>>>>>>> Is there something I can do to help ?
>>>>>>>>>
>>>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>>>>>>>
>>>>>>>>> Some ideas of what i am doing now privately i can do publicly.
>>>>>>>>>
>>>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>>>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
>>>>>>> that require the changes that went into Greg's branch I can merge.
>>>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
>>>>>>
>>>>>> We don't have any now, maybe those two trival ones.
>>>>>>
>>>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>>>> my branch vs. anyone elses? Git handles merges very well.
>>>>>
>>>>> Just like Linus's branches move much faster than mine, and I don't
>>>>> rebase my branches, you shouldn't rebase yours.
>>>>>
>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>>>> git pulls, so why does it matter at all for any of this?
>>>>>
>>>>> What is the problem you are trying to solve here?
>>>> This 5.12 fpga patchset not making it into 5.11.
>>> Ok, but isn't it the responsibility of the submitter to make sure they
>>> apply properly when sending them out?
>>>
>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>>>
>>>> This points to needing some c/i so it does not happen again.
>>> "again"? Merges and the like are a totally normal thing and happen all
>>> the time, I still fail to understand what you are trying to "solve" for
>>> here...
>> What can I do to help make your merges as easy as possible ?
> I have not had any problems with merges, I've only had "problems"
> rejecting patches for their content.
>
> Try helping out with patch reviews if you want, finding and fixing
> things before I review them is usually a good idea :)
ok.
>
>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> No idea, I don't use it.
>
>> Any other things ?
> What problems are you trying to solve here? What's wrong with how this
> subsystem is working that you are feeling needs to be addressed?
I do not believe the issue I raised in 5.10 has made any progress.
If you look at the content in 5.11 we have actually regressed.
https://lore.kernel.org/linux-fpga/3295710c-5e82-7b97-43de-99b9870a8c8c@redhat.com/
Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
So I am asking for
diff --git a/MAINTAINERS b/MAINTAINERS
index 11b38acb4c08..269cd08f4969 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6951,7 +6951,7 @@ F: drivers/net/ethernet/nvidia/*
FPGA DFL DRIVERS
M: Wu Hao <hao.wu@intel.com>
-R: Tom Rix <trix@redhat.com>
+M: Tom Rix <trix@redhat.com>
L: linux-fpga@vger.kernel.org
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-dfl*
@@ -6962,7 +6962,7 @@ F: include/uapi/linux/fpga-dfl.h
FPGA MANAGER FRAMEWORK
M: Moritz Fischer <mdf@kernel.org>
-R: Tom Rix <trix@redhat.com>
+M: Tom Rix <trix@redhat.com>
L: linux-fpga@vger.kernel.org
S: Maintained
W: http://www.rocketboards.org
And to use/maintain my fpga-next and fpga-testing as official kernel.org branches.
Tom
>
> confused,
>
> greg k-h
>
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 16:43 ` Tom Rix
@ 2021-01-11 18:21 ` Greg KH
2021-01-11 19:46 ` Tom Rix
0 siblings, 1 reply; 27+ messages in thread
From: Greg KH @ 2021-01-11 18:21 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
>
> On 1/11/21 8:09 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
> >> On 1/11/21 6:54 AM, Greg KH wrote:
> >>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >>>> On 1/10/21 10:57 PM, Greg KH wrote:
> >>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
> >>>>>>> Tom,
> >>>>>>>
> >>>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> >>>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
> >>>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >>>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
> >>>>>>>>>> changes for FPGA DFL.
> >>>>>>>>> Is there something I can do to help ?
> >>>>>>>>>
> >>>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
> >>>>>>>>>
> >>>>>>>>> Some ideas of what i am doing now privately i can do publicly.
> >>>>>>>>>
> >>>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> >>>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
> >>>>>>> that require the changes that went into Greg's branch I can merge.
> >>>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
> >>>>>>
> >>>>>> We don't have any now, maybe those two trival ones.
> >>>>>>
> >>>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
> >>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>>>> my branch vs. anyone elses? Git handles merges very well.
> >>>>>
> >>>>> Just like Linus's branches move much faster than mine, and I don't
> >>>>> rebase my branches, you shouldn't rebase yours.
> >>>>>
> >>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>>>> git pulls, so why does it matter at all for any of this?
> >>>>>
> >>>>> What is the problem you are trying to solve here?
> >>>> This 5.12 fpga patchset not making it into 5.11.
> >>> Ok, but isn't it the responsibility of the submitter to make sure they
> >>> apply properly when sending them out?
> >>>
> >>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>>>
> >>>> This points to needing some c/i so it does not happen again.
> >>> "again"? Merges and the like are a totally normal thing and happen all
> >>> the time, I still fail to understand what you are trying to "solve" for
> >>> here...
> >> What can I do to help make your merges as easy as possible ?
> > I have not had any problems with merges, I've only had "problems"
> > rejecting patches for their content.
> >
> > Try helping out with patch reviews if you want, finding and fixing
> > things before I review them is usually a good idea :)
> ok.
> >
> >> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> > No idea, I don't use it.
> >
> >> Any other things ?
> > What problems are you trying to solve here? What's wrong with how this
> > subsystem is working that you are feeling needs to be addressed?
>
> I do not believe the issue I raised in 5.10 has made any progress.
What issue?
> If you look at the content in 5.11 we have actually regressed.
What bugs regressed?
> https://lore.kernel.org/linux-fpga/3295710c-5e82-7b97-43de-99b9870a8c8c@redhat.com/
I don't see the problem here, other than a low-quality of patches that
need reworking for some patchsets, and others are just fine. Just like
all kernel subsystems, I don't see anything odd here.
> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
That's not how any of this works :)
> So I am asking for
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 11b38acb4c08..269cd08f4969 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6951,7 +6951,7 @@ F: drivers/net/ethernet/nvidia/*
>
> FPGA DFL DRIVERS
> M: Wu Hao <hao.wu@intel.com>
> -R: Tom Rix <trix@redhat.com>
> +M: Tom Rix <trix@redhat.com>
That's generous, but how about doing review first, the maintainership of
this subsystem does not feel like any sort of bottleneck to me. I
personally have no problems with Moritz's interactions with the
community, his reviewing of patches, and forwarding on to me.
Of course we all have delays as we have other work to do than just this,
that's just part of normal development. I don't see anything stalled at
the moment, nor anything that having another maintainer would have
helped out with at all, so this feels like it is not needed from my end.
Again, it feels like the developers need more reviews, and good ones, so
please continue to help out with that, as that's the best thing I can
see to do here.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 18:21 ` Greg KH
@ 2021-01-11 19:46 ` Tom Rix
2021-01-11 20:03 ` Greg KH
2021-01-11 20:28 ` Moritz Fischer
0 siblings, 2 replies; 27+ messages in thread
From: Tom Rix @ 2021-01-11 19:46 UTC (permalink / raw)
To: Greg KH
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On 1/11/21 10:21 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
>> On 1/11/21 8:09 AM, Greg KH wrote:
>>> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>>>> On 1/11/21 6:54 AM, Greg KH wrote:
>>>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>>>>>> On 1/10/21 10:57 PM, Greg KH wrote:
>>>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>>>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
>>>>>>>>> Tom,
>>>>>>>>>
>>>>>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>>>>>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>>>>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>>>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
>>>>>>>>>>>> changes for FPGA DFL.
>>>>>>>>>>> Is there something I can do to help ?
>>>>>>>>>>>
>>>>>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>>>>>>>>>
>>>>>>>>>>> Some ideas of what i am doing now privately i can do publicly.
>>>>>>>>>>>
>>>>>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>>>>>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
>>>>>>>>> that require the changes that went into Greg's branch I can merge.
>>>>>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
>>>>>>>>
>>>>>>>> We don't have any now, maybe those two trival ones.
>>>>>>>>
>>>>>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
>>>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
>>>>>>> my branch vs. anyone elses? Git handles merges very well.
>>>>>>>
>>>>>>> Just like Linus's branches move much faster than mine, and I don't
>>>>>>> rebase my branches, you shouldn't rebase yours.
>>>>>>>
>>>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>>>>>> git pulls, so why does it matter at all for any of this?
>>>>>>>
>>>>>>> What is the problem you are trying to solve here?
>>>>>> This 5.12 fpga patchset not making it into 5.11.
>>>>> Ok, but isn't it the responsibility of the submitter to make sure they
>>>>> apply properly when sending them out?
>>>>>
>>>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>>>>>
>>>>>> This points to needing some c/i so it does not happen again.
>>>>> "again"? Merges and the like are a totally normal thing and happen all
>>>>> the time, I still fail to understand what you are trying to "solve" for
>>>>> here...
>>>> What can I do to help make your merges as easy as possible ?
>>> I have not had any problems with merges, I've only had "problems"
>>> rejecting patches for their content.
>>>
>>> Try helping out with patch reviews if you want, finding and fixing
>>> things before I review them is usually a good idea :)
>> ok.
>>>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
>>> No idea, I don't use it.
>>>
>>>> Any other things ?
>>> What problems are you trying to solve here? What's wrong with how this
>>> subsystem is working that you are feeling needs to be addressed?
>> I do not believe the issue I raised in 5.10 has made any progress.
> What issue?
>
>> If you look at the content in 5.11 we have actually regressed.
> What bugs regressed?
>
>> https://lore.kernel.org/linux-fpga/3295710c-5e82-7b97-43de-99b9870a8c8c@redhat.com/
> I don't see the problem here, other than a low-quality of patches that
> need reworking for some patchsets, and others are just fine. Just like
> all kernel subsystems, I don't see anything odd here.
>
>> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
> That's not how any of this works :)
>
>> So I am asking for
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 11b38acb4c08..269cd08f4969 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6951,7 +6951,7 @@ F: drivers/net/ethernet/nvidia/*
>>
>> FPGA DFL DRIVERS
>> M: Wu Hao <hao.wu@intel.com>
>> -R: Tom Rix <trix@redhat.com>
>> +M: Tom Rix <trix@redhat.com>
> That's generous, but how about doing review first, the maintainership of
> this subsystem does not feel like any sort of bottleneck to me. I
> personally have no problems with Moritz's interactions with the
> community, his reviewing of patches, and forwarding on to me.
>
> Of course we all have delays as we have other work to do than just this,
> that's just part of normal development. I don't see anything stalled at
> the moment, nor anything that having another maintainer would have
> helped out with at all, so this feels like it is not needed from my end.
>
> Again, it feels like the developers need more reviews, and good ones, so
> please continue to help out with that, as that's the best thing I can
> see to do here.
I have been doing the first review in a couple of days after every patch landing.
I see some pretty good response from the developers to fix the issues raised.
But I do not see Moritz picking up the review until weeks later.
This consistent delay in timely reviews is a bottleneck.
It would be good if the big first reviews could be done in parallel.
Tom
>
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 19:46 ` Tom Rix
@ 2021-01-11 20:03 ` Greg KH
2021-01-11 20:28 ` Moritz Fischer
1 sibling, 0 replies; 27+ messages in thread
From: Greg KH @ 2021-01-11 20:03 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
>
> On 1/11/21 10:21 AM, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
> >> On 1/11/21 8:09 AM, Greg KH wrote:
> >>> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
> >>>> On 1/11/21 6:54 AM, Greg KH wrote:
> >>>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
> >>>>>> On 1/10/21 10:57 PM, Greg KH wrote:
> >>>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
> >>>>>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
> >>>>>>>>> Tom,
> >>>>>>>>>
> >>>>>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> >>>>>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
> >>>>>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >>>>>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
> >>>>>>>>>>>> changes for FPGA DFL.
> >>>>>>>>>>> Is there something I can do to help ?
> >>>>>>>>>>>
> >>>>>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
> >>>>>>>>>>>
> >>>>>>>>>>> Some ideas of what i am doing now privately i can do publicly.
> >>>>>>>>>>>
> >>>>>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
> >>>>>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
> >>>>>>>>> that require the changes that went into Greg's branch I can merge.
> >>>>>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
> >>>>>>>>
> >>>>>>>> We don't have any now, maybe those two trival ones.
> >>>>>>>>
> >>>>>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
> >>>>>>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of
> >>>>>>> my branch vs. anyone elses? Git handles merges very well.
> >>>>>>>
> >>>>>>> Just like Linus's branches move much faster than mine, and I don't
> >>>>>>> rebase my branches, you shouldn't rebase yours.
> >>>>>>>
> >>>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
> >>>>>>> git pulls, so why does it matter at all for any of this?
> >>>>>>>
> >>>>>>> What is the problem you are trying to solve here?
> >>>>>> This 5.12 fpga patchset not making it into 5.11.
> >>>>> Ok, but isn't it the responsibility of the submitter to make sure they
> >>>>> apply properly when sending them out?
> >>>>>
> >>>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
> >>>>>>
> >>>>>> This points to needing some c/i so it does not happen again.
> >>>>> "again"? Merges and the like are a totally normal thing and happen all
> >>>>> the time, I still fail to understand what you are trying to "solve" for
> >>>>> here...
> >>>> What can I do to help make your merges as easy as possible ?
> >>> I have not had any problems with merges, I've only had "problems"
> >>> rejecting patches for their content.
> >>>
> >>> Try helping out with patch reviews if you want, finding and fixing
> >>> things before I review them is usually a good idea :)
> >> ok.
> >>>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
> >>> No idea, I don't use it.
> >>>
> >>>> Any other things ?
> >>> What problems are you trying to solve here? What's wrong with how this
> >>> subsystem is working that you are feeling needs to be addressed?
> >> I do not believe the issue I raised in 5.10 has made any progress.
> > What issue?
> >
> >> If you look at the content in 5.11 we have actually regressed.
> > What bugs regressed?
> >
> >> https://lore.kernel.org/linux-fpga/3295710c-5e82-7b97-43de-99b9870a8c8c@redhat.com/
> > I don't see the problem here, other than a low-quality of patches that
> > need reworking for some patchsets, and others are just fine. Just like
> > all kernel subsystems, I don't see anything odd here.
> >
> >> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
> > That's not how any of this works :)
> >
> >> So I am asking for
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 11b38acb4c08..269cd08f4969 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -6951,7 +6951,7 @@ F: drivers/net/ethernet/nvidia/*
> >>
> >> FPGA DFL DRIVERS
> >> M: Wu Hao <hao.wu@intel.com>
> >> -R: Tom Rix <trix@redhat.com>
> >> +M: Tom Rix <trix@redhat.com>
> > That's generous, but how about doing review first, the maintainership of
> > this subsystem does not feel like any sort of bottleneck to me. I
> > personally have no problems with Moritz's interactions with the
> > community, his reviewing of patches, and forwarding on to me.
> >
> > Of course we all have delays as we have other work to do than just this,
> > that's just part of normal development. I don't see anything stalled at
> > the moment, nor anything that having another maintainer would have
> > helped out with at all, so this feels like it is not needed from my end.
> >
> > Again, it feels like the developers need more reviews, and good ones, so
> > please continue to help out with that, as that's the best thing I can
> > see to do here.
>
> I have been doing the first review in a couple of days after every patch landing.
>
> I see some pretty good response from the developers to fix the issues raised.
>
> But I do not see Moritz picking up the review until weeks later.
>
> This consistent delay in timely reviews is a bottleneck.
What is being prevented from merging at this moment because of this?
There is always ebbs and flows with patch reviews, what do you consider
"manditory" time to review a patch from a maintainer?
Remember, we are almost all doing this not as our paid job, but as part
of what we do.
And to be frank, I personally have been putting the fpga patchset at the
_end_ of my reviews because of the quality of them in the past. While
it is slowly getting better, you all have a big hole to dig out from,
and maybe you need to step up your reviews to raise that bar so I don't
dread seeing them in my review queue :)
> It would be good if the big first reviews could be done in parallel.
parallel with what?
All I'm getting here is "I wish patches were accepted faster!" from you.
When personally, I think they are being accepted at a very nice rate for
such a tiny subsystem.
Good luck with your reviews,
greg k-h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 19:46 ` Tom Rix
2021-01-11 20:03 ` Greg KH
@ 2021-01-11 20:28 ` Moritz Fischer
2021-01-11 22:39 ` Tom Rix
1 sibling, 1 reply; 27+ messages in thread
From: Moritz Fischer @ 2021-01-11 20:28 UTC (permalink / raw)
To: Tom Rix
Cc: Greg KH, Moritz Fischer, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
Tom,
On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
[..]
> I have been doing the first review in a couple of days after every patch landing.
I appreciate your help with doing reviews.
> I see some pretty good response from the developers to fix the issues raised.
... yet patches have been rejected. So it doesn't seem purely a matter
of throughput?
> But I do not see Moritz picking up the review until weeks later.
I'll admit there are delays that happen, I have a dayjob as I pointed
out in earlier conversations. Furthermore, just because I do not
immediately send out an email does not mean I don't look at stuff.
If people show up with 100kLOC patchsets that don't pass checkpatch,
it'll take a while for me to even read up and understand what they're
doing / trying to do.
> This consistent delay in timely reviews is a bottleneck.
As Greg pointed out even ones that were reviewed got rejected, so
clearly the issue is with the quality and not the speed at which we send
them on.
> It would be good if the big first reviews could be done in parallel.
Again depending how the patchsets are structured it will take me a while
to process. Having them re-use existing infrastructure, following
coding and submission guidelines will speed up the process.
On a personal level, being told I'm too slow and not doing my job as
maintainer doesn't exactly increase my motivation to get to it ...
- Moritz
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 20:28 ` Moritz Fischer
@ 2021-01-11 22:39 ` Tom Rix
2021-01-14 16:48 ` Moritz Fischer
0 siblings, 1 reply; 27+ messages in thread
From: Tom Rix @ 2021-01-11 22:39 UTC (permalink / raw)
To: Moritz Fischer
Cc: Greg KH, linux-fpga, linux-kernel, moritzf, Rikard Falkeborn,
Zheng Yongjun, Russ Weight, Gerlach, Matthew, Sonal Santan,
Xu Yilun, Richard Gong
On 1/11/21 12:28 PM, Moritz Fischer wrote:
> Tom,
>
> On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
>
> [..]
>> I have been doing the first review in a couple of days after every patch landing.
> I appreciate your help with doing reviews.
>
>> I see some pretty good response from the developers to fix the issues raised.ÂÂ
> ... yet patches have been rejected. So it doesn't seem purely a matter
> of throughput?
>
>> But I do not see Moritz picking up the review until weeks later.
> I'll admit there are delays that happen, I have a dayjob as I pointed
> out in earlier conversations. Furthermore, just because I do not
> immediately send out an email does not mean I don't look at stuff.
>
> If people show up with 100kLOC patchsets that don't pass checkpatch,
> it'll take a while for me to even read up and understand what they're
> doing / trying to do.
>
>> This consistent delay in timely reviews is a bottleneck.
> As Greg pointed out even ones that were reviewed got rejected, so
> clearly the issue is with the quality and not the speed at which we send
> them on.
>
>> It would be good if the big first reviews could be done in parallel.
> Again depending how the patchsets are structured it will take me a while
> to process. Having them re-use existing infrastructure, following
> coding and submission guidelines will speed up the process.
>
> On a personal level, being told I'm too slow and not doing my job as
> maintainer doesn't exactly increase my motivation to get to it ...
Sorry about that.
I really do want to help out, earlier you mentioned patchwork problems.
If you can point me at the wreckage, I'll take a look.
Tom
>
> - Moritz
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/8] FPGA DFL Changes for 5.12
2021-01-11 22:39 ` Tom Rix
@ 2021-01-14 16:48 ` Moritz Fischer
0 siblings, 0 replies; 27+ messages in thread
From: Moritz Fischer @ 2021-01-14 16:48 UTC (permalink / raw)
To: Tom Rix
Cc: Moritz Fischer, Greg KH, linux-fpga, linux-kernel, moritzf,
Rikard Falkeborn, Zheng Yongjun, Russ Weight, Gerlach, Matthew,
Sonal Santan, Xu Yilun, Richard Gong
On Mon, Jan 11, 2021 at 02:39:36PM -0800, Tom Rix wrote:
>
> On 1/11/21 12:28 PM, Moritz Fischer wrote:
> > Tom,
> >
> > On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
> >
> > [..]
> >> I have been doing the first review in a couple of days after every patch landing.
> > I appreciate your help with doing reviews.
> >
> >> I see some pretty good response from the developers to fix the issues raised.ÂÂ
> > ... yet patches have been rejected. So it doesn't seem purely a matter
> > of throughput?
> >
> >> But I do not see Moritz picking up the review until weeks later.
> > I'll admit there are delays that happen, I have a dayjob as I pointed
> > out in earlier conversations. Furthermore, just because I do not
> > immediately send out an email does not mean I don't look at stuff.
> >
> > If people show up with 100kLOC patchsets that don't pass checkpatch,
> > it'll take a while for me to even read up and understand what they're
> > doing / trying to do.
> >
> >> This consistent delay in timely reviews is a bottleneck.
> > As Greg pointed out even ones that were reviewed got rejected, so
> > clearly the issue is with the quality and not the speed at which we send
> > them on.
> >
> >> It would be good if the big first reviews could be done in parallel.
> > Again depending how the patchsets are structured it will take me a while
> > to process. Having them re-use existing infrastructure, following
> > coding and submission guidelines will speed up the process.
> >
> > On a personal level, being told I'm too slow and not doing my job as
> > maintainer doesn't exactly increase my motivation to get to it ...
>
> Sorry about that.
>
> I really do want to help out, earlier you mentioned patchwork problems.
>
> If you can point me at the wreckage, I'll take a look.
I need to add you as reviewer there. Mostly needs triaging which of the
open patches are still relevant.
I think you could ping kernel.org helpdesk.
- Moritz
^ permalink raw reply [flat|nested] 27+ messages in thread