From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84A66C433DB for ; Mon, 18 Jan 2021 02:54:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4F5D7206E4 for ; Mon, 18 Jan 2021 02:54:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731285AbhARCxy (ORCPT ); Sun, 17 Jan 2021 21:53:54 -0500 Received: from mga11.intel.com ([192.55.52.93]:22551 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729794AbhARCxv (ORCPT ); Sun, 17 Jan 2021 21:53:51 -0500 IronPort-SDR: Tm4jAKlQy6PmkChD9Kwwzii/JR2mKEn1Umpof5H+/f4oeQP12CV3DlOuYCXTSSA/xQNYzVZsdc B8osP9Bcys6w== X-IronPort-AV: E=McAfee;i="6000,8403,9867"; a="175246521" X-IronPort-AV: E=Sophos;i="5.79,355,1602572400"; d="scan'208";a="175246521" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2021 18:53:10 -0800 IronPort-SDR: zvmiLsMvdgYUkatsrYUCGpjP+uNEHGMfZJ/IufESAwsRkv00vTID0TGorc1gwZ+IUyMPstIDw8 gTKk8jj85ENQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,355,1602572400"; d="scan'208";a="355033558" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.141]) by fmsmga008.fm.intel.com with ESMTP; 17 Jan 2021 18:53:08 -0800 Date: Mon, 18 Jan 2021 10:48:46 +0800 From: Xu Yilun To: Moritz Fischer Cc: linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, trix@redhat.com, lgoncalv@redhat.com, hao.wu@intel.com, yilun.xu@intel.com Subject: Re: [PATCH v6 1/2] fpga: dfl: add the userspace I/O device support for DFL devices Message-ID: <20210118024846.GA8153@yilunxu-OptiPlex-7050> References: <1610502848-30345-1-git-send-email-yilun.xu@intel.com> <1610502848-30345-2-git-send-email-yilun.xu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 16, 2021 at 07:56:08PM -0800, Moritz Fischer wrote: > Hi Xu, > > On Wed, Jan 13, 2021 at 09:54:07AM +0800, Xu Yilun wrote: > > This patch supports the DFL drivers be written in userspace. This is > > realized by exposing the userspace I/O device interfaces. > > > > The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq > > platform device with the DFL device's resources, and let the generic UIO > > platform device driver provide support to userspace access to kernel > > interrupts and memory locations. > > > > The driver now supports the ether group feature. To support a new DFL > > feature been directly accessed via UIO, its feature id should be added to > > the driver's id_table. > > > > Signed-off-by: Xu Yilun > > Reviewed-by: Tom Rix > > Acked-by: Wu Hao > > --- > > v2: switch to the new matching algorithem. It matches DFL devices which > > could not be handled by other DFL drivers. > > refacor the code about device resources filling. > > fix some comments. > > v3: split the dfl.c changes out of this patch. > > some minor fixes > > v4: drop the idea of a generic matching algorithem, instead we specify > > each matching device in id_table. > > to make clear that only one irq is supported, the irq handling code > > is refactored. > > v5: refactor the irq resource code. > > v6: fix the res[] zero initialization issue. > > improve the return code for probe(). > > --- > > drivers/fpga/Kconfig | 10 +++++ > > drivers/fpga/Makefile | 1 + > > drivers/fpga/dfl-uio-pdev.c | 93 +++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 104 insertions(+) > > create mode 100644 drivers/fpga/dfl-uio-pdev.c > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > index 5ff9438..61445be 100644 > > --- a/drivers/fpga/Kconfig > > +++ b/drivers/fpga/Kconfig > > @@ -203,6 +203,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000 > > the card. It also instantiates the SPI master (spi-altera) for > > the card's BMC (Board Management Controller). > > > > +config FPGA_DFL_UIO_PDEV > > + tristate "FPGA DFL Driver for Userspace I/O platform devices" > > + depends on FPGA_DFL && UIO_PDRV_GENIRQ > > + help > > + Enable this to allow some DFL drivers be written in userspace. It > Nit: Enable this to allow DFL drivers to be written in userspace. Yes, will fix it. > > + adds the uio_pdrv_genirq platform device with the DFL feature's > > + resources, and lets the generic UIO platform device driver provide > > + support for userspace access to kernel interrupts and memory > > + locations. > > + > > config FPGA_DFL_PCI > > tristate "FPGA DFL PCIe Device Driver" > > depends on PCI && FPGA_DFL > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > > index 18dc9885..8847fe0 100644 > > --- a/drivers/fpga/Makefile > > +++ b/drivers/fpga/Makefile > > @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o > > dfl-afu-objs += dfl-afu-error.o > > > > obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000) += dfl-n3000-nios.o > > +obj-$(CONFIG_FPGA_DFL_UIO_PDEV) += dfl-uio-pdev.o > > > > # Drivers for FPGAs which implement DFL > > obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o > > diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c > > new file mode 100644 > > index 0000000..12b47bf > > --- /dev/null > > +++ b/drivers/fpga/dfl-uio-pdev.c > > @@ -0,0 +1,93 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * DFL driver for Userspace I/O platform devices > > + * > > + * Copyright (C) 2020 Intel Corporation, Inc. > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DRIVER_NAME "dfl-uio-pdev" > > + > > +static int dfl_uio_pdev_probe(struct dfl_device *ddev) > > +{ > > + struct platform_device_info pdevinfo = { 0 }; > > + struct resource res[2] = { { 0 } }; > > + struct uio_info uio_pdata = { 0 }; > > + struct platform_device *uio_pdev; > > + struct device *dev = &ddev->dev; > > + unsigned int num_res = 1; > > + > > + res[0].parent = &ddev->mmio_res; > > + res[0].flags = IORESOURCE_MEM; > > + res[0].start = ddev->mmio_res.start; > > + res[0].end = ddev->mmio_res.end; > > + > > + if (ddev->num_irqs) { > > + if (ddev->num_irqs > 1) > > + dev_warn(&ddev->dev, > > + "%d irqs for %s, but UIO only supports the first one\n", > > + ddev->num_irqs, dev_name(&ddev->dev)); > > + > > + res[1].flags = IORESOURCE_IRQ; > > + res[1].start = ddev->irqs[0]; > > + res[1].end = ddev->irqs[0]; > > + num_res++; > > + } > > + > > + uio_pdata.name = DRIVER_NAME; > > + uio_pdata.version = "0"; > > + > > + pdevinfo.name = "uio_pdrv_genirq"; > > + pdevinfo.res = res; > > + pdevinfo.num_res = num_res; > > + pdevinfo.parent = &ddev->dev; > > + pdevinfo.id = PLATFORM_DEVID_AUTO; > > + pdevinfo.data = &uio_pdata; > > + pdevinfo.size_data = sizeof(uio_pdata); > > + > > + uio_pdev = platform_device_register_full(&pdevinfo); > It looks like: > platform_device_register_resndata(&ddev->dev, "uio_pdrv_genirq", > PLATFORM_DEVID_AUTO, res, num_res, > &uio_pdata, sizeof(uio_pdata)) > > would work? It works. I'll change it. > > > > + if (IS_ERR(uio_pdev)) > > + return PTR_ERR(uio_pdev); > > + > > + dev_set_drvdata(dev, uio_pdev); > > + > > + return 0; > > +} > > + > > +static void dfl_uio_pdev_remove(struct dfl_device *ddev) > > +{ > > + struct platform_device *uio_pdev = dev_get_drvdata(&ddev->dev); > > + > > + platform_device_unregister(uio_pdev); > > +} > > + > > +#define FME_FEATURE_ID_ETH_GROUP 0x10 > > + > > +static const struct dfl_device_id dfl_uio_pdev_ids[] = { > > + { FME_ID, FME_FEATURE_ID_ETH_GROUP }, > > + > > + /* Add your new id entries here to support uio for more dfl features */ > This is fairly common, we can maybe drop this comment? Yes. Thanks, Yilun