Re: [PATCH] MAINTAINERS: fpga: hand off maintainership to Moritz
On Tue, Jun 18, 2019 at 2:17 AM Greg Kroah-Hartman wrote: > > On Sun, Jun 16, 2019 at 10:11:13PM -0500, Alan Tull wrote: > > I'm moving on to a new position and stepping down as FPGA subsystem > > maintainer. Moritz has graciously agreed to take over the > > maintainership. > > > > Signed-off-by: Alan Tull > > Thanks for all the work you have done on this subsystem getting it into > mergable shape and then maintaining it for a while. > > good luck on your future endeavors, hopefully it still involves kernel > programming :) Thanks for all your guidance and help! Alan > > greg k-h
Re: [PATCH] MAINTAINERS: fpga: hand off maintainership to Moritz
On Sun, Jun 16, 2019 at 10:35 PM Moritz Fischer wrote: Hi Moritz, > > Hi Alan, > > On Sun, Jun 16, 2019 at 10:11:13PM -0500, Alan Tull wrote: > > I'm moving on to a new position and stepping down as FPGA subsystem > > maintainer. Moritz has graciously agreed to take over the > > maintainership. > > Thanks a lot for all the work you put into this, it was good fun working > with you, and I hope you'll be back someday, or at least you'll keep > working on the Linux Kernel in other areas. Thank you for your support and all the good work and enthusiasm you've put into this subsystem! Alan > > All: It'll take me a bit to get everything sorted, since I just switched > jobs and am still getting set up there, too, so please be patient :) > > > Signed-off-by: Alan Tull > Acked-by: Moritz Fischer > > --- > > MAINTAINERS | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 80e2bfa049d7..448730982545 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6266,7 +6266,6 @@ F: include/linux/ipmi-fru.h > > K: fmc_d.*register > > > > FPGA MANAGER FRAMEWORK > > -M: Alan Tull > > M: Moritz Fischer > > L: linux-f...@vger.kernel.org > > S: Maintained > > -- > > 2.21.0 > > > > Cheers, > Moritz
[PATCH] MAINTAINERS: fpga: hand off maintainership to Moritz
I'm moving on to a new position and stepping down as FPGA subsystem maintainer. Moritz has graciously agreed to take over the maintainership. Signed-off-by: Alan Tull --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 80e2bfa049d7..448730982545 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6266,7 +6266,6 @@ F:include/linux/ipmi-fru.h K: fmc_d.*register FPGA MANAGER FRAMEWORK -M: Alan Tull M: Moritz Fischer L: linux-f...@vger.kernel.org S: Maintained -- 2.21.0
Re: [PATCH v3 16/16] fpga: dfl: fme: add performance reporting support
On Mon, May 27, 2019 at 12:39 AM Wu Hao wrote: Hi Hao, Just one correction that I saw below, sorry I didn't catch it last time. > > This patch adds support for performance reporting private feature > for FPGA Management Engine (FME). Actually it supports 4 categories > performance counters, 'clock', 'cache', 'iommu' and 'fabric', user > could read the performance counter via exposed sysfs interfaces. > Please refer to sysfs doc for more details. > > Signed-off-by: Luwei Kang > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull > --- > v3: replace scnprintf with sprintf in sysfs interfaces. > update sysfs doc kernel version and date. > fix sysfs doc issue for fabric counter. > refine PERF_OBJ_ATTR_* macro, doesn't count on __ATTR anymore. > introduce PERF_OBJ_ATTR_F_* macro, as it needs to use different > filenames for some of the sysfs attributes. > remove kobject_del when destroy kobject, kobject_put is enough. > do sysfs_remove_groups first when destroying perf_obj. > WARN_ON_ONCE in case internal parms are wrong in read_*_count(). > --- > Documentation/ABI/testing/sysfs-platform-dfl-fme | 93 +++ > drivers/fpga/Makefile| 1 + > drivers/fpga/dfl-fme-main.c | 4 + > drivers/fpga/dfl-fme-perf.c | 962 > +++ > drivers/fpga/dfl-fme.h | 2 + > drivers/fpga/dfl.c | 1 + > drivers/fpga/dfl.h | 2 + > 7 files changed, 1065 insertions(+) > create mode 100644 drivers/fpga/dfl-fme-perf.c > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > index 5a8938f..63a02cb 100644 > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > @@ -119,3 +119,96 @@ Description: Write-only. Write error code to this > file to clear all errors > logged in errors, first_error and next_error. Write fails with > -EINVAL if input parsing fails or input error code doesn't > match. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/clock > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Only. Read for Accelerator Function Unit (AFU) clock > + counter. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/freeze > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Write. Read this file for the current status of 'cache' > + category performance counters, and Write '1' or '0' to freeze > + or unfreeze 'cache' performance counters. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/ > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Only. Read 'cache' category performance counters: > + read_hit, read_miss, write_hit, write_miss, hold_request, > + data_write_port_contention, tag_write_port_contention, > + tx_req_stall, rx_req_stall and rx_eviction. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/freeze > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Write. Read this file for the current status of 'iommu' > + category performance counters, and Write '1' or '0' to freeze > + or unfreeze 'iommu' performance counters. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/ > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Only. Read 'iommu' category 'sip' sub category > + performance counters: iotlb_4k_hit, iotlb_2m_hit, > + iotlb_1g_hit, slpwc_l3_hit, slpwc_l4_hit, rcc_hit, > + rcc_miss, iotlb_4k_miss, iotlb_2m_miss, iotlb_1g_miss, > + slpwc_l3_miss and slpwc_l4_miss. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/afu0/ > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Read-Only. Read 'iommu' category 'afuX' sub category > + performance counters: read_transaction, write_transaction, > + devtlb_read_hit, devtlb_write_hit, devtlb_4k_fill, > + devtlb_2m_fill and devtlb_1g_fill. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/freeze > +Date: May 2019 > +KernelVersion: 5.3 > +Contact: Wu Hao > +Description: Rea
[PATCH 0/1] one fix for FPGA
Hi Greg, Please take this FPGA fix. It have been reviewed on the mailing list and applies cleanly on current linux-next and char-misc-testing. Thanks, Alan Moritz Fischer (1): fpga: zynqmp-fpga: Correctly handle error pointer drivers/fpga/zynqmp-fpga.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.21.0
[PATCH 1/1] fpga: zynqmp-fpga: Correctly handle error pointer
From: Moritz Fischer
Fixes the following static checker errors:
drivers/fpga/zynqmp-fpga.c:50 zynqmp_fpga_ops_write()
error: 'eemi_ops' dereferencing possible ERR_PTR()
drivers/fpga/zynqmp-fpga.c:84 zynqmp_fpga_ops_state()
error: 'eemi_ops' dereferencing possible ERR_PTR()
Note: This does not handle the EPROBE_DEFER value in a
special manner.
Fixes commit c09f7471127e ("fpga manager: Adding FPGA Manager support for
Xilinx zynqmp")
Reported-by: Dan Carpenter
Signed-off-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/zynqmp-fpga.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
index f7cbaadf49ab..b8a88d21d038 100644
--- a/drivers/fpga/zynqmp-fpga.c
+++ b/drivers/fpga/zynqmp-fpga.c
@@ -47,7 +47,7 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
char *kbuf;
int ret;
- if (!eemi_ops || !eemi_ops->fpga_load)
+ if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_load)
return -ENXIO;
priv = mgr->priv;
@@ -81,7 +81,7 @@ static enum fpga_mgr_states zynqmp_fpga_ops_state(struct
fpga_manager *mgr)
const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
u32 status;
- if (!eemi_ops || !eemi_ops->fpga_get_status)
+ if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_get_status)
return FPGA_MGR_STATE_UNKNOWN;
eemi_ops->fpga_get_status();
--
2.21.0
Re: [PATCH v2 05/18] Documentation: fpga: dfl: add descriptions for virtualization and new interfaces.
On Thu, May 16, 2019 at 11:27 PM Wu Hao wrote: > > On Thu, May 16, 2019 at 12:53:00PM -0500, Alan Tull wrote: > > On Thu, May 16, 2019 at 12:36 PM Alan Tull wrote: > > > > > > On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote: > > > > Hi Hao, > > > > Most of this patchset looks ready to go upstream or nearly so with > > pretty straightforward changes . Patches 17 and 18 need minor changes > > and please change the scnprintf in the other patches. The patches > > that had nontrivial changes are the power and thermal ones involving > > hwmon. I'm hoping to send up the patchset minus the hwmon patches in > > the next version if there's no unforseen issues. If the hwmon patches > > are ready then also, that's great, but otherwise those patches don't > > need to hold up all the rest of the patchset. How's that sound? > > Hi Alan > > Thanks for your time for reviewing this patchset. > > This sounds good to me. Only thing here is, I need to split the patch which > updates documentation into 2 patches (to remove hwmon description in doc), > but for sure, it should be very easy. :) Yes that sounds good. Thanks, Alan > > Thanks > Hao > > > > > Alan > > > > > > > > > > This patch adds virtualization support description for DFL based > > > > FPGA devices (based on PCIe SRIOV), and introductions to new > > > > interfaces added by new dfl private feature drivers. > > > > > > > > Signed-off-by: Xu Yilun > > > > Signed-off-by: Wu Hao > > > > > > Acked-by: Alan Tull > > > > > > Thanks, > > > Alan
Re: [PATCH v2 05/18] Documentation: fpga: dfl: add descriptions for virtualization and new interfaces.
On Thu, May 16, 2019 at 12:36 PM Alan Tull wrote: > > On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote: Hi Hao, Most of this patchset looks ready to go upstream or nearly so with pretty straightforward changes . Patches 17 and 18 need minor changes and please change the scnprintf in the other patches. The patches that had nontrivial changes are the power and thermal ones involving hwmon. I'm hoping to send up the patchset minus the hwmon patches in the next version if there's no unforseen issues. If the hwmon patches are ready then also, that's great, but otherwise those patches don't need to hold up all the rest of the patchset. How's that sound? Alan > > > > This patch adds virtualization support description for DFL based > > FPGA devices (based on PCIe SRIOV), and introductions to new > > interfaces added by new dfl private feature drivers. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > Acked-by: Alan Tull > > Thanks, > Alan
Re: [PATCH v2 05/18] Documentation: fpga: dfl: add descriptions for virtualization and new interfaces.
On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote: > > This patch adds virtualization support description for DFL based > FPGA devices (based on PCIe SRIOV), and introductions to new > interfaces added by new dfl private feature drivers. > > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull Thanks, Alan
Re: [PATCH v2 04/18] fpga: dfl: fme: support 512bit data width PR
On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote:
It looks like this addressed the review comments. Adding my Ack. Is
there anything else on this patch?
Alan
>
> In early partial reconfiguration private feature, it only
> supports 32bit data width when writing data to hardware for
> PR. 512bit data width PR support is an important optimization
> for some specific solutions (e.g. XEON with FPGA integrated),
> it allows driver to use AVX512 instruction to improve the
> performance of partial reconfiguration. e.g. programming one
> 100MB bitstream image via this 512bit data width PR hardware
> only takes ~300ms, but 32bit revision requires ~3s per test
> result.
>
> Please note now this optimization is only done on revision 2
> of this PR private feature which is only used in integrated
> solution that AVX512 is always supported. This revision 2
> hardware doesn't support 32bit PR.
>
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
> ---
> v2: check AVX512 support using cpu_feature_enabled()
> fix other comments from Scott Wood
> ---
> drivers/fpga/dfl-fme-main.c | 3 ++
> drivers/fpga/dfl-fme-mgr.c | 113
> +---
> drivers/fpga/dfl-fme-pr.c | 43 +++--
> drivers/fpga/dfl-fme.h | 2 +
> drivers/fpga/dfl.h | 5 ++
> 5 files changed, 135 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 086ad24..076d74f 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -21,6 +21,8 @@
> #include "dfl.h"
> #include "dfl-fme.h"
>
> +#define DRV_VERSION"0.8"
> +
> static ssize_t ports_num_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> @@ -277,3 +279,4 @@ static int fme_remove(struct platform_device *pdev)
> MODULE_AUTHOR("Intel Corporation");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("platform:dfl-fme");
> +MODULE_VERSION(DRV_VERSION);
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index b3f7eee..d1a4ba5 100644
> --- a/drivers/fpga/dfl-fme-mgr.c
> +++ b/drivers/fpga/dfl-fme-mgr.c
> @@ -22,14 +22,18 @@
> #include
> #include
>
> +#include "dfl.h"
> #include "dfl-fme-pr.h"
>
> +#define DRV_VERSION"0.8"
> +
> /* FME Partial Reconfiguration Sub Feature Register Set */
> #define FME_PR_DFH 0x0
> #define FME_PR_CTRL0x8
> #define FME_PR_STS 0x10
> #define FME_PR_DATA0x18
> #define FME_PR_ERR 0x20
> +#define FME_PR_512_DATA0x40 /* Data Register for 512bit
> datawidth PR */
> #define FME_PR_INTFC_ID_L 0xA8
> #define FME_PR_INTFC_ID_H 0xB0
>
> @@ -67,8 +71,43 @@
> #define PR_WAIT_TIMEOUT 800
> #define PR_HOST_STATUS_IDLE0
>
> +#if defined(CONFIG_X86) && defined(CONFIG_AS_AVX512)
> +
> +#include
> +#include
> +
> +static inline int is_cpu_avx512_enabled(void)
> +{
> + return cpu_feature_enabled(X86_FEATURE_AVX512F);
> +}
> +
> +static inline void copy512(const void *src, void __iomem *dst)
> +{
> + kernel_fpu_begin();
> +
> + asm volatile("vmovdqu64 (%0), %%zmm0;"
> +"vmovntdq %%zmm0, (%1);"
> +:
> +: "r"(src), "r"(dst)
> +: "memory");
> +
> + kernel_fpu_end();
> +}
> +#else
> +static inline int is_cpu_avx512_enabled(void)
> +{
> + return 0;
> +}
> +
> +static inline void copy512(const void *src, void __iomem *dst)
> +{
> + WARN_ON_ONCE(1);
> +}
> +#endif
> +
> struct fme_mgr_priv {
> void __iomem *ioaddr;
> + unsigned int pr_datawidth;
> u64 pr_error;
> };
>
> @@ -169,7 +208,7 @@ static int fme_mgr_write(struct fpga_manager *mgr,
> struct fme_mgr_priv *priv = mgr->priv;
> void __iomem *fme_pr = priv->ioaddr;
> u64 pr_ctrl, pr_status, pr_data;
> - int delay = 0, pr_credit, i = 0;
> + int ret = 0, delay = 0, pr_credit;
>
> dev_dbg(dev, "start request\n");
>
> @@ -181,9 +220,9 @@ static int fme_mgr_write(struct fpga_manager *mgr,
>
> /*
> * driver can push data to PR hardware using PR_DATA register once HW
> -* has enough pr_credit (> 1), pr_credit reduces one for every 32bit
> -* pr data write to PR_DATA register. If pr_
Re: [PATCH v2 18/18] fpga: dfl: fme: add performance reporting support
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote: Hi Hao, > > This patch adds support for performance reporting private feature > for FPGA Management Engine (FME). Actually it supports 4 categories > performance counters, 'clock', 'cache', 'iommu' and 'fabric', user > could read the performance counter via exposed sysfs interfaces. > Please refer to sysfs doc for more details. > > Signed-off-by: Luwei Kang > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > v2: improve sysfs doc > --- > Documentation/ABI/testing/sysfs-platform-dfl-fme | 93 +++ > drivers/fpga/Makefile| 1 + > drivers/fpga/dfl-fme-main.c | 4 + > drivers/fpga/dfl-fme-perf.c | 950 > +++ > drivers/fpga/dfl-fme.h | 2 + > drivers/fpga/dfl.c | 1 + > drivers/fpga/dfl.h | 2 + > 7 files changed, 1053 insertions(+) > create mode 100644 drivers/fpga/dfl-fme-perf.c > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > index 503984b..a7f7eb6 100644 > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > @@ -250,3 +250,96 @@ Description: Write-only. Write error code to this > file to clear all errors > logged in errors, first_error and next_error. Write fails with > -EINVAL if input parsing fails or input error code doesn't > match. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/clock > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read for Accelerator Function Unit (AFU) clock > + counter. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/freeze > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file for the current status of 'cache' > + category performance counters, and Write '1' or '0' to freeze > + or unfreeze 'cache' performance counters. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/cache/ > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read 'cache' category performance counters: > + read_hit, read_miss, write_hit, write_miss, hold_request, > + data_write_port_contention, tag_write_port_contention, > + tx_req_stall, rx_req_stall and rx_eviction. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/freeze > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file for the current status of 'iommu' > + category performance counters, and Write '1' or '0' to freeze > + or unfreeze 'iommu' performance counters. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/ > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read 'iommu' category 'sip' sub category > + performance counters: iotlb_4k_hit, iotlb_2m_hit, > + iotlb_1g_hit, slpwc_l3_hit, slpwc_l4_hit, rcc_hit, > + rcc_miss, iotlb_4k_miss, iotlb_2m_miss, iotlb_1g_miss, > + slpwc_l3_miss and slpwc_l4_miss. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/iommu/afu0/ > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read 'iommu' category 'afuX' sub category > + performance counters: read_transaction, write_transaction, > + devtlb_read_hit, devtlb_write_hit, devtlb_4k_fill, > + devtlb_2m_fill and devtlb_1g_fill. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/freeze > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file for the current status of 'fabric' > + category performance counters, and Write '1' or '0' to freeze > + or unfreeze 'fabric' performance counters. > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/ > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read 'fabric' category performance counters: > + pcie0_read, pcie0_write, pcie1_read, pcie1_write, > + upi_read, upi_write and mmio_read. Also mmio_write > + > +What: /sys/bus/platform/devices/dfl-fme.0/perf/fabric/enable > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file for current status of device level > + fabric counters. Write "1" to enable device level fabric > + counters.
[PATCH 2/4] fpga: dfl: afu: Pass the correct device to dma_mapping_error()
From: Scott Wood
dma_mapping_error() was being called on a different device struct than
what was passed to map/unmap. Besides rendering the error checking
ineffective, it caused a debug splat with CONFIG_DMA_API_DEBUG.
Signed-off-by: Scott Wood
Acked-by: Wu Hao
Acked-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/dfl-afu-dma-region.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl-afu-dma-region.c
b/drivers/fpga/dfl-afu-dma-region.c
index 0bbc7142f1dc..f7d268f45df0 100644
--- a/drivers/fpga/dfl-afu-dma-region.c
+++ b/drivers/fpga/dfl-afu-dma-region.c
@@ -391,7 +391,7 @@ int afu_dma_map_region(struct dfl_feature_platform_data
*pdata,
region->pages[0], 0,
region->length,
DMA_BIDIRECTIONAL);
- if (dma_mapping_error(>dev->dev, region->iova)) {
+ if (dma_mapping_error(dfl_fpga_pdata_to_parent(pdata), region->iova)) {
dev_err(>dev->dev, "failed to map for dma\n");
ret = -EFAULT;
goto unpin_pages;
--
2.21.0
[PATCH 1/4] fpga: stratix10-soc: fix use-after-free on s10_init()
From: Wen Yang
The refcount of fw_np has already been decreased by of_find_matching_node()
so it shouldn't be used anymore.
This patch adds an of_node_get() before of_find_matching_node() to avoid
the use-after-free problem.
Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
Signed-off-by: Wen Yang
Cc: Alan Tull
Cc: Moritz Fischer
Cc: Nicolas Saenz Julienne
Cc: linux-f...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Moritz Fischer
Reviewed-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
---
drivers/fpga/stratix10-soc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
index 13851b3d1c56..215d33789c74 100644
--- a/drivers/fpga/stratix10-soc.c
+++ b/drivers/fpga/stratix10-soc.c
@@ -507,12 +507,16 @@ static int __init s10_init(void)
if (!fw_np)
return -ENODEV;
+ of_node_get(fw_np);
np = of_find_matching_node(fw_np, s10_of_match);
- if (!np)
+ if (!np) {
+ of_node_put(fw_np);
return -ENODEV;
+ }
of_node_put(np);
ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
+ of_node_put(fw_np);
if (ret)
return ret;
--
2.21.0
[PATCH 0/4] patches for FPGA
Hi Greg, Please take these four fpga fixes patches. They have been reviewed on the mailing list and apply cleanly on current linux-next and char-misc-testing. Thanks, Alan Chengguang Xu (1): fpga: dfl: expand minor range when registering chrdev region Scott Wood (2): fpga: dfl: afu: Pass the correct device to dma_mapping_error() fpga: dfl: Add lockdep classes for pdata->lock Wen Yang (1): fpga: stratix10-soc: fix use-after-free on s10_init() drivers/fpga/dfl-afu-dma-region.c | 2 +- drivers/fpga/dfl.c| 22 ++ drivers/fpga/stratix10-soc.c | 6 +- 3 files changed, 24 insertions(+), 6 deletions(-) -- 2.21.0
[PATCH 4/4] fpga: dfl: expand minor range when registering chrdev region
From: Chengguang Xu
Actually, total amount of available minor number
for a single major is MINORMASK + 1. So expand
minor range when registering chrdev region.
Signed-off-by: Chengguang Xu
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index c25217cde5ca..4b66aaa32b5a 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -322,7 +322,7 @@ static void dfl_chardev_uinit(void)
for (i = 0; i < DFL_FPGA_DEVT_MAX; i++)
if (MAJOR(dfl_chrdevs[i].devt)) {
unregister_chrdev_region(dfl_chrdevs[i].devt,
-MINORMASK);
+MINORMASK + 1);
dfl_chrdevs[i].devt = MKDEV(0, 0);
}
}
@@ -332,8 +332,8 @@ static int dfl_chardev_init(void)
int i, ret;
for (i = 0; i < DFL_FPGA_DEVT_MAX; i++) {
- ret = alloc_chrdev_region(_chrdevs[i].devt, 0, MINORMASK,
- dfl_chrdevs[i].name);
+ ret = alloc_chrdev_region(_chrdevs[i].devt, 0,
+ MINORMASK + 1, dfl_chrdevs[i].name);
if (ret)
goto exit;
}
--
2.21.0
[PATCH 3/4] fpga: dfl: Add lockdep classes for pdata->lock
From: Scott Wood
struct dfl_feature_platform_data (and it's mutex) is used
by both fme and port devices, and when lockdep is enabled it
complains about nesting between these locks. Tell lockdep about
the difference so it can track each class separately.
Here's the lockdep complaint:
[ 409.680668] WARNING: possible recursive locking detected
[ 409.685983] 5.1.0-rc3.fpga+ #1 Tainted: GE
[ 409.691469]
[ 409.696779] fpgaconf/9348 is trying to acquire lock:
[ 409.701746] a443fe2e (>lock){+.+.}, at:
port_enable_set+0x24/0x60 [dfl_afu]
[ 409.710006]
[ 409.710006] but task is already holding lock:
[ 409.715837] 63b78782 (>lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.724012]
[ 409.724012] other info that might help us debug this:
[ 409.730535] Possible unsafe locking scenario:
[ 409.730535]
[ 409.736457]CPU0
[ 409.738910]
[ 409.741360] lock(>lock);
[ 409.744679] lock(>lock);
[ 409.747999]
[ 409.747999] *** DEADLOCK ***
[ 409.747999]
[ 409.753920] May be due to missing lock nesting notation
[ 409.753920]
[ 409.760704] 4 locks held by fpgaconf/9348:
[ 409.764805] #0: 63b78782 (>lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.773408] #1: 213c8a66 (>mutex){+.+.}, at:
fpga_region_program_fpga+0x24/0x200 [fpga_region]
[ 409.783489] #2: fe63afb9 (>ref_mutex){+.+.}, at:
fpga_mgr_lock+0x15/0x40 [fpga_mgr]
[ 409.792354] #3: 0b2285c5 (>mutex){+.+.}, at:
__fpga_bridge_get+0x26/0xa0 [fpga_bridge]
[ 409.801740]
[ 409.801740] stack backtrace:
[ 409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G
E 5.1.0-rc3.fpga+ #1
[ 409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS
SE5C620.86B.01.00.0763.022420181017 02/24/2018
[ 409.825911] Call Trace:
[ 409.828369] dump_stack+0x5e/0x8b
[ 409.831686] __lock_acquire+0xf3d/0x10e0
[ 409.835612] ? find_held_lock+0x3c/0xa0
[ 409.839451] lock_acquire+0xbc/0x1d0
[ 409.843030] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.847823] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.852616] __mutex_lock+0x86/0x970
[ 409.856195] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.860989] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.865777] ? __mutex_unlock_slowpath+0x4b/0x290
[ 409.870486] port_enable_set+0x24/0x60 [dfl_afu]
[ 409.875106] fpga_bridges_disable+0x36/0x50 [fpga_bridge]
[ 409.880502] fpga_region_program_fpga+0xea/0x200 [fpga_region]
[ 409.886338] fme_pr_ioctl+0x13e/0x330 [dfl_fme]
[ 409.890870] fme_ioctl+0x66/0xe0 [dfl_fme]
[ 409.894973] do_vfs_ioctl+0xa9/0x720
[ 409.898548] ? lockdep_hardirqs_on+0xf0/0x1a0
[ 409.902907] ksys_ioctl+0x60/0x90
[ 409.906225] __x64_sys_ioctl+0x16/0x20
[ 409.909981] do_syscall_64+0x5a/0x220
[ 409.913644] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 409.918698] RIP: 0033:0x7f9d31b9b8d7
[ 409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
[ 409.941020] RSP: 002b:7ffe4cae0d68 EFLAGS: 0202 ORIG_RAX:
0010
[ 409.948588] RAX: ffda RBX: 7f9d32ade6a0 RCX: 7f9d31b9b8d7
[ 409.955719] RDX: 7ffe4cae0df0 RSI: b680 RDI: 0003
[ 409.962852] RBP: 0003 R08: 7f9d2b70a177 R09: 7ffe4cae0e40
[ 409.969984] R10: 7ffe4cae0160 R11: 0202 R12: 7ffe4cae0df0
[ 409.977115] R13: b680 R14: R15: 7ffe4cae0f60
Signed-off-by: Scott Wood
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 2c09e502e721..c25217cde5ca 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -40,6 +40,13 @@ enum dfl_fpga_devt_type {
DFL_FPGA_DEVT_MAX,
};
+static struct lock_class_key dfl_pdata_keys[DFL_ID_MAX];
+
+static const char *dfl_pdata_key_strings[DFL_ID_MAX] = {
+ "dfl-fme-pdata",
+ "dfl-port-pdata",
+};
+
/**
* dfl_dev_info - dfl feature device information.
* @name: name string of the feature platform device.
@@ -443,11 +450,16 @@ static int build_info_commit_dev(struct
build_feature_devs_info *binfo)
struct platform_device *fdev = binfo->feature_dev;
struct dfl_feature_platform_data *pdata;
struct dfl_feature_info *finfo, *p;
+ enum dfl_id_type type;
int ret, index = 0;
if (!fdev)
return 0;
+ type = feature_dev_id_type(fdev);
+ if (WARN_ON_ONCE(type >= DFL_ID_MAX))
+ return -EINVAL;
+
/*
* we do not need to care for the memory which is associated with
* the platform device. After calling plat
Re: [PATCH v2 17/18] fpga: dfl: fme: add global error reporting support
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote:
Hi Hao,
The changes look good. There's one easy to fix thing that Greg has
pointed out recently on another patch (below).
>
> This patch adds support for global error reporting for FPGA
> Management Engine (FME), it introduces sysfs interfaces to
> report different error detected by the hardware, and allow
> user to clear errors or inject error for testing purpose.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
> ---
> v2: fix issues found in sysfs doc.
> fix returned error code issues for writable sysfs interfaces.
> (use -EINVAL if input doesn't match error code)
> reorder the sysfs groups in code.
> +static ssize_t revision_show(struct device *dev, struct device_attribute
> *attr,
> +char *buf)
> +{
> + struct device *err_dev = dev->parent;
> + void __iomem *base;
> +
> + base = dfl_get_feature_ioaddr_by_id(err_dev,
> FME_FEATURE_ID_GLOBAL_ERR);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n", dfl_feature_revision(base));
Greg is discouraging use of scnprintf for sysfs attributes where it's
not needed [1].
Please fix this up the attributes added in this patchset. Besides
that, looks good, I added my Ack.
Alan
> +}
> +static DEVICE_ATTR_RO(revision);
[1] https://lkml.org/lkml/2019/4/25/1050
Re: [PATCH v2 12/18] fpga: dfl: afu: add error reporting support.
On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote: > > Error reporting is one important private feature, it reports error > detected on port and accelerated function unit (AFU). It introduces > several sysfs interfaces to allow userspace to check and clear > errors detected by hardware. > > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull Thanks! Alan > --- > v2: add more error code description for error clear sysfs in doc. > return -EINVAL instead of -EBUSY when input error code doesn't > match in error clear sysfs. > --- > Documentation/ABI/testing/sysfs-platform-dfl-port | 39 > drivers/fpga/Makefile | 1 + > drivers/fpga/dfl-afu-error.c | 225 > ++ > drivers/fpga/dfl-afu-main.c | 4 + > drivers/fpga/dfl-afu.h| 4 + > 5 files changed, 273 insertions(+) > create mode 100644 drivers/fpga/dfl-afu-error.c
Re: [PATCH v2 02/18] fpga: dfl: fme: remove copy_to_user() in ioctl for PR
On Tue, May 7, 2019 at 12:26 PM Moritz Fischer wrote: > > On Mon, Apr 29, 2019 at 04:55:35PM +0800, Wu Hao wrote: > > This patch removes copy_to_user() code in partial reconfiguration > > ioctl, as it's useless as user never needs to read the data > > structure after ioctl. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > Acked-by: Moritz Fischer Acked-by: Alan Tull Alan > > --- > > v2: clean up code split from patch 2 in v1 patchset. > > --- > > drivers/fpga/dfl-fme-pr.c | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl-fme-pr.c > > index d9ca955..6ec0f09 100644 > > --- a/drivers/fpga/dfl-fme-pr.c > > +++ b/drivers/fpga/dfl-fme-pr.c > > @@ -159,9 +159,6 @@ static int fme_pr(struct platform_device *pdev, > > unsigned long arg) > > mutex_unlock(>lock); > > free_exit: > > vfree(buf); > > - if (copy_to_user((void __user *)arg, _pr, minsz)) > > - return -EFAULT; > > - > > return ret; > > } > > > > -- > > 1.8.3.1 > >
Re: [PATCH v2] fpga: zynqmp-fpga: Correctly handle error pointer
On Tue, May 7, 2019 at 2:43 PM Moritz Fischer wrote:
>
> Fixes the following static checker errors:
>
> drivers/fpga/zynqmp-fpga.c:50 zynqmp_fpga_ops_write()
> error: 'eemi_ops' dereferencing possible ERR_PTR()
>
> drivers/fpga/zynqmp-fpga.c:84 zynqmp_fpga_ops_state()
> error: 'eemi_ops' dereferencing possible ERR_PTR()
>
> Note: This does not handle the EPROBE_DEFER value in a
> special manner.
>
> Fixes commit c09f7471127e ("fpga manager: Adding FPGA Manager support for
> Xilinx zynqmp")
> Reported-by: Dan Carpenter
> Signed-off-by: Moritz Fischer
Acked-by: Alan Tull
Thanks!
Alan
> ---
>
> Changes from v1:
> - Address Alan's feedback regarding handling both occurences.
>
> ---
> drivers/fpga/zynqmp-fpga.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
> index f7cbaadf49ab..b8a88d21d038 100644
> --- a/drivers/fpga/zynqmp-fpga.c
> +++ b/drivers/fpga/zynqmp-fpga.c
> @@ -47,7 +47,7 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
> char *kbuf;
> int ret;
>
> - if (!eemi_ops || !eemi_ops->fpga_load)
> + if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_load)
> return -ENXIO;
>
> priv = mgr->priv;
> @@ -81,7 +81,7 @@ static enum fpga_mgr_states zynqmp_fpga_ops_state(struct
> fpga_manager *mgr)
> const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
> u32 status;
>
> - if (!eemi_ops || !eemi_ops->fpga_get_status)
> + if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_get_status)
> return FPGA_MGR_STATE_UNKNOWN;
>
> eemi_ops->fpga_get_status();
> --
> 2.21.0
>
Re: [PATCH] fpga: zynqmp-fpga: Correctly handle error pointer
On Tue, May 7, 2019 at 12:03 PM Moritz Fischer wrote:
Hi Moritz,
>
> Fixes the following static checker error:
>
> drivers/fpga/zynqmp-fpga.c:50 zynqmp_fpga_ops_write()
> error: 'eemi_ops' dereferencing possible ERR_PTR()
>
> Note: This does not handle the EPROBE_DEFER value in a
> special manner.
>
> Fixes commit c09f7471127e ("fpga manager: Adding FPGA Manager support for
> Xilinx zynqmp")
> Reported-by: Dan Carpenter
> Signed-off-by: Moritz Fischer
> ---
> drivers/fpga/zynqmp-fpga.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
> index f7cbaadf49ab..abcb0b2e75bf 100644
> --- a/drivers/fpga/zynqmp-fpga.c
> +++ b/drivers/fpga/zynqmp-fpga.c
> @@ -47,7 +47,7 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
> char *kbuf;
> int ret;
>
> - if (!eemi_ops || !eemi_ops->fpga_load)
> + if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_load)
This if statement also happens in fpga_mgr_states
zynqmp_fpga_ops_state(), so we'll need this fix there also.
> return -ENXIO;
>
> priv = mgr->priv;
> --
> 2.21.0
>
Alan
Re: [PATCH v2 15/18] fpga: dfl: fme: add thermal management support
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote: + The hwmon people > > This patch adds support to thermal management private feature for DFL > FPGA Management Engine (FME). This private feature driver registers > a hwmon for thermal/temperature monitoring (hwmon temp1_input). > If hardware automatic throttling is supported by this hardware, then > driver also exposes sysfs interfaces under hwmon for thresholds > (temp1_alarm/ crit/ emergency), threshold status (temp1_alarm_status/ > temp1_crit_status) and throttling policy (temp1_alarm_policy). > > Signed-off-by: Luwei Kang > Signed-off-by: Russ Weight > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > v2: create a dfl_fme_thermal hwmon to expose thermal information. > move all sysfs interfaces under hwmon > tempareture --> hwmon temp1_input > threshold1--> hwmon temp1_alarm > threshold2--> hwmon temp1_crit > trip_threshold--> hwmon temp1_emergency > threshold1_status --> hwmon temp1_alarm_status > threshold2_status --> hwmon temp1_crit_status > threshold1_policy --> hwmon temp1_alarm_policy > --- > Documentation/ABI/testing/sysfs-platform-dfl-fme | 64 +++ > drivers/fpga/Kconfig | 2 +- > drivers/fpga/dfl-fme-main.c | 212 > +++ > 3 files changed, 277 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > index d1aa375..dfbd315 100644 > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > @@ -44,3 +44,67 @@ Description: Read-only. It returns socket_id to indicate > which socket > this FPGA belongs to, only valid for integrated solution. > User only needs this information, in case standard numa node > can't provide correct information. > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/name > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read this file to get the name of hwmon device, it > + supports values: > + 'dfl_fme_thermal' - thermal hwmon device name > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns FPGA device temperature in millidegrees > + Celsius. > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_alarm > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns hardware threshold1 temperature in > + millidegrees Celsius. If temperature rises at or above this > + threshold, hardware starts 50% or 90% throttling (see > + 'temp1_alarm_policy'). > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns hardware threshold2 temperature in > + millidegrees Celsius. If temperature rises at or above this > + threshold, hardware starts 100% throttling. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_emergency > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns hardware trip threshold temperature in > + millidegrees Celsius. If temperature rises at or above this > + threshold, a fatal event will be triggered to board management > + controller (BMC) to shutdown FPGA. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_alarm_status > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns 1 if temperature is currently at or > above > + hardware threshold1 (see 'temp1_alarm'), otherwise 0. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit_status > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns 1 if temperature is currently at or > above > + hardware threshold2 (see 'temp1_crit'), otherwise 0. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_alarm_policy > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. Read this file to get the policy of hardware > threshold1 > + (see 'temp1_alarm'). It only supports two values (policies): > + 0 - AP2 state (90% throttling) > + 1 - AP1 state (50% throttling) > diff --git a/drivers/fpga/Kconfig
Re: [PATCH v2 16/18] fpga: dfl: fme: add power management support
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote: + hwmon folks > > This patch adds support for power management private feature under > FPGA Management Engine (FME). This private feature driver registers > a hwmon for power (power1_input), thresholds information, e.g. > (power1_cap / crit) and also read-only sysfs interfaces for other > power management information. For configuration, user could write > threshold values via above power1_cap / crit sysfs interface > under hwmon too. > > Signed-off-by: Luwei Kang > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > v2: create a dfl_fme_power hwmon to expose power sysfs interfaces. > move all sysfs interfaces under hwmon > consumed --> hwmon power1_input > threshold1--> hwmon power1_cap > threshold2--> hwmon power1_crit > threshold1_status --> hwmon power1_cap_status > threshold2_status --> hwmon power1_crit_status > xeon_limit--> hwmon power1_xeon_limit > fpga_limit--> hwmon power1_fpga_limit > ltr --> hwmon power1_ltr > --- > Documentation/ABI/testing/sysfs-platform-dfl-fme | 67 ++ > drivers/fpga/dfl-fme-main.c | 247 > +++ > 2 files changed, 314 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > index dfbd315..e2ba92d 100644 > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > @@ -52,6 +52,7 @@ Contact: Wu Hao > Description: Read-Only. Read this file to get the name of hwmon device, it > supports values: > 'dfl_fme_thermal' - thermal hwmon device name > + 'dfl_fme_power' - power hwmon device name > > What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input > Date: April 2019 > @@ -108,3 +109,69 @@ Description: Read-Only. Read this file to get the > policy of hardware threshold1 > (see 'temp1_alarm'). It only supports two values (policies): > 0 - AP2 state (90% throttling) > 1 - AP1 state (50% throttling) > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns current FPGA power consumption in uW. > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_cap > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file to get current hardware power > + threshold1 in uW. If power consumption rises at or above > + this threshold, hardware starts 50% throttling. > + Write this file to set current hardware power threshold1 in > uW. > + As hardware only accepts values in Watts, so input value will > + be round down per Watts (< 1 watts part will be discarded). > + Write fails with -EINVAL if input parsing fails or input isn't > + in the valid range (0 - 12700 uW). > + > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Read this file to get current hardware power > + threshold2 in uW. If power consumption rises at or above > + this threshold, hardware starts 90% throttling. > + Write this file to set current hardware power threshold2 in > uW. > + As hardware only accepts values in Watts, so input value will > + be round down per Watts (< 1 watts part will be discarded). > + Write fails with -EINVAL if input parsing fails or input isn't > + in the valid range (0 - 12700 uW). > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_cap_status > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns 1 if power consumption is currently at > or > + above hardware threshold1 (see 'power1_cap'), otherwise 0. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_status > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns 1 if power consumption is currently at > or > + above hardware threshold2 (see 'power1_crit'), otherwise 0. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit > +Date: April 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Only. It returns power limit for XEON in uW. > + > +What: >
[PATCH 1/2] ARM: dts: socfpga: add ltc2497 on arria10 devkit
Add the two ltc2497 devices that are on the SoCFPGA Arria10
Socdk board at addresses 0x14 and 0x16.
Signed-off-by: Alan Tull
---
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
index 360dae5a5b12..0efbeccc5cd2 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
@@ -48,6 +48,13 @@
};
};
+ ref_033v: 033-v-ref {
+ compatible = "regulator-fixed";
+ regulator-name = "0.33V";
+ regulator-min-microvolt = <33>;
+ regulator-max-microvolt = <33>;
+ };
+
soc {
clkmgr@ffd04000 {
clocks {
@@ -128,6 +135,18 @@
i2c-sda-falling-time-ns = <6000>;
i2c-scl-falling-time-ns = <6000>;
+ adc@14 {
+ compatible = "lltc,ltc2497";
+ reg = <0x14>;
+ vref-supply = <_033v>;
+ };
+
+ adc@16 {
+ compatible = "lltc,ltc2497";
+ reg = <0x16>;
+ vref-supply = <_033v>;
+ };
+
eeprom@51 {
compatible = "atmel,24c32";
reg = <0x51>;
--
2.21.0
[PATCH 2/2] ARM: socfpga_defconfig: enable LTC2497
Enable the LTC2497 driver to support the two LTC2497's that are on the SoCFPGA Arria10 Devkit. Signed-off-by: Alan Tull --- arch/arm/configs/socfpga_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 08d1b3e11d68..cfc447161c09 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -127,6 +127,8 @@ CONFIG_RTC_DRV_DS1307=y CONFIG_DMADEVICES=y CONFIG_PL330_DMA=y CONFIG_DMATEST=m +CONFIG_IIO=y +CONFIG_LTC2497=y CONFIG_FPGA=y CONFIG_FPGA_MGR_SOCFPGA=y CONFIG_FPGA_MGR_SOCFPGA_A10=y -- 2.21.0
Re: [PATCH 15/17] fpga: dfl: fme: add power management support
On Thu, Apr 11, 2019 at 10:06 PM Wu Hao wrote: > > On Thu, Apr 11, 2019 at 03:07:35PM -0500, Alan Tull wrote: > > On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: > > > > Hi Hao, > > > > > > > > This patch adds support for power management private feature under > > > FPGA Management Engine (FME), sysfs interfaces are introduced for > > > different power management functions, users could use these sysfs > > > interface to get current number of consumed power, throttling > > > > How about > > s/number/measurement/ > > ? > > Sounds better. : ) > > > > > > thresholds, threshold status and other information, and configure > > > different value for throttling thresholds too. > > > > > > Signed-off-by: Luwei Kang > > > Signed-off-by: Xu Yilun > > > Signed-off-by: Wu Hao > > > --- > > > Documentation/ABI/testing/sysfs-platform-dfl-fme | 56 + > > > drivers/fpga/dfl-fme-main.c | 257 > > > +++ > > > 2 files changed, 313 insertions(+) > > > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > > index d3aeb88..4b6448f 100644 > > > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > > @@ -100,3 +100,59 @@ Description: Read-only. Read this file to get > > > the policy of temperature > > > threshold1. It only supports two value (policy): > > > 0 - AP2 state (90% throttling) > > > 1 - AP1 state (50% throttling) > > > + > > > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/consumed > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-only. It returns current power consumed by FPGA. > > > > What are the units? > > > > > + > > > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1 > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-Write. Read/Write this file to get/set current power > > > + threshold1 in Watts. > > > > Perhaps document error codes here and for threshold2 below. > > > > > + > > > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2 > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-Write. Read/Write this file to get/set current power > > > + threshold2 in Watts. > > > + > > > +What: > > > /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1_status > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-only. It returns 1 if power consumption reaches the > > > + threshold1, otherwise 0. > > > > I'm used to things like this requiring user to reset the status, so it > > may be worth making it explicit that it will return to zero if > > consumption drops below threshold if that's what's happening here. > > If it's correct, perhaps could just say something like 'returns 1 if > > power consumption is currently at or above threshold1, otherwise 0' > > > > > + > > > +What: > > > /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2_status > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-only. It returns 1 if power consumption reaches the > > > + threshold2, otherwise 0. > > > > Same here. > > Sure, will fix all above comments in this sysfs doc. > > > > > > + > > > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/ltr > > > +Date: March 2019 > > > +KernelVersion: 5.2 > > > +Contact: Wu Hao > > > +Description: Read-only. Read this file to get current Latency Tolerance > > > + Reporting (ltr) value, it's only valid for integrated > > > + solution as it blocks CPU on low power state. > > > > If we're not on the integrated solution, it returns a value but it is > > not really real? > > Currently only integrated solution is
Re: [PATCH] fpga: dfl: afu: Pass the correct device to dma_mapping_error()
On Thu, Apr 11, 2019 at 11:36 AM Moritz Fischer
wrote:
Hi Scott,
Thanks!
>
> Hi Scott,
>
> good catch!
>
> On Thu, Apr 11, 2019 at 5:49 AM Wu Hao wrote:
> >
> > On Wed, Apr 10, 2019 at 04:53:27PM -0500, Scott Wood wrote:
> > > dma_mapping_error() was being called on a different device struct than
> > > what was passed to map/unmap. Besides rendering the error checking
> > > ineffective, it caused a debug splat with CONFIG_DMA_API_DEBUG.
> > >
> > > Signed-off-by: Scott Wood
> >
> > Hi Scott,
> >
> > Looks good to me. Thanks for catching this issue.
> >
> > Acked-by: Wu Hao
> >
> > Hao
> >
> > > ---
> > > drivers/fpga/dfl-afu-dma-region.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/fpga/dfl-afu-dma-region.c
> > > b/drivers/fpga/dfl-afu-dma-region.c
> > > index e18a786fc943..cd68002ac097 100644
> > > --- a/drivers/fpga/dfl-afu-dma-region.c
> > > +++ b/drivers/fpga/dfl-afu-dma-region.c
> > > @@ -399,7 +399,7 @@ int afu_dma_map_region(struct
> > > dfl_feature_platform_data *pdata,
> > > region->pages[0], 0,
> > > region->length,
> > > DMA_BIDIRECTIONAL);
> > > - if (dma_mapping_error(>dev->dev, region->iova)) {
> > > + if (dma_mapping_error(dfl_fpga_pdata_to_parent(pdata),
> > > region->iova)) {
> > > dev_err(>dev->dev, "failed to map for dma\n");
> > > ret = -EFAULT;
> > > goto unpin_pages;
> > > --
> > > 1.8.3.1
>
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
>
> Thanks
> Moritz
Alan
Re: [PATCH 09/17] fpga: dfl: add id_table for dfl private feature driver
On Tue, Apr 2, 2019 at 10:09 AM Moritz Fischer wrote: > > Hi Wu, > > On Mon, Mar 25, 2019 at 11:07:36AM +0800, Wu Hao wrote: > > This patch adds id_table for each dfl private feature driver, > > it allows to reuse same private feature driver to match and support > > multiple dfl private features. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > Acked-by: Moritz Fischer Acked-by: Alan Tull Thanks, Alan
Re: [PATCH 10/17] fpga: dfl: afu: export __port_enable/disable function.
On Tue, Apr 2, 2019 at 10:50 AM Moritz Fischer wrote: Hi Hao, > > On Mon, Mar 25, 2019 at 11:07:37AM +0800, Wu Hao wrote: > > As these two functions are used by other private features. e.g. > > in error reporting private feature, it requires to check port status > > and reset port for error clearing. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > Acked-by: Moritz Fischer Acked-by: Alan Tull Thanks, Alan
Re: [PATCH 12/17] fpga: dfl: afu: add STP (SignalTap) support
On Tue, Apr 2, 2019 at 10:07 AM Moritz Fischer wrote: > > Hi Wu, > > On Mon, Mar 25, 2019 at 11:07:39AM +0800, Wu Hao wrote: > > STP (SignalTap) is one of the private features under the port for > > debugging. This patch adds private feature driver support for it > > to allow userspace applications to mmap related mmio region and > > provide STP service. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > Acked-by: Moritz Fischer Acked-by: Alan Tull Thanks, Alan
Re: [PATCH 15/17] fpga: dfl: fme: add power management support
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
Hi Hao,
>
> This patch adds support for power management private feature under
> FPGA Management Engine (FME), sysfs interfaces are introduced for
> different power management functions, users could use these sysfs
> interface to get current number of consumed power, throttling
How about
s/number/measurement/
?
> thresholds, threshold status and other information, and configure
> different value for throttling thresholds too.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-fme | 56 +
> drivers/fpga/dfl-fme-main.c | 257
> +++
> 2 files changed, 313 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> index d3aeb88..4b6448f 100644
> --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> @@ -100,3 +100,59 @@ Description: Read-only. Read this file to get the
> policy of temperature
> threshold1. It only supports two value (policy):
> 0 - AP2 state (90% throttling)
> 1 - AP1 state (50% throttling)
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/consumed
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns current power consumed by FPGA.
What are the units?
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-Write. Read/Write this file to get/set current power
> + threshold1 in Watts.
Perhaps document error codes here and for threshold2 below.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-Write. Read/Write this file to get/set current power
> + threshold2 in Watts.
> +
> +What:
> /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1_status
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns 1 if power consumption reaches the
> + threshold1, otherwise 0.
I'm used to things like this requiring user to reset the status, so it
may be worth making it explicit that it will return to zero if
consumption drops below threshold if that's what's happening here.
If it's correct, perhaps could just say something like 'returns 1 if
power consumption is currently at or above threshold1, otherwise 0'
> +
> +What:
> /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2_status
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns 1 if power consumption reaches the
> + threshold2, otherwise 0.
Same here.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/ltr
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get current Latency Tolerance
> + Reporting (ltr) value, it's only valid for integrated
> + solution as it blocks CPU on low power state.
If we're not on the integrated solution, it returns a value but it is
not really real?
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/xeon_limit
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get power limit for xeon, it
> + is only valid for integrated solution.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/fpga_limit
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get power limit for fpga, it
> + is only valid for integrated solution.
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 449a17d..dafa6580 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -415,6 +415,259 @@ static const struct dfl_feature_ops
> fme_thermal_mgmt_ops = {
> .uinit = fme_thermal_mgmt_uinit,
> };
>
> +#define FME_PWR_STATUS 0x8
> +#define FME_LATENCY_TOLERANCE BIT_ULL(18)
> +#define PWR_CONSUMED GENMASK_ULL(17, 0)
> +
> +#define FME_PWR_THRESHOLD 0x10
> +#define PWR_THRESHOLD1 GENMASK_ULL(6, 0) /* in Watts */
> +#define PWR_THRESHOLD2 GENMASK_ULL(14, 8) /* in Watts */
> +#define PWR_THRESHOLD_MAX 0x7f
> +#define PWR_THRESHOLD1_STATUS BIT_ULL(16)
> +#define PWR_THRESHOLD2_STATUS BIT_ULL(17)
> +
> +#define FME_PWR_XEON_LIMIT 0x18
> +#define XEON_PWR_LIMIT GENMASK_ULL(14, 0)
>
Re: Device Description for FPGA Components on x86 system
On Wed, Apr 10, 2019 at 7:50 AM Federico Vaga wrote: Hi Federico, I wish I could point you to a complete solution, but there is a lot of work to be done in this area. Most of what is in the kernel is a low level in-kernel API [4]. As you correctly state, the hardest part of this is doing the enumerating if you are on x86 and aren't using devicetree. > > Hi, > > P.S. sorry if I'm too verbose, hopefully it is useful > > thanks for the answer > > On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote: > > Hi, > > > > everything you want is already available and on the way to mainline > > concerning support for various FPGA loading modes or available for > > checkout from a git repository. > > All that has already been discussed on the mailing list. > > > > FPGA loading interface is available here [1]. > > Patchset missing for FPGA loading has been sent to the mailing list from > > Anatolij Gustschin for various Linux kernel versions. Link to the most > > recent patchset version [2]. > > FPGA Manager mailing list archive link [3] - Please read up the story > > here around those patches and also the replies of the others. > > This does not answer the problem, which perhaps need to be clarified. > > Loading FPGA is **not** the problem, I listed it in the things I want to > achieve because it is a pre-requirement for the real problem and because the > two processes are linked (or could be). > > I continue by commenting myself below, trying to make the use case clearer. > > > > > Cheers > > Eric > > > > [1] https://github.com/vdsao/fpga-cfg > > [2] https://marc.info/?l=linux-fpga=155078072107199=2 > > [3] https://marc.info/?l=linux-fpga > > > > Am 10.04.2019 12:01, schrieb Federico Vaga: > > > Hello, > > > > > > sorry to push for an answer but I do not want to take the risk of > > > designing > > > something useless. I do not know how should I interpret a no-answer. > > > > > > If the solution really does not exist today, then I would like to > > > collect > > > opinions/arguments/requirements on the topic so that I can write > > > something > > > useful not only for CERN but for the entire community. > > > > > > Thank you > > > > > > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote: > > >> Hello, > > >> > > >> I'm looking for guidance > > >> > > >> What I have: > > >> * Intel x86_64 computer > > >> * PCIe card with FPGA on it > > >> > > >> What I want to achieve: > > >> * load an FPGA bitstream on the card > > >> * load a device-tree like description for the FPGA devices contained > > >> in the bitstream > > Let me first elaborate on my knowledge to avoid misunderstandings. > > On ARM, nowadays, we boot with a device tree. Later we program an FPGA in > which there are other devices described by a device tree overlay. This can be > done easily. > > A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible, but > it is not common and probably not even suggested, not sure), instead it uses > ACPI. I have heard it suggested that we work on using DT overlays on x86*. It's clear there's work to be done to make that work. I don't know if anybody has really tried. It seems impractical to map or translate a x86 systems ACPI into a DT and go from there. One suggestion a few years ago was adding a partial DT that had nodes that could serve as overlay targets and have that running in parallel with ACPI. > > The FPGA Manager has support only for DeviceTree (there are patching floating > around to load a bitstream with configfs, debugfs or a chardevice (guilty)) There's one other interface in the kernel upstream. The DFL (device feature list) framework built on the FPGA manager/bridge/region stuff [5]. It's probably not what you specifically are looking for, I'm mentioning as it exists in upstream. It has a limited type of enumeration and appears to mostly be geared for acceleration rather than adding and enumerating any random hardware block. Also it requires specific bitstreams as the feature list is in fpga fabric. > > Most drivers foresee a DeviceTree loading but not an ACPI one (my feeling, I > did not extract exact numbers from the sources) > > DeviceTree overlay requires that the system boots with DeviceTree. > > DeviceTree and ACPI do not work together > > So, this is the state of art that I am aware of. Correct me if, and where, I > am wrong. > > > Restarting from this point. I have a PC (x86_64) with a PCIe FPGA card (e.g. > sis8160, spec, links below). How to load the FPGA bitstream (not really a > problem as you correctly pointed out) **and** load all the IP-core instances > in that FPGA bitstream so that drivers will start running? > > - Is there a recommendation for such use case? > - ACPI SSDT overlay? > - DT overlay? > - is there a standard way to load FPGA IP-core devices which is architecture > independent? > > A simple and practical example. The i2c-ocore.c is a platform_driver for an > HDL I2C Master from open cores. I synthesize it and then load it
Re: [PATCH 16/17] fpga: dfl: fme: add global error reporting support
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: Hi Hao, > > This patch adds support for global error reporting for FPGA > Management Engine (FME), it introduces sysfs interfaces to > report different error detected by the hardware, and allow > user to clear errors or inject error for testing purpose. > > Signed-off-by: Luwei Kang > Signed-off-by: Ananda Ravuri > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > Documentation/ABI/testing/sysfs-platform-dfl-fme | 58 > drivers/fpga/Makefile| 2 +- > drivers/fpga/dfl-fme-error.c | 390 > +++ > drivers/fpga/dfl-fme-main.c | 4 + > drivers/fpga/dfl-fme.h | 2 + > drivers/fpga/dfl.h | 2 + > 6 files changed, 457 insertions(+), 1 deletion(-) > create mode 100644 drivers/fpga/dfl-fme-error.c > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > index 4b6448f..38f9cdd 100644 > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > @@ -156,3 +156,61 @@ KernelVersion: 5.2 > Contact: Wu Hao > Description: Read-only. Read this file to get power limit for fpga, it > is only valid for integrated solution. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/errors > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. Read this file to get errors detected by hardware. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/first_error > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. Read this file to get the first error detected by > + hardware. > + > +What: > /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/next_error > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. Read this file to get the second error detected by > + hardware. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/clear > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Write-only. Write error code to this file to clear errors. If > + the input error code doesn't match, it returns -EBUSY. As with the afu errors patch, seems like -EINVAL would be better. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie0_errors > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns errors detected on pcie0 link. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie1_errors > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns errors detected on pcie1 link. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/nonfatal_errors > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns non-fatal errors detected. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/catfatal_errors > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-only. It returns catastrophic and fatal errors detected. > + > +What: /sys/bus/platform/devices/dfl-fme.0/errors/inject_error > +Date: March 2019 > +KernelVersion: 5.2 > +Contact: Wu Hao > +Description: Read-Write. Write this file to inject errors for testing > + purpose. Read this file to check errors injected. > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index f1f0af7..1a9fa3d 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -38,7 +38,7 @@ obj-$(CONFIG_FPGA_DFL_FME_BRIDGE) += dfl-fme-br.o > obj-$(CONFIG_FPGA_DFL_FME_REGION) += dfl-fme-region.o > obj-$(CONFIG_FPGA_DFL_AFU) += dfl-afu.o > > -dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o > +dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o dfl-fme-error.o > dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o > dfl-afu-objs += dfl-afu-error.o > > diff --git a/drivers/fpga/dfl-fme-error.c b/drivers/fpga/dfl-fme-error.c > new file mode 100644 > index 000..f2bd5f8 > --- /dev/null > +++ b/drivers/fpga/dfl-fme-error.c > @@ -0,0 +1,390 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Driver for FPGA Management Engine Error Management > + * > + * Copyright 2019 Intel Corporation, Inc. > + * > + * Authors: > + * Kang Luwei > + * Xiao Guangrong > + * Wu Hao > + * Joseph Grecco > + * Enno Luebbers > + * Tim Whisonant > + * Ananda Ravuri > + * Mitchel, Henry > + */ > + > +#include > + > +#include "dfl.h" > +#include "dfl-fme.h" > + > +#define FME_ERROR_MASK
Re: [PATCH 13/17] fpga: dfl: fme: add capability sysfs interfaces
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
Hi Hao,
Looks good...
>
> This patch adds 3 read-only sysfs interfaces for FPGA Management Engine
> (FME) block for capabilities including cache_size, fabric_version and
> socket_id.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
Thanks,
Alan
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-fme | 23
> drivers/fpga/dfl-fme-main.c | 48
>
> 2 files changed, 71 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> index 8fa4feb..b8327e9 100644
> --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> @@ -21,3 +21,26 @@ Contact: Wu Hao
> Description: Read-only. It returns Bitstream (static FPGA region) meta
> data, which includes the synthesis date, seed and other
> information of this static FPGA region.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/cache_size
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns cache size of this FPGA device.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/fabric_version
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns fabric version of this FPGA device.
> + Userspace applications need this information to select
> + best data channels per different fabric design.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/socket_id
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. It returns socket_id to indicate which socket
> + this FPGA belongs to, only valid for integrated solution.
> + User only needs this information, in case standard numa node
> + can't provide correct information.
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 38c6342..8339ee8 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -75,10 +75,58 @@ static ssize_t bitstream_metadata_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(bitstream_metadata);
>
> +static ssize_t cache_size_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + void __iomem *base;
> + u64 v;
> +
> + base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
> +
> + v = readq(base + FME_HDR_CAP);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n",
> +(unsigned int)FIELD_GET(FME_CAP_CACHE_SIZE, v));
> +}
> +static DEVICE_ATTR_RO(cache_size);
> +
> +static ssize_t fabric_version_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + void __iomem *base;
> + u64 v;
> +
> + base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
> +
> + v = readq(base + FME_HDR_CAP);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n",
> +(unsigned int)FIELD_GET(FME_CAP_FABRIC_VERID, v));
> +}
> +static DEVICE_ATTR_RO(fabric_version);
> +
> +static ssize_t socket_id_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + void __iomem *base;
> + u64 v;
> +
> + base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
> +
> + v = readq(base + FME_HDR_CAP);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n",
> +(unsigned int)FIELD_GET(FME_CAP_SOCKET_ID, v));
> +}
> +static DEVICE_ATTR_RO(socket_id);
> +
> static const struct attribute *fme_hdr_attrs[] = {
> _attr_ports_num.attr,
> _attr_bitstream_id.attr,
> _attr_bitstream_metadata.attr,
> + _attr_cache_size.attr,
> + _attr_fabric_version.attr,
> + _attr_socket_id.attr,
> NULL,
> };
>
> --
> 2.7.4
>
Re: [PATCH 11/17] fpga: dfl: afu: add error reporting support.
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
Hi Hao,
>
> Error reporting is one important private feature, it reports error
> detected on port and accelerated function unit (AFU). It introduces
> several sysfs interfaces to allow userspace to check and clear
> errors detected by hardware.
>
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-port | 29 +++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/dfl-afu-error.c | 225
> ++
> drivers/fpga/dfl-afu-main.c | 4 +
> drivers/fpga/dfl-afu.h| 4 +
> 5 files changed, 263 insertions(+)
> create mode 100644 drivers/fpga/dfl-afu-error.c
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port
> b/Documentation/ABI/testing/sysfs-platform-dfl-port
> index f611e47..e6140aa 100644
> --- a/Documentation/ABI/testing/sysfs-platform-dfl-port
> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-port
> @@ -79,3 +79,32 @@ KernelVersion: 5.2
> Contact: Wu Hao
> Description: Read-only. Read this file to get the status of issued command
> to userclck_freqcntrcmd.
> +
> +What: /sys/bus/platform/devices/dfl-port.0/errors/errors
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get errors detected on port and
> + Accelerated Function Unit (AFU).
> +
> +What: /sys/bus/platform/devices/dfl-port.0/errors/first_error
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get the first error detected by
> + hardware.
> +
> +What:
> /sys/bus/platform/devices/dfl-port.0/errors/first_malformed_req
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Read-only. Read this file to get the first malformed request
> + captured by hardware.
> +
> +What: /sys/bus/platform/devices/dfl-port.0/errors/clear
> +Date: March 2019
> +KernelVersion: 5.2
> +Contact: Wu Hao
> +Description: Write-only. Write error code to this file to clear errors. If
> + the input error code doesn't match, it returns -EBUSY error
> + code.
I understand how -EBUSY could be the right error code for when the
hardware is in a state where the error can't be cleared. But if the
input error code doesn't match, shouldn't the code be -EINVAL? Also
as noted below, the way this is currently coded, -ETIMEDOUT could get
returned.
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c0dd4c8..f1f0af7 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_FPGA_DFL_AFU)+= dfl-afu.o
>
> dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
> dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o
> +dfl-afu-objs += dfl-afu-error.o
>
> # Drivers for FPGAs which implement DFL
> obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> diff --git a/drivers/fpga/dfl-afu-error.c b/drivers/fpga/dfl-afu-error.c
> new file mode 100644
> index 000..b66bd4a
> --- /dev/null
> +++ b/drivers/fpga/dfl-afu-error.c
> @@ -0,0 +1,225 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for FPGA Accelerated Function Unit (AFU) Error Reporting
> + *
> + * Copyright 2019 Intel Corporation, Inc.
> + *
> + * Authors:
> + * Wu Hao
> + * Xiao Guangrong
> + * Joseph Grecco
> + * Enno Luebbers
> + * Tim Whisonant
> + * Ananda Ravuri
> + * Mitchel Henry
> + */
> +
> +#include
> +
> +#include "dfl-afu.h"
> +
> +#define PORT_ERROR_MASK0x8
> +#define PORT_ERROR 0x10
> +#define PORT_FIRST_ERROR 0x18
> +#define PORT_MALFORMED_REQ00x20
> +#define PORT_MALFORMED_REQ10x28
> +
> +#define ERROR_MASK GENMASK_ULL(63, 0)
> +
> +/* mask or unmask port errors by the error mask register. */
> +static void __port_err_mask(struct device *dev, bool mask)
> +{
> + void __iomem *base;
> +
> + base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_ERROR);
> +
> + writeq(mask ? ERROR_MASK : 0, base + PORT_ERROR_MASK);
> +}
> +
> +/* clear port errors. */
> +static int __port_err_clear(struct device *dev, u64 err)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + void __iomem *base_err, *base_hdr;
> + int ret;
> + u64 v;
> +
> + base_err = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_ERROR);
> + base_hdr = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_HEADER);
> +
> + /*
> +* clear Port Errors
> +*
> +* - Check for AP6 State
> +* - Halt Port by keeping Port in reset
> +* - Set PORT Error mask to all 1 to mask errors
> +* - Clear all errors
> +* - Set
Re: [PATCH v4 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
On Mon, Apr 8, 2019 at 11:51 AM Moritz Fischer wrote: > > Hi Michal, > > On Mon, Apr 08, 2019 at 04:36:15PM +0200, Michal Simek wrote: > > On 08. 04. 19 16:17, Alan Tull wrote: > > > On Mon, Apr 8, 2019 at 7:39 AM Nava kishore Manne > > > wrote: > > >> > > >> Hi Alan, > > >> > > >> Thanks for look into it and providing the ACK. > > >> I got one minor comments from Moritz Fischer do you want me fix that > > >> issue now or I can fix it later as it’s a minor comment? > > > > > > Please fix for Moritz comment. > > > > > >> In which kernel version i can expect this driver changes?? > > > > > > Patch 2/3 and 3/3 are dependent on 1/3 which isn't a drivers/fpga > > > thing, it's drivers/firmware. > > > > I can take it via arm-soc guys if you are ok with that. > > Just need to have your ack in commits. > > We have done it like this several times, IIRC reset, nvmem. > > I'm fine with you taking it through arm-soc. Alan? Fine with me! Alan > I'll look at the other > patches. > > Thanks, > Moritz
Re: [PATCH v4 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
On Mon, Apr 8, 2019 at 7:39 AM Nava kishore Manne wrote: > > Hi Alan, > > Thanks for look into it and providing the ACK. > I got one minor comments from Moritz Fischer do you want me fix that issue > now or I can fix it later as it’s a minor comment? Please fix for Moritz comment. > In which kernel version i can expect this driver changes?? Patch 2/3 and 3/3 are dependent on 1/3 which isn't a drivers/fpga thing, it's drivers/firmware. Alan > > > Regards, > Navakishore. > > > -Original Message- > > From: Alan Tull [mailto:at...@kernel.org] > > Sent: Tuesday, April 2, 2019 11:57 PM > > To: Nava kishore Manne > > Cc: Moritz Fischer ; Rob Herring ; Mark > > Rutland ; Michal Simek ; Rajan > > Vaja ; Jolly Shah ; linux- > > f...@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED DEVICE > > TREE BINDINGS ; moderated list:ARM/FREESCALE > > IMX / MXC ARM ARCHITECTURE ; linux- > > kernel ; kishore m > > > > Subject: Re: [PATCH v4 3/3] fpga manager: Adding FPGA Manager support for > > Xilinx zynqmp > > > > On Tue, Apr 2, 2019 at 7:32 AM Nava kishore Manne > > wrote: > > > > Hi Nava, > > > > Looks good. > > > > > > > > This patch adds FPGA Manager support for the Xilinx ZynqMP chip. > > > > > > Signed-off-by: Nava kishore Manne > > Acked-by: Alan Tull > > > > > --- > > > Changes for v4: > > > -Updated the Fpga Mgr registrations call's > > > to 5.0 > > > -Removed dma_set_mask_and_coherent() As the FW > > > supports only 32-bit address operations. > > > > > > Changes for v3: > > > -Created patches on top of 5.0-rc5. > > > No functional changes. > > > > > > Changes for v2: > > > -Fixed some minor coding issues as suggested by > > > Moritz > > > > > > Changes for v1: > > > -None. > > > > > > Changes for RFC-V2: > > > -Updated the Fpga Mgr registrations call's > > > to 4.18 > > > > Thanks, > > Alan
Re: [PATCHv1] fpga: mgr: add FPGA configuration log
On Wed, Apr 3, 2019 at 3:08 PM Moritz Fischer wrote: > > On Wed, Apr 03, 2019 at 01:37:51PM -0500, Alan Tull wrote: > > > > > > it's state, not status for most fpga manager drivers. It should > > > return 'operating' if everything went well. > > Yeah, sorry :) > > > > It seems like there's a possible scenario where the FPGA starts up > > > with the FPGA in 'operating' mode and the user messes up early enough > > > that the state doesn't change. > > Huh, then we should fix that instead? :) > > > > > > > > > > > Personally not in favor of extra messages, but if we do it we should > > > > change the message to "Sucessfully programmed FPGA". > > > > > > > > I think making it a dbg message is a good trade-off ... > > > > dbg vs info... On the one hand, it is a usually a message the > > developer wants to see so the developer would turn on debug messages. > > But then again FPGA programming doesn't happen that often and it is a > > kind of significant event since it is your hardware changing i.e. it > > won't add a lot messages, but it is sort of an important one if it > > happens. If the system crashes after a FPGA reprogramming event, it > > would be good to have this in the log by default. I don't want to > > argue too powerfully for adding extra messages though. Is this a case > > where info is worth it since fpga programming is significant? > > In the current setup, it doesn't happen often. Going forward people > might have use-cases where this happens a lot more often. Yes, then adding the message could become very spammy. > > I mean if y'all feel like this is required, sure, I still feel people > shouldn't rely on dmesg output for functional verification :) I agree with you that using sysfs to see what state the FPGA mgr ended up in should be adequate most of the time. We probably don't need this. > > I don't wanna guarantee that this message is gonna be there always ... Indeed... Thanks, Alan > > Cheers, > Moritz
Re: [PATCHv1] fpga: mgr: add FPGA configuration log
On Wed, Apr 3, 2019 at 1:05 PM Alan Tull wrote: > > On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote: > > > > Hi Richard, > > > > On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote: > > > Hi Moritz, > > > > > > > > > On 4/3/19 9:20 AM, Moritz Fischer wrote: > > > > Hi Richard, > > > > > > > > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.intel.com > > > > wrote: > > > > > From: Richard Gong > > > > > > > > > > Add a log for user to know FPGA configuration is successful > > > > > > > > > > Signed-off-by: Richard Gong > > > > > --- > > > > > drivers/fpga/fpga-mgr.c | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c > > > > > index c386681..559e046 100644 > > > > > --- a/drivers/fpga/fpga-mgr.c > > > > > +++ b/drivers/fpga/fpga-mgr.c > > > > > @@ -151,6 +151,7 @@ static int fpga_mgr_write_complete(struct > > > > > fpga_manager *mgr, > > > > > } > > > > > mgr->state = FPGA_MGR_STATE_OPERATING; > > > > > + dev_info(>dev, "Successfully programming FPGA\n"); > > > > > > > > That info is available in FPGA manager's sysfs status entry, if at all > > > > I'd make this a dev_dbg(). > > > > > > > > From my end I don't see how we need this really. > > > > > > We got requests from the field and they want to see a log to get know if > > > FPGA configuration is successfully completed. They don't want use any > > > additional command to get status. > > > > > > This log is useful for the user who performs FPGA configuration. > > > > > > I think we need use dev_info, since dev_dbg is not enabled by fault for > > > most > > > build. > > > > Well basically it boils down to: > > > > $ dmesg | grep "Sucessfully" > > > > vs > > > > $ cat /sys/class/fpga.../status > > it's state, not status for most fpga manager drivers. It should > return 'operating' if everything went well. > > It seems like there's a possible scenario where the FPGA starts up > with the FPGA in 'operating' mode and the user messes up early enough > that the state doesn't change. > > > > > Personally not in favor of extra messages, but if we do it we should > > change the message to "Sucessfully programmed FPGA". > > > > I think making it a dbg message is a good trade-off ... dbg vs info... On the one hand, it is a usually a message the developer wants to see so the developer would turn on debug messages. But then again FPGA programming doesn't happen that often and it is a kind of significant event since it is your hardware changing i.e. it won't add a lot messages, but it is sort of an important one if it happens. If the system crashes after a FPGA reprogramming event, it would be good to have this in the log by default. I don't want to argue too powerfully for adding extra messages though. Is this a case where info is worth it since fpga programming is significant? > > > > Moritz
Re: [PATCHv1] fpga: mgr: add FPGA configuration log
On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote: > > Hi Richard, > > On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote: > > Hi Moritz, > > > > > > On 4/3/19 9:20 AM, Moritz Fischer wrote: > > > Hi Richard, > > > > > > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.intel.com > > > wrote: > > > > From: Richard Gong > > > > > > > > Add a log for user to know FPGA configuration is successful > > > > > > > > Signed-off-by: Richard Gong > > > > --- > > > > drivers/fpga/fpga-mgr.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c > > > > index c386681..559e046 100644 > > > > --- a/drivers/fpga/fpga-mgr.c > > > > +++ b/drivers/fpga/fpga-mgr.c > > > > @@ -151,6 +151,7 @@ static int fpga_mgr_write_complete(struct > > > > fpga_manager *mgr, > > > > } > > > > mgr->state = FPGA_MGR_STATE_OPERATING; > > > > + dev_info(>dev, "Successfully programming FPGA\n"); > > > > > > That info is available in FPGA manager's sysfs status entry, if at all > > > I'd make this a dev_dbg(). > > > > > > From my end I don't see how we need this really. > > > > We got requests from the field and they want to see a log to get know if > > FPGA configuration is successfully completed. They don't want use any > > additional command to get status. > > > > This log is useful for the user who performs FPGA configuration. > > > > I think we need use dev_info, since dev_dbg is not enabled by fault for most > > build. > > Well basically it boils down to: > > $ dmesg | grep "Sucessfully" > > vs > > $ cat /sys/class/fpga.../status it's state, not status for most fpga manager drivers. It should return 'operating' if everything went well. It seems like there's a possible scenario where the FPGA starts up with the FPGA in 'operating' mode and the user messes up early enough that the state doesn't change. > > Personally not in favor of extra messages, but if we do it we should > change the message to "Sucessfully programmed FPGA". > > I think making it a dbg message is a good trade-off ... > > Moritz
Re: [PATCHv1] fpga: mgr: add FPGA configuration log
On Wed, Apr 3, 2019 at 9:20 AM Moritz Fischer wrote: > > Hi Richard, > > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.intel.com wrote: > > From: Richard Gong > > > > Add a log for user to know FPGA configuration is successful > > > > Signed-off-by: Richard Gong > > --- > > drivers/fpga/fpga-mgr.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c > > index c386681..559e046 100644 > > --- a/drivers/fpga/fpga-mgr.c > > +++ b/drivers/fpga/fpga-mgr.c > > @@ -151,6 +151,7 @@ static int fpga_mgr_write_complete(struct fpga_manager > > *mgr, > > } > > mgr->state = FPGA_MGR_STATE_OPERATING; > > > > + dev_info(>dev, "Successfully programming FPGA\n"); > > That info is available in FPGA manager's sysfs status entry, if at all > I'd make this a dev_dbg(). > > From my end I don't see how we need this really. I'm ok with adding a message. It's not adding lots of messages, just one line for an event that will only happen for people who care about the event (not too many FPGA users but if someone is using FPGA, they will care about this.) Alan > > Thanks, > Moritz
Re: [PATCH v4 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
On Tue, Apr 2, 2019 at 7:32 AM Nava kishore Manne wrote: Hi Nava, Looks good. > > This patch adds FPGA Manager support for the Xilinx > ZynqMP chip. > > Signed-off-by: Nava kishore Manne Acked-by: Alan Tull > --- > Changes for v4: > -Updated the Fpga Mgr registrations call's > to 5.0 > -Removed dma_set_mask_and_coherent() As the FW > supports only 32-bit address operations. > > Changes for v3: > -Created patches on top of 5.0-rc5. > No functional changes. > > Changes for v2: > -Fixed some minor coding issues as suggested by > Moritz > > Changes for v1: > -None. > > Changes for RFC-V2: > -Updated the Fpga Mgr registrations call's > to 4.18 Thanks, Alan
Re: [PATCH 08/17] fpga: dfl: afu: add userclock sysfs interfaces.
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: Hi Hao, Looks fine. > > This patch introduces userclock sysfs interfaces for AFU, user > could use these interfaces for clock setting to AFU. > > Please note that, this is only working for port header feature > with revision 0, for later revisions, userclock setting is moved > to a separated private feature, so one revision sysfs interface > is exposed to userspace application for this purpose too. > > Signed-off-by: Ananda Ravuri > Signed-off-by: Russ Weight > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull
Re: [PATCH v5 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
On Thu, Mar 28, 2019 at 12:00 PM Rob Herring wrote: > > On Tue, 26 Mar 2019 20:01:29 +0530, Nava kishore Manne wrote: > > Add documentation to describe Xilinx ZynqMP fpga driver > > bindings. > > > > Signed-off-by: Nava kishore Manne > > --- > > Changes for v5: > > -Moved pcap node as a child to firwmare > >node as suggested by Rob. > > Changes for v4: > > -Modified binding description as suggested by Moritz Fischer. > > Changes for v3: > > -Removed PCAP as a child node to the FW and Created > >an independent node since PCAP driver is a consumer > >not a provider. > > > > .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 25 +++ > > 1 file changed, 25 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt > > > > Reviewed-by: Rob Herring Acked-by: Alan Tull
Re: [PATCH 05/17] fpga: dfl: fme: add DFL_FPGA_FME_PORT_RELEASE/ASSIGN ioctl support.
On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote: > > In order to support virtualization usage via PCIe SRIOV, this patch > adds two ioctls under FPGA Management Engine (FME) to release and > assign back the port device. In order to safely turn Port from PF > into VF and enable PCIe SRIOV, it requires user to invoke this > PORT_RELEASE ioctl to release port firstly to remove userspace > interfaces, and then configure the PF/VF access register in FME. > After disable SRIOV, it requires user to invoke this PORT_ASSIGN > ioctl to attach the port back to PF. > > Ioctl interfaces: > * DFL_FPGA_FME_PORT_RELEASE >Release platform device of given port, it deletes port platform >device to remove related userspace interfaces on PF, then >configures PF/VF access mode to VF. > > * DFL_FPGA_FME_PORT_ASSIGN >Assign platform device of given port back to PF, it configures >PF/VF access mode to PF, then adds port platform device back to >re-enable related userspace interfaces on PF. > > Signed-off-by: Zhang Yi Z > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull
Re: [PATCH 06/17] fpga: dfl: pci: enable SRIOV support.
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: > > This patch enables the standard sriov support. It allows user to > enable SRIOV (and VFs), then user could pass through accelerators > (VFs) into virtual machine or use VFs directly in host. > > Signed-off-by: Zhang Yi Z > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull
Re: [PATCH 02/17] fpga: dfl: fme: align PR buffer size per PR datawidth
On Mon, Mar 25, 2019 at 7:44 PM Wu Hao wrote: > > On Mon, Mar 25, 2019 at 12:50:40PM -0500, Alan Tull wrote: > > On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote: > > > > Hi Hao, > > > > Looks good, one question below. > > > > > > > > Current driver checks if input bitstream file size is aligned or > > > not per PR data width (default 32bits). It requires one additional > > > step for end user when they generate the bitstream file, padding > > > extra zeros to bitstream file to align its size per PR data width, > > > but they don't have to as hardware will drop extra padding bytes > > > automatically. > > > > > > In order to simplify the user steps, this patch aligns PR buffer > > > size per PR data width in driver, to allow user to pass unaligned > > > size bitstream files to driver. > > > > > > Signed-off-by: Xu Yilun > > > Signed-off-by: Wu Hao Acked-by: Alan Tull Thanks, Alan
Re: [PATCH 07/17] fpga: dfl: afu: add AFU state related sysfs interfaces
On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: Hi Hao, > > This patch introduces more sysfs interfaces for Accelerated > Function Unit (AFU). These interfaces allow users to read > current AFU Power State (APx), read / clear AFU Power (APx) > events which are sticky to identify transient APx state, > and manage AFU's LTR (latency tolerance reporting). > > Signed-off-by: Ananda Ravuri > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull Thanks, Alan
Re: [PATCH 03/17] fpga: dfl: fme: support 512bit data width PR
On Mon, Mar 25, 2019 at 5:58 PM Scott Wood wrote:
Hi Scott,
>
> On Mon, 2019-03-25 at 17:53 -0500, Scott Wood wrote:
> > On Mon, 2019-03-25 at 11:07 +0800, Wu Hao wrote:
> > > In early partial reconfiguration private feature, it only
> > > supports 32bit data width when writing data to hardware for
> > > PR. 512bit data width PR support is an important optimization
> > > for some specific solutions (e.g. XEON with FPGA integrated),
> > > it allows driver to use AVX512 instruction to improve the
> > > performance of partial reconfiguration. e.g. programming one
> > > 100MB bitstream image via this 512bit data width PR hardware
> > > only takes ~300ms, but 32bit revision requires ~3s per test
> > > result.
> > >
> > > Please note now this optimization is only done on revision 2
> > > of this PR private feature which is only used in integrated
> > > solution that AVX512 is always supported.
> > >
> > > Signed-off-by: Ananda Ravuri
> > > Signed-off-by: Xu Yilun
> > > Signed-off-by: Wu Hao
> > > ---
> > > drivers/fpga/dfl-fme-main.c | 3 ++
> > > drivers/fpga/dfl-fme-mgr.c | 75 +-
> > > --
> > > -
> > > drivers/fpga/dfl-fme-pr.c | 45 ---
> > > drivers/fpga/dfl-fme.h | 2 ++
> > > drivers/fpga/dfl.h | 5 +++
> > > 5 files changed, 99 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > > index 086ad24..076d74f 100644
> > > --- a/drivers/fpga/dfl-fme-main.c
> > > +++ b/drivers/fpga/dfl-fme-main.c
> > > @@ -21,6 +21,8 @@
> > > #include "dfl.h"
> > > #include "dfl-fme.h"
> > >
> > > +#define DRV_VERSION"0.8"
> >
> > What is this going to be used for? Under what circumstances will the
> > driver version be bumped? What does it have to do with 512-bit writes?
> >
> > > +#if defined(CONFIG_X86) && defined(CONFIG_AS_AVX512)
> > > +
> > > +#include
> > > +
> > > +static inline void copy512(void *src, void __iomem *dst)
> > > +{
> > > + kernel_fpu_begin();
> > > +
> > > + asm volatile("vmovdqu64 (%0), %%zmm0;"
> > > +"vmovntdq %%zmm0, (%1);"
> > > +:
> > > +: "r"(src), "r"(dst));
> > > +
> > > + kernel_fpu_end();
> > > +}
> >
> > Shouldn't there be some sort of check that AVX512 is actually supported
> > on the running system?
> >
> > Also, src should be const, and the asm statement should have a memory
> > clobber.
> >
> > > +#else
> > > +static inline void copy512(void *src, void __iomem *dst)
> > > +{
> > > + WARN_ON_ONCE(1);
> > > +}
> > > +#endif
> >
> > Likewise, this will be called if a revision 2 device is used on non-x86
> > (or on x86 with an old binutils). The driver should fall back to 32-bit
> > in such cases.
>
> Sorry, I missed the comment about revision 2 only being on integrated
> devices -- but will that always be the case? Seems worthwhile to check for
> AVX512 support anyway. And there's still the possibility of being built
> with an old binutils such that CONFIG_AS_AVX512 is not set, or running on a
> kernel where avx512 was disabled via a boot option.
The code checks for CONFIG_AS_AVX512 above.
What boot option are you referring to?
Alan
>
> What about future revisions >= 2? Currently the driver will treat them as
> if they were revision < 2. Is that intended?
>
> -Scott
>
>
Re: [PATCH 03/17] fpga: dfl: fme: support 512bit data width PR
On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote: Hi Hao, This looks fine. > > In early partial reconfiguration private feature, it only > supports 32bit data width when writing data to hardware for > PR. 512bit data width PR support is an important optimization > for some specific solutions (e.g. XEON with FPGA integrated), > it allows driver to use AVX512 instruction to improve the > performance of partial reconfiguration. e.g. programming one > 100MB bitstream image via this 512bit data width PR hardware > only takes ~300ms, but 32bit revision requires ~3s per test > result. > > Please note now this optimization is only done on revision 2 > of this PR private feature which is only used in integrated > solution that AVX512 is always supported. > > Signed-off-by: Ananda Ravuri > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao Acked-by: Alan Tull
Re: [PATCH 02/17] fpga: dfl: fme: align PR buffer size per PR datawidth
On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote: Hi Hao, Looks good, one question below. > > Current driver checks if input bitstream file size is aligned or > not per PR data width (default 32bits). It requires one additional > step for end user when they generate the bitstream file, padding > extra zeros to bitstream file to align its size per PR data width, > but they don't have to as hardware will drop extra padding bytes > automatically. > > In order to simplify the user steps, this patch aligns PR buffer > size per PR data width in driver, to allow user to pass unaligned > size bitstream files to driver. > > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > drivers/fpga/dfl-fme-pr.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl-fme-pr.c > index d9ca955..c1fb1fe 100644 > --- a/drivers/fpga/dfl-fme-pr.c > +++ b/drivers/fpga/dfl-fme-pr.c > @@ -74,6 +74,7 @@ static int fme_pr(struct platform_device *pdev, unsigned > long arg) > struct dfl_fme *fme; > unsigned long minsz; > void *buf = NULL; > + size_t length; > int ret = 0; > u64 v; > > @@ -85,9 +86,6 @@ static int fme_pr(struct platform_device *pdev, unsigned > long arg) > if (port_pr.argsz < minsz || port_pr.flags) > return -EINVAL; > > - if (!IS_ALIGNED(port_pr.buffer_size, 4)) > - return -EINVAL; > - > /* get fme header region */ > fme_hdr = dfl_get_feature_ioaddr_by_id(>dev, >FME_FEATURE_ID_HEADER); > @@ -103,7 +101,13 @@ static int fme_pr(struct platform_device *pdev, unsigned > long arg) >port_pr.buffer_size)) > return -EFAULT; > > - buf = vmalloc(port_pr.buffer_size); > + /* > +* align PR buffer per PR bandwidth, as HW ignores the extra padding > +* data automatically. > +*/ > + length = ALIGN(port_pr.buffer_size, 4); > + > + buf = vmalloc(length); Since it may not be completely filled, would it be worthwhile to alloc a zero'ed buff? Alan > if (!buf) > return -ENOMEM; > > @@ -140,7 +144,7 @@ static int fme_pr(struct platform_device *pdev, unsigned > long arg) > fpga_image_info_free(region->info); > > info->buf = buf; > - info->count = port_pr.buffer_size; > + info->count = length; > info->region_id = port_pr.port_id; > region->info = info; > > -- > 2.7.4 >
Re: [PATCH 01/17] fpga: dfl-fme-mgr: fix FME_PR_INTFC_ID register address.
On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote: Hi Hao, > > FME_PR_INTFC_ID is used as compat_id for fpga manager and region, > but high 64 bits and low 64 bits of the compat_id are swapped by > mistake. This patch fixes this problem by fixing register address. > > Signed-off-by: Wu Hao Acked-by: Alan Tull Thanks, Alan > --- > drivers/fpga/dfl-fme-mgr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > index 76f3770..b3f7eee 100644 > --- a/drivers/fpga/dfl-fme-mgr.c > +++ b/drivers/fpga/dfl-fme-mgr.c > @@ -30,8 +30,8 @@ > #define FME_PR_STS 0x10 > #define FME_PR_DATA0x18 > #define FME_PR_ERR 0x20 > -#define FME_PR_INTFC_ID_H 0xA8 > -#define FME_PR_INTFC_ID_L 0xB0 > +#define FME_PR_INTFC_ID_L 0xA8 > +#define FME_PR_INTFC_ID_H 0xB0 > > /* FME PR Control Register Bitfield */ > #define FME_PR_CTRL_PR_RST BIT_ULL(0) /* Reset PR engine */ > -- > 2.7.4 >
Re: [PATCH v3 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
On Tue, Feb 12, 2019 at 5:06 AM Moritz Fischer wrote:
Hi Nava,
> > + mgr = fpga_mgr_create(dev, "Xilinx ZynqMP FPGA Manager",
> > + _fpga_ops, priv);
Please use the new devm_fpga_mgr_create()
> > + if (!mgr)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, mgr);
> > +
> > + err = fpga_mgr_register(mgr);
> vs here.
> > + if (err) {
> > + dev_err(dev, "unable to register FPGA manager");
> > + fpga_mgr_free(mgr);
With devm_fpga_mgr_create(), this fpga_mgr_free() can go away.
> > + return err;
> > + }
> > +
> > + return 0;
Thanks,
Alan
Re: [GIT PULL] of: overlay: validation checks, subsequent fixes for v20 -- correction: v4.20
On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman wrote: > > On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote: > > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote: > > > > What LTSI's are these patches likely to end up in? Just to be clear, > > I'm not pushing for any specific answer, I just want to know what to > > expect. > > I have no idea what you are asking here. > > What patches? I probably should have asked my question *below* the pertinent context of the the 17 patches listed in the pull request, which was: > of: overlay: add tests to validate kfrees from overlay removal > of: overlay: add missing of_node_put() after add new node to changeset > of: overlay: add missing of_node_get() in __of_attach_node_sysfs > powerpc/pseries: add of_node_put() in dlpar_detach_node() > of: overlay: use prop add changeset entry for property in new nodes > of: overlay: do not duplicate properties from overlay for new nodes > of: overlay: reorder fields in struct fragment > of: overlay: validate overlay properties #address-cells and #size-cells > of: overlay: make all pr_debug() and pr_err() messages unique > of: overlay: test case of two fragments adding same node > of: overlay: check prevents multiple fragments add or delete same node > of: overlay: check prevents multiple fragments touching same property > of: unittest: remove unused of_unittest_apply_overlay() argument > of: overlay: set node fields from properties when add new overlay node > of: unittest: allow base devicetree to have symbol metadata > of: unittest: find overlays[] entry by name instead of index > of: unittest: initialize args before calling of_*parse_*() > What is "LTSI's"? I have recently seen some of devicetree patches being picked up for the 4.20 stable-queue. That seemed to suggest that some, but not all of these will end up in the next LTS release. Also I was wondering if any of this is likely to get backported to LTSI-4.14. > > confused, Yes, and now I'm confused about the confusion. Sorry for spreading confusion. Alan > > greg k-h
Re: [GIT PULL] of: overlay: validation checks, subsequent fixes for v20 -- correction: v4.20
On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote: What LTSI's are these patches likely to end up in? Just to be clear, I'm not pushing for any specific answer, I just want to know what to expect. Thanks, Alan > > On 11/8/18 10:56 PM, Frank Rowand wrote: > > Hi Rob, > > > > Please pull the changes to add the overlay validation checks. > > > > This is the v7 version of the patch series. > > > > -Frank > > > > > > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frowand/linux.git > > tags/kfree_validate_v7-for-4.20 > > > > for you to fetch changes up to eeb07c573ec307c53fe2f6ac6d8d11c261f64006: > > > > of: unittest: initialize args before calling of_*parse_*() (2018-11-08 > > 22:12:37 -0800) > > > > > > Add checks to (1) overlay apply process and (2) memory freeing > > triggered by overlay release. The checks are intended to detect > > possible memory leaks and invalid overlays. > > > > The checks revealed bugs in existing code. Fixed the bugs. > > > > While fixing bugs, noted other issues, which are fixed in > > separate patches. > > > > > > Frank Rowand (17): > > of: overlay: add tests to validate kfrees from overlay removal > > of: overlay: add missing of_node_put() after add new node to changeset > > of: overlay: add missing of_node_get() in __of_attach_node_sysfs > > powerpc/pseries: add of_node_put() in dlpar_detach_node() > > of: overlay: use prop add changeset entry for property in new nodes > > of: overlay: do not duplicate properties from overlay for new nodes > > of: overlay: reorder fields in struct fragment > > of: overlay: validate overlay properties #address-cells and > > #size-cells > > of: overlay: make all pr_debug() and pr_err() messages unique > > of: overlay: test case of two fragments adding same node > > of: overlay: check prevents multiple fragments add or delete same node > > of: overlay: check prevents multiple fragments touching same property > > of: unittest: remove unused of_unittest_apply_overlay() argument > > of: overlay: set node fields from properties when add new overlay node > > of: unittest: allow base devicetree to have symbol metadata > > of: unittest: find overlays[] entry by name instead of index > > of: unittest: initialize args before calling of_*parse_*() > > > > arch/powerpc/platforms/pseries/dlpar.c | 2 + > > drivers/of/dynamic.c | 59 - > > drivers/of/kobj.c | 4 +- > > drivers/of/overlay.c | 292 > > - > > drivers/of/unittest-data/Makefile | 2 + > > .../of/unittest-data/overlay_bad_add_dup_node.dts | 28 ++ > > .../of/unittest-data/overlay_bad_add_dup_prop.dts | 24 ++ > > drivers/of/unittest-data/overlay_base.dts | 1 + > > drivers/of/unittest.c | 96 +-- > > include/linux/of.h | 21 +- > > 10 files changed, 432 insertions(+), 97 deletions(-) > > create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_node.dts > > create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_prop.dts > > >
Re: [PATCH] ARM: socfpga: fix base address of SDR controller
On Tue, Jan 29, 2019 at 2:09 PM Simon Goldschmidt
wrote:
Hi Simon,
Thanks for submitting. A couple of things...
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index f365003f0..8f6c1a5d6 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -788,9 +788,9 @@
> reg = <0xfffec000 0x100>;
> };
>
> - sdr: sdr@ffc25000 {
> + sdr: sdr@ffc2 {
> compatible = "altr,sdr-ctl", "syscon";
> - reg = <0xffc25000 0x1000>;
> + reg = <0xffc2 0x6000>;
The binding doc will also need this change (in a separate patch)
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
> diff --git a/arch/arm/mach-socfpga/self-refresh.S
> b/arch/arm/mach-socfpga/self-refresh.S
> index f2d7f883e..bd7759357 100644
> --- a/arch/arm/mach-socfpga/self-refresh.S
> +++ b/arch/arm/mach-socfpga/self-refresh.S
> @@ -19,8 +19,8 @@
> #define MAX_LOOP_COUNT 1000
>
> /* Register offset */
> -#define SDR_CTRLGRP_LOWPWREQ_ADDR 0x54
> -#define SDR_CTRLGRP_LOWPWRACK_ADDR 0x58
> +#define SDR_CTRLGRP_LOWPWREQ_ADDR 0x5054
> +#define SDR_CTRLGRP_LOWPWRACK_ADDR 0x5058
These offsets are used for ldr/sdr and are limited to 12 bits. This
won't build if CONFIG_SOCFPGA_SUSPEND is enabled.
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:
Assembler messages:
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:65:
Error: bad immediate value for offset (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:67:
Error: bad immediate value for offset (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:72:
Error: bad immediate value for offset (20568)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:101:
Error: bad immediate value for offset (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:103:
Error: bad immediate value for offset (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:108:
Error: bad immediate value for offset (20568)
/home/atull/repos/linux-socfpga/scripts/Makefile.build:367: recipe for
target 'arch/arm/mach-socfpga/self-refresh.o' failed
Thanks,
Alan
[PATCH] fpga: stratix10-soc: fix wrong of_node_put() in init function
From: Nicolas Saenz Julienne
After finding a "firmware" dt node stratix10 tries to match it's
compatible string with it. To do so it's calling of_find_matching_node()
which already takes care of decreasing the refcount on the "firmware"
node. We are then incorrectly decreasing the refcount on that node
again.
This patch removes the unwarranted call to of_node_put().
Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
Acked-by: Moritz Fischer
[atull: remove unnecessary braces]
---
drivers/fpga/stratix10-soc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
index a1a09e04fab8..13851b3d1c56 100644
--- a/drivers/fpga/stratix10-soc.c
+++ b/drivers/fpga/stratix10-soc.c
@@ -508,14 +508,11 @@ static int __init s10_init(void)
return -ENODEV;
np = of_find_matching_node(fw_np, s10_of_match);
- if (!np) {
- of_node_put(fw_np);
+ if (!np)
return -ENODEV;
- }
of_node_put(np);
ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
- of_node_put(fw_np);
if (ret)
return ret;
--
2.20.1
Re: [PATCH 1/3] fpga: stratix10-soc: fix wrong of_node_put() in init function
On Thu, Jan 24, 2019 at 2:46 PM Alan Tull wrote:
>
> From: Nicolas Saenz Julienne
>
> After finding a "firmware" dt node stratix10 tries to match it's
> compatible string with it. To do so it's calling of_find_matching_node()
> which already takes care of decreasing the refcount on the "firmware"
> node. We are then incorrectly decreasing the refcount on that node
> again.
>
> This patch removes the unwarranted call to of_node_put().
>
> Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
> Signed-off-by: Nicolas Saenz Julienne
> Acked-by: Alan Tull
> Acked-by: Moritz Fischer
> ---
> drivers/fpga/stratix10-soc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
> index a1a09e0..e75dbe5 100644
> --- a/drivers/fpga/stratix10-soc.c
> +++ b/drivers/fpga/stratix10-soc.c
> @@ -509,13 +509,11 @@ static int __init s10_init(void)
>
> np = of_find_matching_node(fw_np, s10_of_match);
> if (!np) {
> - of_node_put(fw_np);
> return -ENODEV;
> }
This leaves unnecessary braces around a single statement. I had said
in the code review that I was going to clean that up. Arg! I'll
resubmit this patch.
Alan
>
> of_node_put(np);
> ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
> - of_node_put(fw_np);
> if (ret)
> return ret;
>
> --
> 2.7.4
>
[PATCH 3/3] fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size
From: Colin Ian King
Don't populate the const array dummy on the stack but instead
make it static. Makes the object code smaller by 26 bytes:
Before:
textdata bss dec hex filename
73712032 0940324bb drivers/fpga/altera-ps-spi.o
After:
textdata bss dec hex filename
72812096 0937724a1 drivers/fpga/altera-ps-spi.o
(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King
Acked-by: Alan Tull
Acked-by: Moritz Fischer
---
drivers/fpga/altera-ps-spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera-ps-spi.c
index 8c18bee..678d011 100644
--- a/drivers/fpga/altera-ps-spi.c
+++ b/drivers/fpga/altera-ps-spi.c
@@ -205,7 +205,7 @@ static int altera_ps_write_complete(struct fpga_manager
*mgr,
struct fpga_image_info *info)
{
struct altera_ps_conf *conf = mgr->priv;
- const char dummy[] = {0};
+ static const char dummy[] = {0};
int ret;
if (gpiod_get_value_cansleep(conf->status)) {
--
2.7.4
[PATCH 2/3] fpga: altera_freeze_bridge: remove restriction to socfpga
The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA since it can be used on other platforms such as Stratix10. Signed-off-by: Alan Tull Reviewed-by: Moritz Fischer --- drivers/fpga/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 0bb7b5c..c20445b 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -104,7 +104,7 @@ config SOCFPGA_FPGA_BRIDGE config ALTERA_FREEZE_BRIDGE tristate "Altera FPGA Freeze Bridge" - depends on ARCH_SOCFPGA && FPGA_BRIDGE + depends on FPGA_BRIDGE && HAS_IOMEM help Say Y to enable drivers for Altera FPGA Freeze bridges. A freeze bridge is a bridge that exists in the FPGA fabric to -- 2.7.4
[PATCH 0/3] patches for FPGA
Hi Greg, Please take these patches for fpga. They have been reviewed on the mailing list and apply cleanly on current linux-next. The "fpga: stratix10-soc: fix wrong of_node_put() in init function" is a bug fix, sorry it's late. It will only affect the Stratix10 platform. The other two can go in whenever is appropriate. Thanks, Alan Alan Tull (1): fpga: altera_freeze_bridge: remove restriction to socfpga Colin Ian King (1): fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size Nicolas Saenz Julienne (1): fpga: stratix10-soc: fix wrong of_node_put() in init function drivers/fpga/Kconfig | 2 +- drivers/fpga/altera-ps-spi.c | 2 +- drivers/fpga/stratix10-soc.c | 2 -- 3 files changed, 2 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH 1/3] fpga: stratix10-soc: fix wrong of_node_put() in init function
From: Nicolas Saenz Julienne
After finding a "firmware" dt node stratix10 tries to match it's
compatible string with it. To do so it's calling of_find_matching_node()
which already takes care of decreasing the refcount on the "firmware"
node. We are then incorrectly decreasing the refcount on that node
again.
This patch removes the unwarranted call to of_node_put().
Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
Acked-by: Moritz Fischer
---
drivers/fpga/stratix10-soc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
index a1a09e0..e75dbe5 100644
--- a/drivers/fpga/stratix10-soc.c
+++ b/drivers/fpga/stratix10-soc.c
@@ -509,13 +509,11 @@ static int __init s10_init(void)
np = of_find_matching_node(fw_np, s10_of_match);
if (!np) {
- of_node_put(fw_np);
return -ENODEV;
}
of_node_put(np);
ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
- of_node_put(fw_np);
if (ret)
return ret;
--
2.7.4
Re: [PATCH] fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size
On Thu, Nov 29, 2018 at 5:10 PM Colin King wrote:
Hi Colin,
Thanks!
>
> From: Colin Ian King
>
> Don't populate the const array dummy on the stack but instead
> make it static. Makes the object code smaller by 26 bytes:
>
> Before:
>textdata bss dec hex filename
>73712032 0940324bb drivers/fpga/altera-ps-spi.o
>
> After:
>textdata bss dec hex filename
>72812096 0937724a1 drivers/fpga/altera-ps-spi.o
>
> (gcc version 8.2.0 x86_64)
>
> Signed-off-by: Colin Ian King
Acked-by: Alan Tull
> ---
> drivers/fpga/altera-ps-spi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera-ps-spi.c
> index 8c18beec6b57..678d0115f840 100644
> --- a/drivers/fpga/altera-ps-spi.c
> +++ b/drivers/fpga/altera-ps-spi.c
> @@ -205,7 +205,7 @@ static int altera_ps_write_complete(struct fpga_manager
> *mgr,
> struct fpga_image_info *info)
> {
> struct altera_ps_conf *conf = mgr->priv;
> - const char dummy[] = {0};
> + static const char dummy[] = {0};
> int ret;
>
> if (gpiod_get_value_cansleep(conf->status)) {
> --
> 2.19.1
>
Re: [PATCHv1] firmware: intel_stratix10_service: add hardware dependency
On Wed, Jan 23, 2019 at 10:42 AM Dinh Nguyen wrote: > > > > On 1/23/19 10:37 AM, Alan Tull wrote: > > On Wed, Jan 23, 2019 at 10:00 AM Greg KH wrote: > > > > Hi Greg, > > > >> > >> On Wed, Jan 23, 2019 at 09:47:56AM -0600, richard.g...@linux.intel.com > >> wrote: > >>> From: Richard Gong > >>> > >>> Add a Kconfig dependency to ensure Intel Stratix10 service layer driver > >>> can be built only on the platform that supports it. > >>> > >>> Signed-off-by: Richard Gong > >>> --- > >>> drivers/firmware/Kconfig | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > >>> index f754578..cac16c4 100644 > >>> --- a/drivers/firmware/Kconfig > >>> +++ b/drivers/firmware/Kconfig > >>> @@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE > >>> > >>> config INTEL_STRATIX10_SERVICE > >>> tristate "Intel Stratix10 Service Layer" > >>> - depends on HAVE_ARM_SMCCC > >>> + depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC > >> > >> That's lame, what about building for testing? > > > > Do you mean this instead? > > > > depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST > > > >> > >> And is this needed now, for 5.0-final, or can it wait for 5.1? > > > > This change will reduce kernel size for most arm64. It can go into > > whichever kernel. We can resubmit allowing for COMPILE_TEST. > > > > I don't see how this is true? ARM64 has a single defconfig and > ARCH_STRATIX10 is included in that defconfig. I don't see how adding > this dependency will reduce the kernel size for most arm64? Sorry, I wasn't clear. By default it will be built in since there's one arm64 defconfig. But adding ARCH_STRATIX10 dependency here supports users who turn off all the ARCH_* they don't care about in their own defconfig that won't get upstreamed. > > Dinh
Re: [PATCHv1] firmware: intel_stratix10_service: add hardware dependency
On Wed, Jan 23, 2019 at 10:00 AM Greg KH wrote: Hi Greg, > > On Wed, Jan 23, 2019 at 09:47:56AM -0600, richard.g...@linux.intel.com wrote: > > From: Richard Gong > > > > Add a Kconfig dependency to ensure Intel Stratix10 service layer driver > > can be built only on the platform that supports it. > > > > Signed-off-by: Richard Gong > > --- > > drivers/firmware/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > > index f754578..cac16c4 100644 > > --- a/drivers/firmware/Kconfig > > +++ b/drivers/firmware/Kconfig > > @@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE > > > > config INTEL_STRATIX10_SERVICE > > tristate "Intel Stratix10 Service Layer" > > - depends on HAVE_ARM_SMCCC > > + depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC > > That's lame, what about building for testing? Do you mean this instead? depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST > > And is this needed now, for 5.0-final, or can it wait for 5.1? This change will reduce kernel size for most arm64. It can go into whichever kernel. We can resubmit allowing for COMPILE_TEST. > What > changed to require this? Nothing, we just didn't catch this. We're used to having our own defconfig. Not used to having a single defconfig that is shared. Thanks for the review comments, Alan > > tahnks, > > greg k-h
Re: [PATCH v3] fpga: altera_freeze_bridge: remove restriction to socfpga
On Sat, Jan 19, 2019 at 6:41 PM Moritz Fischer wrote: > > On Tue, Jan 15, 2019 at 6:01 PM Alan Tull wrote: > > > > The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA > > since it can be used on other platforms such as Stratix10. > > > > Signed-off-by: Alan Tull > Reviewed-by: Moritz Fischer Thanks! Alan > > --- > > v2: add depends on HAS_IOMEM > > v3: put both dependencies on one line > > --- > > drivers/fpga/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > index 0bb7b5c..c20445b 100644 > > --- a/drivers/fpga/Kconfig > > +++ b/drivers/fpga/Kconfig > > @@ -104,7 +104,7 @@ config SOCFPGA_FPGA_BRIDGE > > > > config ALTERA_FREEZE_BRIDGE > > tristate "Altera FPGA Freeze Bridge" > > - depends on ARCH_SOCFPGA && FPGA_BRIDGE > > + depends on FPGA_BRIDGE && HAS_IOMEM > > help > > Say Y to enable drivers for Altera FPGA Freeze bridges. A > > freeze bridge is a bridge that exists in the FPGA fabric to > > -- > > 2.7.4 > > > > Thanks, > Moritz
[PATCH v3] fpga: altera_freeze_bridge: remove restriction to socfpga
The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA since it can be used on other platforms such as Stratix10. Signed-off-by: Alan Tull --- v2: add depends on HAS_IOMEM v3: put both dependencies on one line --- drivers/fpga/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 0bb7b5c..c20445b 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -104,7 +104,7 @@ config SOCFPGA_FPGA_BRIDGE config ALTERA_FREEZE_BRIDGE tristate "Altera FPGA Freeze Bridge" - depends on ARCH_SOCFPGA && FPGA_BRIDGE + depends on FPGA_BRIDGE && HAS_IOMEM help Say Y to enable drivers for Altera FPGA Freeze bridges. A freeze bridge is a bridge that exists in the FPGA fabric to -- 2.7.4
Re: [PATCH v2] fpga: altera_freeze_bridge: remove restriction to socfpga
On Tue, Jan 15, 2019 at 11:47 AM Dinh Nguyen wrote: > > minor nit > > On 1/14/19 4:33 PM, Alan Tull wrote: > > The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA > > since it can be used on other platforms such as Stratix10. > > > > Signed-off-by: Alan Tull > > --- > > drivers/fpga/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > index 0bb7b5c..da5786a 100644 > > --- a/drivers/fpga/Kconfig > > +++ b/drivers/fpga/Kconfig > > @@ -104,7 +104,8 @@ config SOCFPGA_FPGA_BRIDGE > > > > config ALTERA_FREEZE_BRIDGE > > tristate "Altera FPGA Freeze Bridge" > > - depends on ARCH_SOCFPGA && FPGA_BRIDGE > > + depends on FPGA_BRIDGE > > + depends on HAS_IOMEM > > can just be: > > depends on FPGA_BRIDGE && HAS_IOMEM I agree. > > Dinh
[PATCH v2] fpga: altera_freeze_bridge: remove restriction to socfpga
The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA since it can be used on other platforms such as Stratix10. Signed-off-by: Alan Tull --- drivers/fpga/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 0bb7b5c..da5786a 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -104,7 +104,8 @@ config SOCFPGA_FPGA_BRIDGE config ALTERA_FREEZE_BRIDGE tristate "Altera FPGA Freeze Bridge" - depends on ARCH_SOCFPGA && FPGA_BRIDGE + depends on FPGA_BRIDGE + depends on HAS_IOMEM help Say Y to enable drivers for Altera FPGA Freeze bridges. A freeze bridge is a bridge that exists in the FPGA fabric to -- 2.7.4
Re: [PATCH] fpga: altera_freeze_bridge: remove restriction to socfpga
On Fri, Jan 11, 2019 at 12:42 PM Moritz Fischer wrote: Hi Moritz, > > Hi Alan, > > On Thu, Jan 10, 2019 at 3:06 PM Alan Tull wrote: > > > > The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA > > since it can be used on other platforms such as Stratix10. > > > > Signed-off-by: Alan Tull > > --- > > drivers/fpga/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > index 0bb7b5c..0bdbd3d 100644 > > --- a/drivers/fpga/Kconfig > > +++ b/drivers/fpga/Kconfig > > @@ -104,7 +104,7 @@ config SOCFPGA_FPGA_BRIDGE > > > > config ALTERA_FREEZE_BRIDGE > > tristate "Altera FPGA Freeze Bridge" > > - depends on ARCH_SOCFPGA && FPGA_BRIDGE > > + depends on FPGA_BRIDGE > > Doesn't that need a dependency on HAS_IOMEM at least, then? Right you are! Thanks! Alan > > help > > Say Y to enable drivers for Altera FPGA Freeze bridges. A > > freeze bridge is a bridge that exists in the FPGA fabric to > > -- > > 2.7.4 > > > > Thanks, > Moritz
[PATCH] fpga: altera_freeze_bridge: remove restriction to socfpga
The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA since it can be used on other platforms such as Stratix10. Signed-off-by: Alan Tull --- drivers/fpga/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 0bb7b5c..0bdbd3d 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -104,7 +104,7 @@ config SOCFPGA_FPGA_BRIDGE config ALTERA_FREEZE_BRIDGE tristate "Altera FPGA Freeze Bridge" - depends on ARCH_SOCFPGA && FPGA_BRIDGE + depends on FPGA_BRIDGE help Say Y to enable drivers for Altera FPGA Freeze bridges. A freeze bridge is a bridge that exists in the FPGA fabric to -- 2.7.4
Re: [PATCH] fpga: stratix10-soc: fix wrong of_node_put() in init function
On Mon, Dec 3, 2018 at 6:22 AM Nicolas Saenz Julienne
wrote:
Hi Nicolas,
Thanks for catching this! I'll fix up one formatting thing (below).
>
> After finding a "firmware" dt node stratix10 tries to match it's
> compatible string with it. To do so it's calling of_find_matching_node()
> which already takes care of decreasing the refcount on the "firmware"
> node. We are then incorrectly decreasing the refcount on that node
> again.
>
> This patch removes the unwarranted call to of_node_put().
>
> Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
> Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
> ---
> drivers/fpga/stratix10-soc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
> index a1a09e04fab8..e75dbe583152 100644
> --- a/drivers/fpga/stratix10-soc.c
> +++ b/drivers/fpga/stratix10-soc.c
> @@ -509,13 +509,11 @@ static int __init s10_init(void)
>
> np = of_find_matching_node(fw_np, s10_of_match);
> if (!np) {
> - of_node_put(fw_np);
> return -ENODEV;
> }
We don't need the brackets anymore around the return statement. I'll fix it up.
Thanks,
Alan
>
> of_node_put(np);
> ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
> - of_node_put(fw_np);
> if (ret)
> return ret;
>
> --
> 2.19.2
>
Re: [PATCH] fpga: stratix10-soc: fix wrong of_node_put() in init function
On Mon, Dec 3, 2018 at 6:22 AM Nicolas Saenz Julienne
wrote:
Hi Nicolas,
Thanks for catching this! I'll fix up one formatting thing (below).
>
> After finding a "firmware" dt node stratix10 tries to match it's
> compatible string with it. To do so it's calling of_find_matching_node()
> which already takes care of decreasing the refcount on the "firmware"
> node. We are then incorrectly decreasing the refcount on that node
> again.
>
> This patch removes the unwarranted call to of_node_put().
>
> Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
> Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
> ---
> drivers/fpga/stratix10-soc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
> index a1a09e04fab8..e75dbe583152 100644
> --- a/drivers/fpga/stratix10-soc.c
> +++ b/drivers/fpga/stratix10-soc.c
> @@ -509,13 +509,11 @@ static int __init s10_init(void)
>
> np = of_find_matching_node(fw_np, s10_of_match);
> if (!np) {
> - of_node_put(fw_np);
> return -ENODEV;
> }
We don't need the brackets anymore around the return statement. I'll fix it up.
Thanks,
Alan
>
> of_node_put(np);
> ret = of_platform_populate(fw_np, s10_of_match, NULL, NULL);
> - of_node_put(fw_np);
> if (ret)
> return ret;
>
> --
> 2.19.2
>
[PATCH 1/2] fpga: altera-cvp: fix probing for multiple FPGAs on the bus
From: Anatolij Gustschin
Currently registering CvP managers works only for first probed CvP
device, for all other devices it is refused due to duplicated chkcfg
sysfs entry:
fpga_manager fpga3: Altera CvP FPGA Manager @:0c:00.0 registered
sysfs: cannot create duplicate filename '/bus/pci/drivers/altera-cvp/chkcfg'
CPU: 0 PID: 3808 Comm: bash Tainted: G O 4.19.0-custom+ #5
Call Trace:
dump_stack+0x46/0x5b
sysfs_warn_dup+0x53/0x60
sysfs_add_file_mode_ns+0x16d/0x180
sysfs_create_file_ns+0x51/0x60
altera_cvp_probe+0x16f/0x2a0 [altera_cvp]
local_pci_probe+0x3f/0xa0
? pci_match_device+0xb1/0xf0
pci_device_probe+0x116/0x170
really_probe+0x21b/0x2c0
driver_probe_device+0x4b/0xe0
bind_store+0xcb/0x130
kernfs_fop_write+0xfd/0x180
__vfs_write+0x21/0x150
? selinux_file_permission+0xdc/0x130
vfs_write+0xa8/0x1a0
? find_vma+0xd/0x60
ksys_write+0x3d/0x90
do_syscall_64+0x44/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
altera-cvp :0c:00.0: Can't create sysfs chkcfg file
fpga_manager fpga3: fpga_mgr_unregister Altera CvP FPGA Manager @:0c:00.0
Move chkcfg creation to module init as suggested by Alan.
Signed-off-by: Anatolij Gustschin
Acked-by: Alan Tull
---
drivers/fpga/altera-cvp.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 7395085..35c3aa5 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -475,14 +475,6 @@ static int altera_cvp_probe(struct pci_dev *pdev,
if (ret)
goto err_unmap;
- ret = driver_create_file(_cvp_driver.driver,
-_attr_chkcfg);
- if (ret) {
- dev_err(>dev, "Can't create sysfs chkcfg file\n");
- fpga_mgr_unregister(mgr);
- goto err_unmap;
- }
-
return 0;
err_unmap:
@@ -501,7 +493,6 @@ static void altera_cvp_remove(struct pci_dev *pdev)
struct altera_cvp_conf *conf = mgr->priv;
u16 cmd;
- driver_remove_file(_cvp_driver.driver, _attr_chkcfg);
fpga_mgr_unregister(mgr);
if (conf->map)
pci_iounmap(pdev, conf->map);
@@ -511,7 +502,30 @@ static void altera_cvp_remove(struct pci_dev *pdev)
pci_write_config_word(pdev, PCI_COMMAND, cmd);
}
-module_pci_driver(altera_cvp_driver);
+static int __init altera_cvp_init(void)
+{
+ int ret;
+
+ ret = pci_register_driver(_cvp_driver);
+ if (ret)
+ return ret;
+
+ ret = driver_create_file(_cvp_driver.driver,
+_attr_chkcfg);
+ if (ret)
+ pr_warn("Can't create sysfs chkcfg file\n");
+
+ return 0;
+}
+
+static void __exit altera_cvp_exit(void)
+{
+ driver_remove_file(_cvp_driver.driver, _attr_chkcfg);
+ pci_unregister_driver(_cvp_driver);
+}
+
+module_init(altera_cvp_init);
+module_exit(altera_cvp_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Anatolij Gustschin ");
--
2.7.4
[PATCH 2/2] fpga: mgr: altera-ps-spi: enable usage on non-dt platforms
From: Anatolij Gustschin
Driver probing fails on non-dt platforms since of_match_device()
always returns NULL here. Add spi ids with device names and
matching driver data as an index of a map array with data for
supported devices. Add this map array and a function for mapping
spi ids to driver data. This allows driver binding to dynamically
added PS-SPI devices (e.g. when added via spi_new_device() after
hot-plugging).
Signed-off-by: Anatolij Gustschin
Acked-by: Alan Tull
---
drivers/fpga/altera-ps-spi.c | 40 +++-
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera-ps-spi.c
index 33aafda..8c18bee 100644
--- a/drivers/fpga/altera-ps-spi.c
+++ b/drivers/fpga/altera-ps-spi.c
@@ -75,6 +75,12 @@ static struct altera_ps_data a10_data = {
.t_st2ck_us = 10, /* min(t_ST2CK) */
};
+/* Array index is enum altera_ps_devtype */
+static const struct altera_ps_data *altera_ps_data_map[] = {
+ _data,
+ _data,
+};
+
static const struct of_device_id of_ef_match[] = {
{ .compatible = "altr,fpga-passive-serial", .data = _data },
{ .compatible = "altr,fpga-arria10-passive-serial", .data = _data },
@@ -234,6 +240,22 @@ static const struct fpga_manager_ops altera_ps_ops = {
.write_complete = altera_ps_write_complete,
};
+static const struct altera_ps_data *id_to_data(const struct spi_device_id *id)
+{
+ kernel_ulong_t devtype = id->driver_data;
+ const struct altera_ps_data *data;
+
+ /* someone added a altera_ps_devtype without adding to the map array */
+ if (devtype >= ARRAY_SIZE(altera_ps_data_map))
+ return NULL;
+
+ data = altera_ps_data_map[devtype];
+ if (!data || data->devtype != devtype)
+ return NULL;
+
+ return data;
+}
+
static int altera_ps_probe(struct spi_device *spi)
{
struct altera_ps_conf *conf;
@@ -244,11 +266,17 @@ static int altera_ps_probe(struct spi_device *spi)
if (!conf)
return -ENOMEM;
- of_id = of_match_device(of_ef_match, >dev);
- if (!of_id)
- return -ENODEV;
+ if (spi->dev.of_node) {
+ of_id = of_match_device(of_ef_match, >dev);
+ if (!of_id)
+ return -ENODEV;
+ conf->data = of_id->data;
+ } else {
+ conf->data = id_to_data(spi_get_device_id(spi));
+ if (!conf->data)
+ return -ENODEV;
+ }
- conf->data = of_id->data;
conf->spi = spi;
conf->config = devm_gpiod_get(>dev, "nconfig", GPIOD_OUT_LOW);
if (IS_ERR(conf->config)) {
@@ -294,7 +322,9 @@ static int altera_ps_remove(struct spi_device *spi)
}
static const struct spi_device_id altera_ps_spi_ids[] = {
- {"cyclone-ps-spi", 0},
+ { "cyclone-ps-spi", CYCLONE5 },
+ { "fpga-passive-serial", CYCLONE5 },
+ { "fpga-arria10-passive-serial", ARRIA10 },
{}
};
MODULE_DEVICE_TABLE(spi, altera_ps_spi_ids);
--
2.7.4
[PATCH 0/2] patches for FPGA
Hi Greg, Please take these two fpga fixes patches. They have been reviewed on the mailing list and apply cleanly on current linux-next. Thanks, Alan Anatolij Gustschin (2): fpga: altera-cvp: fix probing for multiple FPGAs on the bus fpga: mgr: altera-ps-spi: enable usage on non-dt platforms drivers/fpga/altera-cvp.c| 34 -- drivers/fpga/altera-ps-spi.c | 40 +++- 2 files changed, 59 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH 1/2] fpga: altera-cvp: fix probing for multiple FPGAs on the bus
From: Anatolij Gustschin
Currently registering CvP managers works only for first probed CvP
device, for all other devices it is refused due to duplicated chkcfg
sysfs entry:
fpga_manager fpga3: Altera CvP FPGA Manager @:0c:00.0 registered
sysfs: cannot create duplicate filename '/bus/pci/drivers/altera-cvp/chkcfg'
CPU: 0 PID: 3808 Comm: bash Tainted: G O 4.19.0-custom+ #5
Call Trace:
dump_stack+0x46/0x5b
sysfs_warn_dup+0x53/0x60
sysfs_add_file_mode_ns+0x16d/0x180
sysfs_create_file_ns+0x51/0x60
altera_cvp_probe+0x16f/0x2a0 [altera_cvp]
local_pci_probe+0x3f/0xa0
? pci_match_device+0xb1/0xf0
pci_device_probe+0x116/0x170
really_probe+0x21b/0x2c0
driver_probe_device+0x4b/0xe0
bind_store+0xcb/0x130
kernfs_fop_write+0xfd/0x180
__vfs_write+0x21/0x150
? selinux_file_permission+0xdc/0x130
vfs_write+0xa8/0x1a0
? find_vma+0xd/0x60
ksys_write+0x3d/0x90
do_syscall_64+0x44/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
altera-cvp :0c:00.0: Can't create sysfs chkcfg file
fpga_manager fpga3: fpga_mgr_unregister Altera CvP FPGA Manager @:0c:00.0
Move chkcfg creation to module init as suggested by Alan.
Signed-off-by: Anatolij Gustschin
Acked-by: Alan Tull
---
drivers/fpga/altera-cvp.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 7395085..35c3aa5 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -475,14 +475,6 @@ static int altera_cvp_probe(struct pci_dev *pdev,
if (ret)
goto err_unmap;
- ret = driver_create_file(_cvp_driver.driver,
-_attr_chkcfg);
- if (ret) {
- dev_err(>dev, "Can't create sysfs chkcfg file\n");
- fpga_mgr_unregister(mgr);
- goto err_unmap;
- }
-
return 0;
err_unmap:
@@ -501,7 +493,6 @@ static void altera_cvp_remove(struct pci_dev *pdev)
struct altera_cvp_conf *conf = mgr->priv;
u16 cmd;
- driver_remove_file(_cvp_driver.driver, _attr_chkcfg);
fpga_mgr_unregister(mgr);
if (conf->map)
pci_iounmap(pdev, conf->map);
@@ -511,7 +502,30 @@ static void altera_cvp_remove(struct pci_dev *pdev)
pci_write_config_word(pdev, PCI_COMMAND, cmd);
}
-module_pci_driver(altera_cvp_driver);
+static int __init altera_cvp_init(void)
+{
+ int ret;
+
+ ret = pci_register_driver(_cvp_driver);
+ if (ret)
+ return ret;
+
+ ret = driver_create_file(_cvp_driver.driver,
+_attr_chkcfg);
+ if (ret)
+ pr_warn("Can't create sysfs chkcfg file\n");
+
+ return 0;
+}
+
+static void __exit altera_cvp_exit(void)
+{
+ driver_remove_file(_cvp_driver.driver, _attr_chkcfg);
+ pci_unregister_driver(_cvp_driver);
+}
+
+module_init(altera_cvp_init);
+module_exit(altera_cvp_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Anatolij Gustschin ");
--
2.7.4
[PATCH 2/2] fpga: mgr: altera-ps-spi: enable usage on non-dt platforms
From: Anatolij Gustschin
Driver probing fails on non-dt platforms since of_match_device()
always returns NULL here. Add spi ids with device names and
matching driver data as an index of a map array with data for
supported devices. Add this map array and a function for mapping
spi ids to driver data. This allows driver binding to dynamically
added PS-SPI devices (e.g. when added via spi_new_device() after
hot-plugging).
Signed-off-by: Anatolij Gustschin
Acked-by: Alan Tull
---
drivers/fpga/altera-ps-spi.c | 40 +++-
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera-ps-spi.c
index 33aafda..8c18bee 100644
--- a/drivers/fpga/altera-ps-spi.c
+++ b/drivers/fpga/altera-ps-spi.c
@@ -75,6 +75,12 @@ static struct altera_ps_data a10_data = {
.t_st2ck_us = 10, /* min(t_ST2CK) */
};
+/* Array index is enum altera_ps_devtype */
+static const struct altera_ps_data *altera_ps_data_map[] = {
+ _data,
+ _data,
+};
+
static const struct of_device_id of_ef_match[] = {
{ .compatible = "altr,fpga-passive-serial", .data = _data },
{ .compatible = "altr,fpga-arria10-passive-serial", .data = _data },
@@ -234,6 +240,22 @@ static const struct fpga_manager_ops altera_ps_ops = {
.write_complete = altera_ps_write_complete,
};
+static const struct altera_ps_data *id_to_data(const struct spi_device_id *id)
+{
+ kernel_ulong_t devtype = id->driver_data;
+ const struct altera_ps_data *data;
+
+ /* someone added a altera_ps_devtype without adding to the map array */
+ if (devtype >= ARRAY_SIZE(altera_ps_data_map))
+ return NULL;
+
+ data = altera_ps_data_map[devtype];
+ if (!data || data->devtype != devtype)
+ return NULL;
+
+ return data;
+}
+
static int altera_ps_probe(struct spi_device *spi)
{
struct altera_ps_conf *conf;
@@ -244,11 +266,17 @@ static int altera_ps_probe(struct spi_device *spi)
if (!conf)
return -ENOMEM;
- of_id = of_match_device(of_ef_match, >dev);
- if (!of_id)
- return -ENODEV;
+ if (spi->dev.of_node) {
+ of_id = of_match_device(of_ef_match, >dev);
+ if (!of_id)
+ return -ENODEV;
+ conf->data = of_id->data;
+ } else {
+ conf->data = id_to_data(spi_get_device_id(spi));
+ if (!conf->data)
+ return -ENODEV;
+ }
- conf->data = of_id->data;
conf->spi = spi;
conf->config = devm_gpiod_get(>dev, "nconfig", GPIOD_OUT_LOW);
if (IS_ERR(conf->config)) {
@@ -294,7 +322,9 @@ static int altera_ps_remove(struct spi_device *spi)
}
static const struct spi_device_id altera_ps_spi_ids[] = {
- {"cyclone-ps-spi", 0},
+ { "cyclone-ps-spi", CYCLONE5 },
+ { "fpga-passive-serial", CYCLONE5 },
+ { "fpga-arria10-passive-serial", ARRIA10 },
{}
};
MODULE_DEVICE_TABLE(spi, altera_ps_spi_ids);
--
2.7.4
[PATCH 0/2] patches for FPGA
Hi Greg, Please take these two fpga fixes patches. They have been reviewed on the mailing list and apply cleanly on current linux-next. Thanks, Alan Anatolij Gustschin (2): fpga: altera-cvp: fix probing for multiple FPGAs on the bus fpga: mgr: altera-ps-spi: enable usage on non-dt platforms drivers/fpga/altera-cvp.c| 34 -- drivers/fpga/altera-ps-spi.c | 40 +++- 2 files changed, 59 insertions(+), 15 deletions(-) -- 2.7.4
Re: [PATCH 5/5] fpga: dfl-fme-region: Use platform_get_drvdata()
On Mon, Nov 12, 2018 at 12:02 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Nov 12, 2018 at 09:46:53AM -0600, Alan Tull wrote:
> > On Sun, Sep 30, 2018 at 10:48 AM Greg Kroah-Hartman
> > wrote:
> >
> > Hi Greg,
> >
> > >
> > > On Wed, Sep 12, 2018 at 09:43:27AM -0500, Alan Tull wrote:
> > > > From: Moritz Fischer
> > > >
> > > > Use platform_get_drvdata() in remove() function of
> > > > the platform driver rather than dev_get_drvdata()
> > > > to match the platform_set_drvdata in the probe().
> > > >
> > > > Signed-off-by: Moritz Fischer
> > > > Acked-by: Alan Tull
> > > > ---
> > > > drivers/fpga/dfl-fme-region.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/fpga/dfl-fme-region.c
> > > > b/drivers/fpga/dfl-fme-region.c
> > > > index 51a5ac2..3fa0de2 100644
> > > > --- a/drivers/fpga/dfl-fme-region.c
> > > > +++ b/drivers/fpga/dfl-fme-region.c
> > > > @@ -66,7 +66,7 @@ static int fme_region_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > static int fme_region_remove(struct platform_device *pdev)
> > > > {
> > > > - struct fpga_region *region = dev_get_drvdata(>dev);
> > > > + struct fpga_region *region = platform_get_drvdata(pdev);
> > >
> > > This is nice, but not a bugfix. I'll wait for 4.20-rc1 for this patch.
> >
> > Could you take patch 4/5 and 5/5? They didn't make it into a 4.20 rc yet.
>
> Can you resend them please? I don't see either of these in my queue
> anywhere.
>
> thanks,
>
> greg k-h
Sure! Just sent them.
Thanks,
Alan
Re: [PATCH 5/5] fpga: dfl-fme-region: Use platform_get_drvdata()
On Mon, Nov 12, 2018 at 12:02 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Nov 12, 2018 at 09:46:53AM -0600, Alan Tull wrote:
> > On Sun, Sep 30, 2018 at 10:48 AM Greg Kroah-Hartman
> > wrote:
> >
> > Hi Greg,
> >
> > >
> > > On Wed, Sep 12, 2018 at 09:43:27AM -0500, Alan Tull wrote:
> > > > From: Moritz Fischer
> > > >
> > > > Use platform_get_drvdata() in remove() function of
> > > > the platform driver rather than dev_get_drvdata()
> > > > to match the platform_set_drvdata in the probe().
> > > >
> > > > Signed-off-by: Moritz Fischer
> > > > Acked-by: Alan Tull
> > > > ---
> > > > drivers/fpga/dfl-fme-region.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/fpga/dfl-fme-region.c
> > > > b/drivers/fpga/dfl-fme-region.c
> > > > index 51a5ac2..3fa0de2 100644
> > > > --- a/drivers/fpga/dfl-fme-region.c
> > > > +++ b/drivers/fpga/dfl-fme-region.c
> > > > @@ -66,7 +66,7 @@ static int fme_region_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > static int fme_region_remove(struct platform_device *pdev)
> > > > {
> > > > - struct fpga_region *region = dev_get_drvdata(>dev);
> > > > + struct fpga_region *region = platform_get_drvdata(pdev);
> > >
> > > This is nice, but not a bugfix. I'll wait for 4.20-rc1 for this patch.
> >
> > Could you take patch 4/5 and 5/5? They didn't make it into a 4.20 rc yet.
>
> Can you resend them please? I don't see either of these in my queue
> anywhere.
>
> thanks,
>
> greg k-h
Sure! Just sent them.
Thanks,
Alan
[RESEND 1/2] fpga: of-fpga-region: Use platform_set_drvdata
From: Moritz Fischer Use platform_set_drvdata rather than dev_set_drvdata to match the platform_get_drvdata in the _remove() function of the platform driver. Signed-off-by: Moritz Fischer Acked-by: Alan Tull --- drivers/fpga/of-fpga-region.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index 122286f..75f64ab 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -421,7 +421,7 @@ static int of_fpga_region_probe(struct platform_device *pdev) goto eprobe_mgr_put; of_platform_populate(np, fpga_region_of_match, NULL, >dev); - dev_set_drvdata(dev, region); + platform_set_drvdata(pdev, region); dev_info(dev, "FPGA Region probed\n"); -- 2.7.4
[RESEND 1/2] fpga: of-fpga-region: Use platform_set_drvdata
From: Moritz Fischer Use platform_set_drvdata rather than dev_set_drvdata to match the platform_get_drvdata in the _remove() function of the platform driver. Signed-off-by: Moritz Fischer Acked-by: Alan Tull --- drivers/fpga/of-fpga-region.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index 122286f..75f64ab 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -421,7 +421,7 @@ static int of_fpga_region_probe(struct platform_device *pdev) goto eprobe_mgr_put; of_platform_populate(np, fpga_region_of_match, NULL, >dev); - dev_set_drvdata(dev, region); + platform_set_drvdata(pdev, region); dev_info(dev, "FPGA Region probed\n"); -- 2.7.4
[RESEND 2/2] fpga: dfl-fme-region: Use platform_get_drvdata()
From: Moritz Fischer
Use platform_get_drvdata() in remove() function of
the platform driver rather than dev_get_drvdata()
to match the platform_set_drvdata in the probe().
Signed-off-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/dfl-fme-region.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
index ec134ec..1eeb42a 100644
--- a/drivers/fpga/dfl-fme-region.c
+++ b/drivers/fpga/dfl-fme-region.c
@@ -64,7 +64,7 @@ static int fme_region_probe(struct platform_device *pdev)
static int fme_region_remove(struct platform_device *pdev)
{
- struct fpga_region *region = dev_get_drvdata(>dev);
+ struct fpga_region *region = platform_get_drvdata(pdev);
struct fpga_manager *mgr = region->mgr;
fpga_region_unregister(region);
--
2.7.4
[RESEND 0/2] fpga fixes for 4.20
Hi Greg, Here's a reposting of the two small fixes for fpga, please take them in. They've been reviewed on the mailing list and apply cleanly on today's char-misc-test. Thanks, Alan Moritz Fischer (2): fpga: of-fpga-region: Use platform_set_drvdata fpga: dfl-fme-region: Use platform_get_drvdata() drivers/fpga/dfl-fme-region.c | 2 +- drivers/fpga/of-fpga-region.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.7.4
[RESEND 2/2] fpga: dfl-fme-region: Use platform_get_drvdata()
From: Moritz Fischer
Use platform_get_drvdata() in remove() function of
the platform driver rather than dev_get_drvdata()
to match the platform_set_drvdata in the probe().
Signed-off-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/dfl-fme-region.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
index ec134ec..1eeb42a 100644
--- a/drivers/fpga/dfl-fme-region.c
+++ b/drivers/fpga/dfl-fme-region.c
@@ -64,7 +64,7 @@ static int fme_region_probe(struct platform_device *pdev)
static int fme_region_remove(struct platform_device *pdev)
{
- struct fpga_region *region = dev_get_drvdata(>dev);
+ struct fpga_region *region = platform_get_drvdata(pdev);
struct fpga_manager *mgr = region->mgr;
fpga_region_unregister(region);
--
2.7.4
[RESEND 0/2] fpga fixes for 4.20
Hi Greg, Here's a reposting of the two small fixes for fpga, please take them in. They've been reviewed on the mailing list and apply cleanly on today's char-misc-test. Thanks, Alan Moritz Fischer (2): fpga: of-fpga-region: Use platform_set_drvdata fpga: dfl-fme-region: Use platform_get_drvdata() drivers/fpga/dfl-fme-region.c | 2 +- drivers/fpga/of-fpga-region.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.7.4
Re: [PATCH 4/5] fpga: of-fpga-region: Use platform_set_drvdata
On Sun, Sep 30, 2018 at 10:49 AM Greg Kroah-Hartman wrote: Hi Greg, > > On Wed, Sep 12, 2018 at 09:43:26AM -0500, Alan Tull wrote: > > From: Moritz Fischer > > > > Use platform_set_drvdata rather than dev_set_drvdata > > to match the platform_get_drvdata in the _remove() > > function of the platform driver. > > > > Signed-off-by: Moritz Fischer > > Acked-by: Alan Tull > > --- > > drivers/fpga/of-fpga-region.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c > > index 052a134..d6a70e4 100644 > > --- a/drivers/fpga/of-fpga-region.c > > +++ b/drivers/fpga/of-fpga-region.c > > @@ -421,7 +421,7 @@ static int of_fpga_region_probe(struct platform_device > > *pdev) > > goto eprobe_free; > > > > of_platform_populate(np, fpga_region_of_match, NULL, >dev); > > - dev_set_drvdata(dev, region); > > + platform_set_drvdata(pdev, region); > > Again, not really a bugfix :) Could you take this patch 4/5 (just sent a reminder for 5/5)? Thanks Alan
Re: [PATCH 4/5] fpga: of-fpga-region: Use platform_set_drvdata
On Sun, Sep 30, 2018 at 10:49 AM Greg Kroah-Hartman wrote: Hi Greg, > > On Wed, Sep 12, 2018 at 09:43:26AM -0500, Alan Tull wrote: > > From: Moritz Fischer > > > > Use platform_set_drvdata rather than dev_set_drvdata > > to match the platform_get_drvdata in the _remove() > > function of the platform driver. > > > > Signed-off-by: Moritz Fischer > > Acked-by: Alan Tull > > --- > > drivers/fpga/of-fpga-region.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c > > index 052a134..d6a70e4 100644 > > --- a/drivers/fpga/of-fpga-region.c > > +++ b/drivers/fpga/of-fpga-region.c > > @@ -421,7 +421,7 @@ static int of_fpga_region_probe(struct platform_device > > *pdev) > > goto eprobe_free; > > > > of_platform_populate(np, fpga_region_of_match, NULL, >dev); > > - dev_set_drvdata(dev, region); > > + platform_set_drvdata(pdev, region); > > Again, not really a bugfix :) Could you take this patch 4/5 (just sent a reminder for 5/5)? Thanks Alan
Re: [PATCH 5/5] fpga: dfl-fme-region: Use platform_get_drvdata()
On Sun, Sep 30, 2018 at 10:48 AM Greg Kroah-Hartman
wrote:
Hi Greg,
>
> On Wed, Sep 12, 2018 at 09:43:27AM -0500, Alan Tull wrote:
> > From: Moritz Fischer
> >
> > Use platform_get_drvdata() in remove() function of
> > the platform driver rather than dev_get_drvdata()
> > to match the platform_set_drvdata in the probe().
> >
> > Signed-off-by: Moritz Fischer
> > Acked-by: Alan Tull
> > ---
> > drivers/fpga/dfl-fme-region.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> > index 51a5ac2..3fa0de2 100644
> > --- a/drivers/fpga/dfl-fme-region.c
> > +++ b/drivers/fpga/dfl-fme-region.c
> > @@ -66,7 +66,7 @@ static int fme_region_probe(struct platform_device *pdev)
> >
> > static int fme_region_remove(struct platform_device *pdev)
> > {
> > - struct fpga_region *region = dev_get_drvdata(>dev);
> > + struct fpga_region *region = platform_get_drvdata(pdev);
>
> This is nice, but not a bugfix. I'll wait for 4.20-rc1 for this patch.
Could you take patch 4/5 and 5/5? They didn't make it into a 4.20 rc yet.
Alan
>
> thanks,
>
> greg k-h
Re: [PATCH 5/5] fpga: dfl-fme-region: Use platform_get_drvdata()
On Sun, Sep 30, 2018 at 10:48 AM Greg Kroah-Hartman
wrote:
Hi Greg,
>
> On Wed, Sep 12, 2018 at 09:43:27AM -0500, Alan Tull wrote:
> > From: Moritz Fischer
> >
> > Use platform_get_drvdata() in remove() function of
> > the platform driver rather than dev_get_drvdata()
> > to match the platform_set_drvdata in the probe().
> >
> > Signed-off-by: Moritz Fischer
> > Acked-by: Alan Tull
> > ---
> > drivers/fpga/dfl-fme-region.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> > index 51a5ac2..3fa0de2 100644
> > --- a/drivers/fpga/dfl-fme-region.c
> > +++ b/drivers/fpga/dfl-fme-region.c
> > @@ -66,7 +66,7 @@ static int fme_region_probe(struct platform_device *pdev)
> >
> > static int fme_region_remove(struct platform_device *pdev)
> > {
> > - struct fpga_region *region = dev_get_drvdata(>dev);
> > + struct fpga_region *region = platform_get_drvdata(pdev);
>
> This is nice, but not a bugfix. I'll wait for 4.20-rc1 for this patch.
Could you take patch 4/5 and 5/5? They didn't make it into a 4.20 rc yet.
Alan
>
> thanks,
>
> greg k-h
[PATCH 2/4] fpga: dfl: fme: remove set but not used variable 'priv'
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/fpga/dfl-fme-pr.c: In function 'pr_mgmt_uinit':
drivers/fpga/dfl-fme-pr.c:447:18: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
Acked-by: Moritz Fischer
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl-fme-pr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl-fme-pr.c
index 0b84053..fe5a557 100644
--- a/drivers/fpga/dfl-fme-pr.c
+++ b/drivers/fpga/dfl-fme-pr.c
@@ -444,10 +444,8 @@ static void pr_mgmt_uinit(struct platform_device *pdev,
struct dfl_feature *feature)
{
struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
- struct dfl_fme *priv;
mutex_lock(>lock);
- priv = dfl_fpga_pdata_get_private(pdata);
dfl_fme_destroy_regions(pdata);
dfl_fme_destroy_bridges(pdata);
--
2.7.4
[PATCH 2/4] fpga: dfl: fme: remove set but not used variable 'priv'
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/fpga/dfl-fme-pr.c: In function 'pr_mgmt_uinit':
drivers/fpga/dfl-fme-pr.c:447:18: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
Acked-by: Moritz Fischer
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl-fme-pr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl-fme-pr.c
index 0b84053..fe5a557 100644
--- a/drivers/fpga/dfl-fme-pr.c
+++ b/drivers/fpga/dfl-fme-pr.c
@@ -444,10 +444,8 @@ static void pr_mgmt_uinit(struct platform_device *pdev,
struct dfl_feature *feature)
{
struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
- struct dfl_fme *priv;
mutex_lock(>lock);
- priv = dfl_fpga_pdata_get_private(pdata);
dfl_fme_destroy_regions(pdata);
dfl_fme_destroy_bridges(pdata);
--
2.7.4
[PATCH 4/4] zynq-fpga: Only route PR via PCAP when required
From: Mike Looijmans The Xilinx Zynq FPGA driver takes ownership of the PR interface, making it impossible to use the ICAP interface for partial reconfiguration. This patch changes the driver to only activate PR over PCAP while the device is actively being accessed by the driver for programming. This allows both PCAP and ICAP interfaces to be used for PR. Signed-off-by: Mike Looijmans Reviewed-by: Moritz Fischer Acked-by: Alan Tull --- drivers/fpga/zynq-fpga.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c index bb82efe..57b0e67 100644 --- a/drivers/fpga/zynq-fpga.c +++ b/drivers/fpga/zynq-fpga.c @@ -501,6 +501,10 @@ static int zynq_fpga_ops_write_complete(struct fpga_manager *mgr, if (err) return err; + /* Release 'PR' control back to the ICAP */ + zynq_fpga_write(priv, CTRL_OFFSET, + zynq_fpga_read(priv, CTRL_OFFSET) & ~CTRL_PCAP_PR_MASK); + err = zynq_fpga_poll_timeout(priv, INT_STS_OFFSET, intr_status, intr_status & IXR_PCFG_DONE_MASK, INIT_POLL_DELAY, -- 2.7.4
[PATCH 4/4] zynq-fpga: Only route PR via PCAP when required
From: Mike Looijmans The Xilinx Zynq FPGA driver takes ownership of the PR interface, making it impossible to use the ICAP interface for partial reconfiguration. This patch changes the driver to only activate PR over PCAP while the device is actively being accessed by the driver for programming. This allows both PCAP and ICAP interfaces to be used for PR. Signed-off-by: Mike Looijmans Reviewed-by: Moritz Fischer Acked-by: Alan Tull --- drivers/fpga/zynq-fpga.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c index bb82efe..57b0e67 100644 --- a/drivers/fpga/zynq-fpga.c +++ b/drivers/fpga/zynq-fpga.c @@ -501,6 +501,10 @@ static int zynq_fpga_ops_write_complete(struct fpga_manager *mgr, if (err) return err; + /* Release 'PR' control back to the ICAP */ + zynq_fpga_write(priv, CTRL_OFFSET, + zynq_fpga_read(priv, CTRL_OFFSET) & ~CTRL_PCAP_PR_MASK); + err = zynq_fpga_poll_timeout(priv, INT_STS_OFFSET, intr_status, intr_status & IXR_PCFG_DONE_MASK, INIT_POLL_DELAY, -- 2.7.4
[PATCH 1/4] fpga: altera-cvp: fix 'bad IO access' on x86_64
From: Anatolij Gustschin If mapping the CvP BAR fails, we still can configure the FPGA via PCI config space access. In this case the iomap pointer is NULL. On x86_64, passing NULL address to pci_iounmap() generates "Bad IO access at port 0x0" output with stack call trace. Fix it. Signed-off-by: Anatolij Gustschin Acked-by: Alan Tull --- drivers/fpga/altera-cvp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c index 610a155..144fa2a 100644 --- a/drivers/fpga/altera-cvp.c +++ b/drivers/fpga/altera-cvp.c @@ -477,7 +477,8 @@ static int altera_cvp_probe(struct pci_dev *pdev, return 0; err_unmap: - pci_iounmap(pdev, conf->map); + if (conf->map) + pci_iounmap(pdev, conf->map); pci_release_region(pdev, CVP_BAR); err_disable: cmd &= ~PCI_COMMAND_MEMORY; @@ -493,7 +494,8 @@ static void altera_cvp_remove(struct pci_dev *pdev) driver_remove_file(_cvp_driver.driver, _attr_chkcfg); fpga_mgr_unregister(mgr); - pci_iounmap(pdev, conf->map); + if (conf->map) + pci_iounmap(pdev, conf->map); pci_release_region(pdev, CVP_BAR); pci_read_config_word(pdev, PCI_COMMAND, ); cmd &= ~PCI_COMMAND_MEMORY; -- 2.7.4
[PATCH 0/4] patches for FPGA
Hi Greg, Please take these four small fpga fixes patches. They have been reviewed on the mailing list and apply cleanly on current linux-next and char-misc-testing. Thanks, Alan Anatolij Gustschin (1): fpga: altera-cvp: fix 'bad IO access' on x86_64 Andreas Puhm (1): fpga: altera-cvp: Fix registration for CvP incapable devices Mike Looijmans (1): zynq-fpga: Only route PR via PCAP when required YueHaibing (1): fpga: dfl: fme: remove set but not used variable 'priv' drivers/fpga/altera-cvp.c | 15 +-- drivers/fpga/dfl-fme-pr.c | 2 -- drivers/fpga/zynq-fpga.c | 4 3 files changed, 17 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH 3/4] fpga: altera-cvp: Fix registration for CvP incapable devices
From: Andreas Puhm
The probe function needs to verify the CvP enable bit in order to
properly determine if FPGA Manager functionality can be safely
enabled.
Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver")
Signed-off-by: Andreas Puhm
Signed-off-by: Anatolij Gustschin
Reviewed-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/altera-cvp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
index 144fa2a..7395085 100644
--- a/drivers/fpga/altera-cvp.c
+++ b/drivers/fpga/altera-cvp.c
@@ -403,6 +403,7 @@ static int altera_cvp_probe(struct pci_dev *pdev,
struct altera_cvp_conf *conf;
struct fpga_manager *mgr;
u16 cmd, val;
+ u32 regval;
int ret;
/*
@@ -416,6 +417,14 @@ static int altera_cvp_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ pci_read_config_dword(pdev, VSE_CVP_STATUS, );
+ if (!(regval & VSE_CVP_STATUS_CVP_EN)) {
+ dev_err(>dev,
+ "CVP is disabled for this device: CVP_STATUS Reg
0x%x\n",
+ regval);
+ return -ENODEV;
+ }
+
conf = devm_kzalloc(>dev, sizeof(*conf), GFP_KERNEL);
if (!conf)
return -ENOMEM;
--
2.7.4
[PATCH 1/4] fpga: altera-cvp: fix 'bad IO access' on x86_64
From: Anatolij Gustschin If mapping the CvP BAR fails, we still can configure the FPGA via PCI config space access. In this case the iomap pointer is NULL. On x86_64, passing NULL address to pci_iounmap() generates "Bad IO access at port 0x0" output with stack call trace. Fix it. Signed-off-by: Anatolij Gustschin Acked-by: Alan Tull --- drivers/fpga/altera-cvp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c index 610a155..144fa2a 100644 --- a/drivers/fpga/altera-cvp.c +++ b/drivers/fpga/altera-cvp.c @@ -477,7 +477,8 @@ static int altera_cvp_probe(struct pci_dev *pdev, return 0; err_unmap: - pci_iounmap(pdev, conf->map); + if (conf->map) + pci_iounmap(pdev, conf->map); pci_release_region(pdev, CVP_BAR); err_disable: cmd &= ~PCI_COMMAND_MEMORY; @@ -493,7 +494,8 @@ static void altera_cvp_remove(struct pci_dev *pdev) driver_remove_file(_cvp_driver.driver, _attr_chkcfg); fpga_mgr_unregister(mgr); - pci_iounmap(pdev, conf->map); + if (conf->map) + pci_iounmap(pdev, conf->map); pci_release_region(pdev, CVP_BAR); pci_read_config_word(pdev, PCI_COMMAND, ); cmd &= ~PCI_COMMAND_MEMORY; -- 2.7.4
[PATCH 0/4] patches for FPGA
Hi Greg, Please take these four small fpga fixes patches. They have been reviewed on the mailing list and apply cleanly on current linux-next and char-misc-testing. Thanks, Alan Anatolij Gustschin (1): fpga: altera-cvp: fix 'bad IO access' on x86_64 Andreas Puhm (1): fpga: altera-cvp: Fix registration for CvP incapable devices Mike Looijmans (1): zynq-fpga: Only route PR via PCAP when required YueHaibing (1): fpga: dfl: fme: remove set but not used variable 'priv' drivers/fpga/altera-cvp.c | 15 +-- drivers/fpga/dfl-fme-pr.c | 2 -- drivers/fpga/zynq-fpga.c | 4 3 files changed, 17 insertions(+), 4 deletions(-) -- 2.7.4
