Re: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master

[Xu Yilun]

On Fri, Apr 09, 2021 at 12:02:47PM +0800, Wu, Hao wrote:
> > > > > > > > > +
> > > > > > > > > +static void dfl_spi_altera_remove(struct dfl_device *dfl_dev)
> > > > > > > > > +{
> > > > > > > > > +struct dfl_altera_spi *aspi = dev_get_drvdata(_dev->dev);
> > > > > > > > > +
> > > > > > > > > +platform_device_unregister(aspi->altr_spi);
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +#define FME_FEATURE_ID_MAX10_SPI0xe
> > > > > > > > > +
> > > > > > > > > +static const struct dfl_device_id dfl_spi_altera_ids[] = {
> > > > > > > > > +{ FME_ID, FME_FEATURE_ID_MAX10_SPI },
> > > > > > > > > +{ }
> > > > > > > > > +};
> > > > > > > >
> > > > > > > > Maybe you can extend the Altera SPI driver with this part?
> > > > > > >
> > > > > > > The file, drivers/spi/spi-altera.c, already has platform MODULE_
> > related
> > > > > > > code.  Wouldn't moving this code to that file produce conflicts?
> > > > > >
> > > > > > I've seen other drivers support multiple busses, so it should be
> > > > > > possible, there might be nuances I'm missing in my brief look at 
> > > > > > this,
> > > > > > though.
> > > > > >
> > > > > > I think one of them would be MODULE_DEVICE_TABLE(platform, ...)
> > > > > > and the other one MODULE_DEVICE_TABLE(dfl, ...)
> > > > > >
> > > > > > See drivers/i2c/busses/i2c-designware-platdrv.c for an example 
> > > > > > (though
> > > > > > they might be guarding against what you describe with CONFIG_OF vs
> > > > > > CONFIG_ACPI)
> > > > > >
> > > > > > If that doesn't work we could split it up into
> > > > > >
> > > > > > altera-spi-plat.c and altera-spi-dfl.c and altera-spi-core.c
> > > > > > or something of that sort?
> > > > > >
> > > > > > My point being, now that we have a bus, let's use it and develop 
> > > > > > drivers
> > > > > > according to the Linux device model where possible :)
> > > > >
> > > > > Agree. This does make sense from my side too. DFL core provides the
> > > > mechanism
> > > > > to enumerate different IPs on FPGA, but each function driver needs to 
> > > > > go
> > to
> > > > > related subsystem for review.  : )
> > > > >
> > > > > I understand that for FPGA case, it may have some additional logics 
> > > > > for
> > specific
> > > > > purposes based on common altera spi master IP, then additional code 
> > > > > for
> > > >
> > > > I'm wondering if the additional logics are extensions for common 
> > > > spi-altera.
> > Like
> > > > the
> > > > SPI_CORE_PARAMETER register, it is not within the register space of
> > > > spi-altera,
> > > >
> > > >
> > > >   |   |  +-+
> > > >   |DFL|--| ++  |
> > > >   |BUS|  | |SPI CORE|  |
> > > >   |   |  | |PARAM   |  |
> > > >   |   |  | ++  |
> > > >   |   |  | |
> > > >   |   |  | ++  |   +---+
> > > >  | |Indirect|  |   |spi|
> > > >  | |access  +--+---|altera |
> > > >  | |master  |  |   +---+
> > > >  | ++  |
> > > >  +-+
> > > > > a specific product still can be put into altera-spi-.c or 
> > > > > altera-spi-dfl-
> > .c
> > > >
> > > > So is it proper we integrate this feature into spi-altera? Previously
> > > > we have merged the dfl-n3000-nios, its spi part is very similar as
> > > > this driver. The dfl-n3000-nios make the spi-altera as a sub device.
> > > > Could we borrow the idea, or could we just integrate this driver in
> > > > dfl-n3000-nios?
> > >
> > > Looks like those are enhancements of the IP. They can be applied even
> >
> > I don't think the extra registers are the enhancement of the IP. They
> > are not part of the IP because they are not within the IP's register
> > space. They are like some external way of describing the IP like
> > Devicetree or ACPI.
> 
> Why adding new registers can't be consider as enhancement, those
> changes serve the original IP and make it better, right? small mmio
> footprint and parameter registers?
> 
> >
> > > other buses are used, not only for DFL, like PCI device or platform 
> > > device,
> > > right? then why not put related code together with the original IP?
> >
> > The code of devicetree or ACPI parsing are integrated in the IP drivers,
> > but for this case, it may not be proper for now, cause this style is not
> > formally introduced by any standard. IP specific parameters description
> > are not within the scope of DFL now.
> 
> Not sure if I get your point, but it's possible that we add some enhancements
> to one IP then driver could be simplified and doesn't need devicetree any 
> more.
> For sure, it's IP specific thing, not the scope of DFL.
> 
> Then things become this: extension to IP to allow this IP to be used without
> device tree, so that this IP can be used in DFL or PCI or other buses without
> device tree?

It's good to extend an IP, but it needs a published SPEC and stable
register interfaces. For now, the spi-altera driver conforms to the
"SPI Core" chapter 

Re: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master

[Xu Yilun]

On Thu, Apr 08, 2021 at 11:53:06AM -0700, Moritz Fischer wrote:
> On Thu, Apr 08, 2021 at 09:20:19AM +, Wu, Hao wrote:
> > > On Thu, Apr 08, 2021 at 03:30:15PM +0800, Wu, Hao wrote:
> > > > > > On Mon, 5 Apr 2021, Moritz Fischer wrote:
> > > > > >
> > > > > > > Hi Matthew,
> > > > > > >
> > > > > > > On Mon, Apr 05, 2021 at 04:53:00PM -0700,
> > > > > matthew.gerl...@linux.intel.com wrote:
> > > > > > > > From: Matthew Gerlach 
> > > > > > > >
> > > > > > > > This patch adds DFL bus driver for the Altera SPI Master
> > > > > > > > controller.  The SPI master is connected to an Intel SPI Slave 
> > > > > > > > to
> > > > > > > > Avalon Master Bridge, inside an Intel MAX10 BMC Chip.
> > > > > > > >
> > > > > > > > Signed-off-by: Matthew Gerlach 
> > > > > > > > ---
> > > > > > > >  drivers/fpga/Kconfig  |   9 ++
> > > > > > > >  drivers/fpga/Makefile |   1 +
> > > > > > > >  drivers/fpga/dfl-spi-altera.c | 221
> > > > > ++
> > > > > > > >  3 files changed, 231 insertions(+)
> > > > > > > >  create mode 100644 drivers/fpga/dfl-spi-altera.c
> > > > > > > >
> > > > > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > > > > > index d591dd9..0a86994 100644
> > > > > > > > --- a/drivers/fpga/Kconfig
> > > > > > > > +++ b/drivers/fpga/Kconfig
> > > > > > > > @@ -210,6 +210,15 @@ 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_SPI_ALTERA
> > > > > > > > +tristate "FPGA DFL Altera SPI Master Driver"
> > > > > > > > +depends on FPGA_DFL
> > > > > > > > +select REGMAP
> > > > > > > > +help
> > > > > > > > +  This is a DFL bus driver for the Altera SPI master 
> > > > > > > > controller.
> > > > > > > > +  The SPI master is connected to a SPI slave to Avalon Master
> > > > > > > > +  bridge in a Intel MAX BMC.
> > > > > > > > +
> > > > > > > >  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..58a42ad 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_SPI_ALTERA)+= dfl-spi-altera.o
> > > > > > > >
> > > > > > > >  # Drivers for FPGAs which implement DFL
> > > > > > > >  obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o
> > > > > > > > diff --git a/drivers/fpga/dfl-spi-altera.c 
> > > > > > > > b/drivers/fpga/dfl-spi-altera.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000..9bec25fd
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/drivers/fpga/dfl-spi-altera.c
> > > > > > > > @@ -0,0 +1,221 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > +/*
> > > > > > > > + * DFL bus driver for Altera SPI Master
> > > > > > > > + *
> > > > > > > > + * Copyright (C) 2020 Intel Corporation, Inc.
> > > > > > > > + *
> > > > > > > > + * Authors:
> > > > > > > > + *   Matthew Gerlach 
> > > > > > > > + */
> > > > > > > > +
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +#include 
> > > > > > > > +
> > > > > > > > +struct dfl_altera_spi {
> > > > > > > > +void __iomem *base;
> > > > > > > > +struct regmap *regmap;
> > > > > > > > +struct device *dev;
> > > > > > > > +struct platform_device *altr_spi;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +#define SPI_CORE_PARAMETER  0x8
> > > > > > > > +#define SHIFT_MODE  BIT_ULL(1)
> > > > > > > > +#define SHIFT_MODE_MSB  0
> > > > > > > > +#define SHIFT_MODE_LSB  1
> > > > > > > > +#define DATA_WIDTH  GENMASK_ULL(7, 2)
> > > > > > > > +#define NUM_CHIPSELECT  GENMASK_ULL(13, 8)
> > > > > > > > +#define CLK_POLARITYBIT_ULL(14)
> > > > > > > > +#define CLK_PHASE   BIT_ULL(15)
> > > > > > > > +#define PERIPHERAL_ID   GENMASK_ULL(47, 32)
> > > > > > > > +#define SPI_CLK GENMASK_ULL(31, 22)
> > > > > > > > +#define SPI_INDIRECT_ACC_OFST   0x10
> > > > > > > > +
> > > > > > > > +#define INDIRECT_ADDR   (SPI_INDIRECT_ACC_OFST+0x0)
> > > > > > > > +#define INDIRECT_WR BIT_ULL(8)
> > > > > > > > +#define INDIRECT_RD BIT_ULL(9)
> > > 

Re: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master

[Xu Yilun]

On Thu, Apr 08, 2021 at 05:20:19PM +0800, Wu, Hao wrote:
> > On Thu, Apr 08, 2021 at 03:30:15PM +0800, Wu, Hao wrote:
> > > > > On Mon, 5 Apr 2021, Moritz Fischer wrote:
> > > > >
> > > > > > Hi Matthew,
> > > > > >
> > > > > > On Mon, Apr 05, 2021 at 04:53:00PM -0700,
> > > > matthew.gerl...@linux.intel.com wrote:
> > > > > > > From: Matthew Gerlach 
> > > > > > >
> > > > > > > This patch adds DFL bus driver for the Altera SPI Master
> > > > > > > controller.  The SPI master is connected to an Intel SPI Slave to
> > > > > > > Avalon Master Bridge, inside an Intel MAX10 BMC Chip.
> > > > > > >
> > > > > > > Signed-off-by: Matthew Gerlach 
> > > > > > > ---
> > > > > > >  drivers/fpga/Kconfig  |   9 ++
> > > > > > >  drivers/fpga/Makefile |   1 +
> > > > > > >  drivers/fpga/dfl-spi-altera.c | 221
> > > > ++
> > > > > > >  3 files changed, 231 insertions(+)
> > > > > > >  create mode 100644 drivers/fpga/dfl-spi-altera.c
> > > > > > >
> > > > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > > > > index d591dd9..0a86994 100644
> > > > > > > --- a/drivers/fpga/Kconfig
> > > > > > > +++ b/drivers/fpga/Kconfig
> > > > > > > @@ -210,6 +210,15 @@ 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_SPI_ALTERA
> > > > > > > +tristate "FPGA DFL Altera SPI Master Driver"
> > > > > > > +depends on FPGA_DFL
> > > > > > > +select REGMAP
> > > > > > > +help
> > > > > > > +  This is a DFL bus driver for the Altera SPI master controller.
> > > > > > > +  The SPI master is connected to a SPI slave to Avalon Master
> > > > > > > +  bridge in a Intel MAX BMC.
> > > > > > > +
> > > > > > >  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..58a42ad 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_SPI_ALTERA)+= dfl-spi-altera.o
> > > > > > >
> > > > > > >  # Drivers for FPGAs which implement DFL
> > > > > > >  obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o
> > > > > > > diff --git a/drivers/fpga/dfl-spi-altera.c 
> > > > > > > b/drivers/fpga/dfl-spi-altera.c
> > > > > > > new file mode 100644
> > > > > > > index 000..9bec25fd
> > > > > > > --- /dev/null
> > > > > > > +++ b/drivers/fpga/dfl-spi-altera.c
> > > > > > > @@ -0,0 +1,221 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > +/*
> > > > > > > + * DFL bus driver for Altera SPI Master
> > > > > > > + *
> > > > > > > + * Copyright (C) 2020 Intel Corporation, Inc.
> > > > > > > + *
> > > > > > > + * Authors:
> > > > > > > + *   Matthew Gerlach 
> > > > > > > + */
> > > > > > > +
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +
> > > > > > > +struct dfl_altera_spi {
> > > > > > > +void __iomem *base;
> > > > > > > +struct regmap *regmap;
> > > > > > > +struct device *dev;
> > > > > > > +struct platform_device *altr_spi;
> > > > > > > +};
> > > > > > > +
> > > > > > > +#define SPI_CORE_PARAMETER  0x8
> > > > > > > +#define SHIFT_MODE  BIT_ULL(1)
> > > > > > > +#define SHIFT_MODE_MSB  0
> > > > > > > +#define SHIFT_MODE_LSB  1
> > > > > > > +#define DATA_WIDTH  GENMASK_ULL(7, 2)
> > > > > > > +#define NUM_CHIPSELECT  GENMASK_ULL(13, 8)
> > > > > > > +#define CLK_POLARITYBIT_ULL(14)
> > > > > > > +#define CLK_PHASE   BIT_ULL(15)
> > > > > > > +#define PERIPHERAL_ID   GENMASK_ULL(47, 32)
> > > > > > > +#define SPI_CLK GENMASK_ULL(31, 22)
> > > > > > > +#define SPI_INDIRECT_ACC_OFST   0x10
> > > > > > > +
> > > > > > > +#define INDIRECT_ADDR   (SPI_INDIRECT_ACC_OFST+0x0)
> > > > > > > +#define INDIRECT_WR BIT_ULL(8)
> > > > > > > +#define INDIRECT_RD BIT_ULL(9)
> > > > > > > +#define INDIRECT_RD_DATA(SPI_INDIRECT_ACC_OFST+0x8)
> > > > > > > +#define INDIRECT_DATA_MASK  GENMASK_ULL(31, 0)
> > > > > > > +#define INDIRECT_DEBUG  BIT_ULL(32)
> > > > > > > +#define INDIRECT_WR_DATA(SPI_INDIRECT_ACC_OFST+0x10)
> > > > > > > +#define INDIRECT_TIMEOUT1
> > > > > > > 

Re: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master

[Xu Yilun]

On Thu, Apr 08, 2021 at 03:30:15PM +0800, Wu, Hao wrote:
> > > On Mon, 5 Apr 2021, Moritz Fischer wrote:
> > >
> > > > Hi Matthew,
> > > >
> > > > On Mon, Apr 05, 2021 at 04:53:00PM -0700,
> > matthew.gerl...@linux.intel.com wrote:
> > > > > From: Matthew Gerlach 
> > > > >
> > > > > This patch adds DFL bus driver for the Altera SPI Master
> > > > > controller.  The SPI master is connected to an Intel SPI Slave to
> > > > > Avalon Master Bridge, inside an Intel MAX10 BMC Chip.
> > > > >
> > > > > Signed-off-by: Matthew Gerlach 
> > > > > ---
> > > > >  drivers/fpga/Kconfig  |   9 ++
> > > > >  drivers/fpga/Makefile |   1 +
> > > > >  drivers/fpga/dfl-spi-altera.c | 221
> > ++
> > > > >  3 files changed, 231 insertions(+)
> > > > >  create mode 100644 drivers/fpga/dfl-spi-altera.c
> > > > >
> > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > > index d591dd9..0a86994 100644
> > > > > --- a/drivers/fpga/Kconfig
> > > > > +++ b/drivers/fpga/Kconfig
> > > > > @@ -210,6 +210,15 @@ 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_SPI_ALTERA
> > > > > +tristate "FPGA DFL Altera SPI Master Driver"
> > > > > +depends on FPGA_DFL
> > > > > +select REGMAP
> > > > > +help
> > > > > +  This is a DFL bus driver for the Altera SPI master controller.
> > > > > +  The SPI master is connected to a SPI slave to Avalon Master
> > > > > +  bridge in a Intel MAX BMC.
> > > > > +
> > > > >  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..58a42ad 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_SPI_ALTERA)+= dfl-spi-altera.o
> > > > >
> > > > >  # Drivers for FPGAs which implement DFL
> > > > >  obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o
> > > > > diff --git a/drivers/fpga/dfl-spi-altera.c 
> > > > > b/drivers/fpga/dfl-spi-altera.c
> > > > > new file mode 100644
> > > > > index 000..9bec25fd
> > > > > --- /dev/null
> > > > > +++ b/drivers/fpga/dfl-spi-altera.c
> > > > > @@ -0,0 +1,221 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +/*
> > > > > + * DFL bus driver for Altera SPI Master
> > > > > + *
> > > > > + * Copyright (C) 2020 Intel Corporation, Inc.
> > > > > + *
> > > > > + * Authors:
> > > > > + *   Matthew Gerlach 
> > > > > + */
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +struct dfl_altera_spi {
> > > > > +void __iomem *base;
> > > > > +struct regmap *regmap;
> > > > > +struct device *dev;
> > > > > +struct platform_device *altr_spi;
> > > > > +};
> > > > > +
> > > > > +#define SPI_CORE_PARAMETER  0x8
> > > > > +#define SHIFT_MODE  BIT_ULL(1)
> > > > > +#define SHIFT_MODE_MSB  0
> > > > > +#define SHIFT_MODE_LSB  1
> > > > > +#define DATA_WIDTH  GENMASK_ULL(7, 2)
> > > > > +#define NUM_CHIPSELECT  GENMASK_ULL(13, 8)
> > > > > +#define CLK_POLARITYBIT_ULL(14)
> > > > > +#define CLK_PHASE   BIT_ULL(15)
> > > > > +#define PERIPHERAL_ID   GENMASK_ULL(47, 32)
> > > > > +#define SPI_CLK GENMASK_ULL(31, 22)
> > > > > +#define SPI_INDIRECT_ACC_OFST   0x10
> > > > > +
> > > > > +#define INDIRECT_ADDR   (SPI_INDIRECT_ACC_OFST+0x0)
> > > > > +#define INDIRECT_WR BIT_ULL(8)
> > > > > +#define INDIRECT_RD BIT_ULL(9)
> > > > > +#define INDIRECT_RD_DATA(SPI_INDIRECT_ACC_OFST+0x8)
> > > > > +#define INDIRECT_DATA_MASK  GENMASK_ULL(31, 0)
> > > > > +#define INDIRECT_DEBUG  BIT_ULL(32)
> > > > > +#define INDIRECT_WR_DATA(SPI_INDIRECT_ACC_OFST+0x10)
> > > > > +#define INDIRECT_TIMEOUT1
> > > > > +
> > > > > +static int indirect_bus_reg_read(void *context, unsigned int reg,
> > > > > + unsigned int *val)
> > > > > +{
> > > > > +struct dfl_altera_spi *aspi = context;
> > > > > +void __iomem *base = aspi->base;
> > > > > +int loops;
> > > > > +u64 v;
> > > > > +
> > > > > +writeq((reg >> 2) | INDIRECT_RD, base + INDIRECT_ADDR);
> > > > > +
> > > > > +loops = 0;
> > > > > +while ((readq(base + INDIRECT_ADDR) & INDIRECT_RD) &&
> > > > > +   (loops++ < INDIRECT_TIMEOUT))
> > > > > +cpu_relax();
> > > > > +
> > > > > +if 

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

[Xu Yilun]

On Mon, Apr 05, 2021 at 04:53:01PM -0700, matthew.gerl...@linux.intel.com wrote:
> From: Matthew Gerlach 
> 
> Like the Intel N3000 card, the Intel D5005 has a MAX10 based
> BMC.  This commit adds support for the D5005 sensors that are
> monitored by the MAX10 BMC.
> 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Russ Weight 
> ---
>  drivers/hwmon/intel-m10-bmc-hwmon.c | 122 
> 
>  drivers/mfd/intel-m10-bmc.c |  10 +++
>  2 files changed, 132 insertions(+)
> 
> diff --git a/drivers/hwmon/intel-m10-bmc-hwmon.c 
> b/drivers/hwmon/intel-m10-bmc-hwmon.c
> index 17d5e6b..bd7ed2e 100644
> --- a/drivers/hwmon/intel-m10-bmc-hwmon.c
> +++ b/drivers/hwmon/intel-m10-bmc-hwmon.c
> @@ -99,6 +99,50 @@ struct m10bmc_hwmon {
>   NULL
>  };
>  
> +static const struct m10bmc_sdata d5005bmc_temp_tbl[] = {
> + { 0x100, 0x104, 0x108, 0x10c, 0x0, 500, "Board Inlet Air Temperature" },
> + { 0x110, 0x114, 0x118, 0x0, 0x0, 500, "FPGA Core Temperature" },
> + { 0x11c, 0x120, 0x124, 0x128, 0x0, 500, "Board Exhaust Air Temperature" 
> },
> + { 0x12c, 0x130, 0x134, 0x0, 0x0, 500, "FPGA Transceiver Temperature" },
> + { 0x138, 0x13c, 0x140, 0x144, 0x0, 500, "RDIMM0 Temperature" },
> + { 0x148, 0x14c, 0x150, 0x154, 0x0, 500, "RDIMM1 Temperature" },
> + { 0x158, 0x15c, 0x160, 0x164, 0x0, 500, "RDIMM2 Temperature" },
> + { 0x168, 0x16c, 0x170, 0x174, 0x0, 500, "RDIMM3 Temperature" },
> + { 0x178, 0x17c, 0x180, 0x0, 0x0, 500, "QSFP0 Temperature" },
> + { 0x188, 0x18c, 0x190, 0x0, 0x0, 500, "QSFP1 Temperature" },
> + { 0x1a0, 0x1a4, 0x1a8, 0x0, 0x0, 500, "3.3v Temperature" },
> + { 0x1bc, 0x1c0, 0x1c4, 0x0, 0x0, 500, "VCCERAM Temperature" },
> + { 0x1d8, 0x1dc, 0x1e0, 0x0, 0x0, 500, "VCCR Temperature" },
> + { 0x1f4, 0x1f8, 0x1fc, 0x0, 0x0, 500, "VCCT Temperature" },
> + { 0x210, 0x214, 0x218, 0x0, 0x0, 500, "1.8v Temperature" },
> + { 0x22c, 0x230, 0x234, 0x0, 0x0, 500, "12v Backplane Temperature" },
> + { 0x248, 0x24c, 0x250, 0x0, 0x0, 500, "12v AUX Temperature" },
> +};
> +
> +static const struct m10bmc_sdata d5005bmc_in_tbl[] = {
> + { 0x184, 0x0, 0x0, 0x0, 0x0, 1, "QSFP0 Supply Voltage" },
> + { 0x194, 0x0, 0x0, 0x0, 0x0, 1, "QSFP1 Supply Voltage" },
> + { 0x198, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Voltage" },
> + { 0x1ac, 0x1b0, 0x1b4, 0x0, 0x0, 1, "3.3v Voltage" },
> + { 0x1c8, 0x1cc, 0x1d0, 0x0, 0x0, 1, "VCCERAM Voltage" },
> + { 0x1e4, 0x1e8, 0x1ec, 0x0, 0x0, 1, "VCCR Voltage" },
> + { 0x200, 0x204, 0x208, 0x0, 0x0, 1, "VCCT Voltage" },
> + { 0x21c, 0x220, 0x224, 0x0, 0x0, 1, "1.8v Voltage" },
> + { 0x238, 0x0, 0x0, 0x0, 0x23c, 1, "12v Backplane Voltage" },
> + { 0x254, 0x0, 0x0, 0x0, 0x258, 1, "12v AUX Voltage" },
> +};
> +
> +static const struct m10bmc_sdata d5005bmc_curr_tbl[] = {
> + { 0x19c, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Current" },
> + { 0x1b8, 0x0, 0x0, 0x0, 0x0, 1, "3.3v Current" },
> + { 0x1d4, 0x0, 0x0, 0x0, 0x0, 1, "VCCERAM Current" },
> + { 0x1f0, 0x0, 0x0, 0x0, 0x0, 1, "VCCR Current" },
> + { 0x20c, 0x0, 0x0, 0x0, 0x0, 1, "VCCT Current" },
> + { 0x228, 0x0, 0x0, 0x0, 0x0, 1, "1.8v Current" },
> + { 0x240, 0x244, 0x0, 0x0, 0x0, 1, "12v Backplane Current" },
> + { 0x25c, 0x260, 0x0, 0x0, 0x0, 1, "12v AUX Current" },
> +};
> +
>  static const struct m10bmc_hwmon_board_data n3000bmc_hwmon_bdata = {
>   .tables = {
>   [hwmon_temp] = n3000bmc_temp_tbl,
> @@ -110,6 +154,80 @@ struct m10bmc_hwmon {
>   .hinfo = n3000bmc_hinfo,
>  };
>  
> +static const struct hwmon_channel_info *d5005bmc_hinfo[] = {
> + HWMON_CHANNEL_INFO(temp,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
> +HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
> +HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
> +HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
> +HWMON_T_LABEL,
> +HWMON_T_INPUT | 

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

[Xu Yilun]

Hi Moritz:

Sorry I need to get back to you again, seems no more comments from Greg.

The patchset is stuck here for more than 1 month. Do you have some
more suggestion that could make it move forward? Do you have some more
comments? Or give an acked-by? Or could you apply it to your fpga branch
and go with next pull request?

Thanks,
Yilun

On Mon, Mar 08, 2021 at 09:59:34AM +0800, Xu Yilun wrote:
> This patchset supports some dfl device drivers written in userspace.
> 
> There are some Q about why UIO driver is needed in v11:
> 
> >From Greg:
>   Why are you saying that an ethernet driver should be using the UIO
>   interface?
> 
>   And why can't you use the existing UIO drivers that bind to memory
>   regions specified by firmware?  Without an interrupt being used, why is
>   UIO needed at all?
> 
> >From Moritz:
>   Essentially I see two options:
>   - Have a DFL bus driver instantiate a platform driver (uio_pdrv_genirq)
> which I *think* you described above?
>   - What this patch implements -- a UIO driver on the DFL bus
> 
>   These FPGA devices can on the fly change their contents and -- even if
>   just for test -- being able to expose a bunch of registers via UIO can
>   be extremely useful.
> 
>   Whether a device should expose registers or not should be up to the
>   implemeneter of the FPGA design I think (policy). This patch (or the
>   previous version) provides a mechanism to do so via DFL.
> 
>   This is similar in nature to uio_pdrv_genirq on a DT based platform, to
>   expose the registers you instantiate the DT node.
> 
>   Re-implementing a new driver for each of these instances doesn't seem
>   desirable and tying DFL as enumeration mechanism to UIO seems like a
>   good compromise for enabling this kind of functionality.
> 
>   Note this is *not* an attempt to bypass the network stack or other
>   existing subsystems.
> 
> See the original message in:
>   
> https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m66ba2c96848e3dea38d1a4f16dfea3cb291f7975
> 
> 
> >From Yilun:
>   The ETH GROUP IP is not designed as the full functional ethernet
>   controller. It is specially developed for the Intel N3000 NIC. Since it
>   is an FPGA based card, it is designed for the users to runtime reload
>   part of the MAC layer logic developed by themselves, while the ETH GROUP
>   is another part of the MAC which is not expected to be reloaded by
>   customers, but it provides some configurations for software to work with
>   the user logic.
> 
>   So I category the feature as the devices that "designed for specific
>   purposes and does not fit into one of the standard kernel subsystems".
>   Some related description could be found in Patch #2, to illustrate why
>   using UIO for some DFL devices.
> 
>   There are now UIO drivers for PCI or platform devices, but in this case
>   we are going to export a DFL(Device Feature List) bus device to
>   userspace, a DFL driver for UIO is needed to bind to it.
> 
> See the original message in:
>   
> https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m91b303fd61485644353fad1e1e9c11d528844684
> 
> 
> Xu Yilun (2):
>   uio: uio_dfl: add userspace i/o driver for DFL bus
>   Documentation: fpga: dfl: Add description for DFL UIO support
> 
>  Documentation/fpga/dfl.rst | 26 ++
>  MAINTAINERS|  1 +
>  drivers/uio/Kconfig| 17 
>  drivers/uio/Makefile   |  1 +
>  drivers/uio/uio_dfl.c  | 66 
> ++
>  5 files changed, 111 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
> 
> -- 
> 2.7.4

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

[Xu Yilun]

Hi Greg:

I listed below some answers from Moritz and Yilun from previous mails for
your question.

Do you have more comments?

Thanks in advance,
Yilun

On Mon, Mar 08, 2021 at 09:59:34AM +0800, Xu Yilun wrote:
> This patchset supports some dfl device drivers written in userspace.
> 
> There are some Q about why UIO driver is needed in v11:
> 
> >From Greg:
>   Why are you saying that an ethernet driver should be using the UIO
>   interface?
> 
>   And why can't you use the existing UIO drivers that bind to memory
>   regions specified by firmware?  Without an interrupt being used, why is
>   UIO needed at all?
> 
> >From Moritz:
>   Essentially I see two options:
>   - Have a DFL bus driver instantiate a platform driver (uio_pdrv_genirq)
> which I *think* you described above?
>   - What this patch implements -- a UIO driver on the DFL bus
> 
>   These FPGA devices can on the fly change their contents and -- even if
>   just for test -- being able to expose a bunch of registers via UIO can
>   be extremely useful.
> 
>   Whether a device should expose registers or not should be up to the
>   implemeneter of the FPGA design I think (policy). This patch (or the
>   previous version) provides a mechanism to do so via DFL.
> 
>   This is similar in nature to uio_pdrv_genirq on a DT based platform, to
>   expose the registers you instantiate the DT node.
> 
>   Re-implementing a new driver for each of these instances doesn't seem
>   desirable and tying DFL as enumeration mechanism to UIO seems like a
>   good compromise for enabling this kind of functionality.
> 
>   Note this is *not* an attempt to bypass the network stack or other
>   existing subsystems.
> 
> See the original message in:
>   
> https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m66ba2c96848e3dea38d1a4f16dfea3cb291f7975
> 
> 
> >From Yilun:
>   The ETH GROUP IP is not designed as the full functional ethernet
>   controller. It is specially developed for the Intel N3000 NIC. Since it
>   is an FPGA based card, it is designed for the users to runtime reload
>   part of the MAC layer logic developed by themselves, while the ETH GROUP
>   is another part of the MAC which is not expected to be reloaded by
>   customers, but it provides some configurations for software to work with
>   the user logic.
> 
>   So I category the feature as the devices that "designed for specific
>   purposes and does not fit into one of the standard kernel subsystems".
>   Some related description could be found in Patch #2, to illustrate why
>   using UIO for some DFL devices.
> 
>   There are now UIO drivers for PCI or platform devices, but in this case
>   we are going to export a DFL(Device Feature List) bus device to
>   userspace, a DFL driver for UIO is needed to bind to it.
> 
> See the original message in:
>   
> https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m91b303fd61485644353fad1e1e9c11d528844684
> 
> 
> Xu Yilun (2):
>   uio: uio_dfl: add userspace i/o driver for DFL bus
>   Documentation: fpga: dfl: Add description for DFL UIO support
> 
>  Documentation/fpga/dfl.rst | 26 ++
>  MAINTAINERS|  1 +
>  drivers/uio/Kconfig| 17 
>  drivers/uio/Makefile   |  1 +
>  drivers/uio/uio_dfl.c  | 66 
> ++
>  5 files changed, 111 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
> 
> -- 
> 2.7.4

[PATCH v4 1/4] mfd: intel-m10-bmc: Fix the register access range

[Xu Yilun]

This patch fixes the max register address of MAX 10 BMC. The range
0x2000 ~ 0x20fc are for control registers of the QSPI flash
controller, which are not accessible to host.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Acked-for-MFD-by: Lee Jones 
---
v2: no change.
v3: no change, rebased to 5.12-rc1
v4: add Lee's Acked-by, no other change.
---
 include/linux/mfd/intel-m10-bmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 74d4e19..9b54ca1 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,7 @@
 
 #define M10BMC_LEGACY_SYS_BASE 0x300400
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x20fc
+#define M10BMC_MEM_END 0x1fff
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

[PATCH v4 0/4] Some improvement for Intel MAX 10 MFD drivers

[Xu Yilun]

This patchset is some improvements for intel-m10-bmc and its subdevs.

Main changes from v1:
- Add a patch (#2) to simplify the definition of the legacy version reg.
- Add a patch (#4), add entry in MAINTAINERS for intel-m10-bmc mfd driver
  and the subdev drivers.

Main changes from v2:
- Add Tom Rix as the reviewer for intel-m10-bmc mfd driver and the subdev
  drivers.
- Rebased to 5.12-rc1

Main changes from v3:
- Improve the comments for valid version check.


Matthew Gerlach (1):
  mfd: intel-m10-bmc: Add access table configuration to the regmap

Xu Yilun (3):
  mfd: intel-m10-bmc: Fix the register access range
  mfd: intel-m10-bmc: Simplify the legacy version reg definition
  MAINTAINERS: Add entry for Intel MAX 10 mfd driver

 MAINTAINERS   | 10 ++
 drivers/mfd/intel-m10-bmc.c   | 30 --
 include/linux/mfd/intel-m10-bmc.h |  7 +--
 3 files changed, 35 insertions(+), 12 deletions(-)

-- 
2.7.4

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

[Xu Yilun]

The version register is the only one in the legacy I/O space to be
accessed, so it is not necessary to define the legacy base & version
register offset. A direct definition of the legacy version register
address would be fine.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v3: no change, rebased to 5.12-rc1
v4: improve the comments for valid version check.
---
 drivers/mfd/intel-m10-bmc.c   | 17 +++--
 include/linux/mfd/intel-m10-bmc.h |  2 +-
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index 06c9775..90d0448 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -116,17 +116,14 @@ static int check_m10bmc_version(struct intel_m10bmc 
*ddata)
int ret;
 
/*
-* This check is to filter out the very old legacy BMC versions,
-* M10BMC_LEGACY_SYS_BASE is the offset to this old block of mmio
-* registers. In the old BMC chips, the BMC version info is stored
-* in this old version register (M10BMC_LEGACY_SYS_BASE +
-* M10BMC_BUILD_VER), so its read out value would have not been
-* LEGACY_INVALID (0x). But in new BMC chips that the
-* driver supports, the value of this register should be
-* LEGACY_INVALID.
+* This check is to filter out the very old legacy BMC versions. In the
+* old BMC chips, the BMC version info is stored in the old version
+* register (M10BMC_LEGACY_BUILD_VER), so its read out value would have
+* not been M10BMC_VER_LEGACY_INVALID (0x). But in new BMC
+* chips that the driver supports, the value of this register should be
+* M10BMC_VER_LEGACY_INVALID.
 */
-   ret = m10bmc_raw_read(ddata,
- M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER, );
+   ret = m10bmc_raw_read(ddata, M10BMC_LEGACY_BUILD_VER, );
if (ret)
return -ENODEV;
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 9b54ca1..4f1071f 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -9,7 +9,7 @@
 
 #include 
 
-#define M10BMC_LEGACY_SYS_BASE 0x300400
+#define M10BMC_LEGACY_BUILD_VER0x300468
 #define M10BMC_SYS_BASE0x300800
 #define M10BMC_MEM_END 0x1fff
 
-- 
2.7.4

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

[Xu Yilun]

From: Matthew Gerlach 

This patch adds access tables to the MAX 10 BMC regmap. This prevents
the host from accessing the unwanted I/O space. It also filters out the
invalid outputs when reading the regmap debugfs interface.

Signed-off-by: Matthew Gerlach 
Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Acked-for-MFD-by: Lee Jones 
---
v2: Use the new macro M10BMC_LEGACY_BUILD_VER
v3: No change, rebased to 5.12-rc1
v4: Add Lee's Acked-by, no other change
---
 drivers/mfd/intel-m10-bmc.c   | 13 +
 include/linux/mfd/intel-m10-bmc.h |  5 -
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index 90d0448..1161933 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -23,10 +23,23 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
{ .name = "n3000bmc-secure" },
 };
 
+static const struct regmap_range m10bmc_regmap_range[] = {
+   regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
+   regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
+   regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
+};
+
+static const struct regmap_access_table m10bmc_access_table = {
+   .yes_ranges = m10bmc_regmap_range,
+   .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
+};
+
 static struct regmap_config intel_m10bmc_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
+   .wr_table = _access_table,
+   .rd_table = _access_table,
.max_register = M10BMC_MEM_END,
 };
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 4f1071f..c4eb38c 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,10 @@
 
 #define M10BMC_LEGACY_BUILD_VER0x300468
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x1fff
+#define M10BMC_SYS_END 0x300fff
+#define M10BMC_FLASH_BASE  0x1000
+#define M10BMC_FLASH_END   0x1fff
+#define M10BMC_MEM_END M10BMC_FLASH_END
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

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

[Xu Yilun]

This patch adds maintainer info for Intel MAX 10 mfd driver.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Acked-for-MFD-by: Lee Jones 
---
v3: Add Tom Rix as the reviewer.
v4: Add Lee's Acked-by, no other change.
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b58a469..ab31c01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9116,6 +9116,16 @@ F:   include/linux/mei_cl_bus.h
 F: include/uapi/linux/mei.h
 F: samples/mei/*
 
+INTEL MAX 10 BMC MFD DRIVER
+M: Xu Yilun 
+R: Tom Rix 
+S: Maintained
+F: Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+F: Documentation/hwmon/intel-m10-bmc-hwmon.rst
+F: drivers/hwmon/intel-m10-bmc-hwmon.c
+F: drivers/mfd/intel-m10-bmc.c
+F: include/linux/mfd/intel-m10-bmc.h
+
 INTEL MENLOW THERMAL DRIVER
 M: Sujith Thomas 
 L: platform-driver-...@vger.kernel.org
-- 
2.7.4

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

[Xu Yilun]

On Wed, Mar 10, 2021 at 09:16:25AM +, Lee Jones wrote:
> On Mon, 01 Mar 2021, Xu Yilun wrote:
> 
> > The version register is the only one in the legacy I/O space to be
> > accessed, so it is not necessary to define the legacy base & version
> > register offset. A direct definition of the legacy version register
> > address would be fine.
> > 
> > Signed-off-by: Xu Yilun 
> > Reviewed-by: Tom Rix 
> > ---
> > v3: no change, rebased to 5.12-rc1
> > ---
> >  drivers/mfd/intel-m10-bmc.c   | 12 +---
> >  include/linux/mfd/intel-m10-bmc.h |  2 +-
> >  2 files changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> > index 06c9775..0d2c03f 100644
> > --- a/drivers/mfd/intel-m10-bmc.c
> > +++ b/drivers/mfd/intel-m10-bmc.c
> > @@ -117,16 +117,14 @@ static int check_m10bmc_version(struct intel_m10bmc 
> > *ddata)
> >  
> > /*
> >  * This check is to filter out the very old legacy BMC versions,
> > -* M10BMC_LEGACY_SYS_BASE is the offset to this old block of mmio
> > -* registers. In the old BMC chips, the BMC version info is stored
> > -* in this old version register (M10BMC_LEGACY_SYS_BASE +
> > -* M10BMC_BUILD_VER), so its read out value would have not been
> > -* LEGACY_INVALID (0x). But in new BMC chips that the
> > +* 0x300400 is the offset to this old block of mmio registers. In the
> 
> Not sure we want actual addresses in comments.
> 
> Please reword this to cover just the latest solution.

Will fix it in next version.

Thanks,
Yilun

> 
> > +* old BMC chips, the BMC version info is stored in this old version
> > +* register (0x300400 + 0x68), so its read out value would have not
> > +* been LEGACY_INVALID (0x). But in new BMC chips that the
> >  * driver supports, the value of this register should be
> >  * LEGACY_INVALID.
> >  */
> > -   ret = m10bmc_raw_read(ddata,
> > - M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER, );
> > +   ret = m10bmc_raw_read(ddata, M10BMC_LEGACY_BUILD_VER, );
> > if (ret)
> > return -ENODEV;
> >  
> > diff --git a/include/linux/mfd/intel-m10-bmc.h 
> > b/include/linux/mfd/intel-m10-bmc.h
> > index 9b54ca1..4f1071f 100644
> > --- a/include/linux/mfd/intel-m10-bmc.h
> > +++ b/include/linux/mfd/intel-m10-bmc.h
> > @@ -9,7 +9,7 @@
> >  
> >  #include 
> >  
> > -#define M10BMC_LEGACY_SYS_BASE 0x300400
> > +#define M10BMC_LEGACY_BUILD_VER0x300468
> >  #define M10BMC_SYS_BASE0x300800
> >  #define M10BMC_MEM_END 0x1fff
> >  
> 
> -- 
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 0/4] Some improvement for Intel MAX 10 MFD drivers

[Xu Yilun]

On Mon, Mar 08, 2021 at 09:01:24AM +, Lee Jones wrote:
> On Mon, 08 Mar 2021, Xu Yilun wrote:
> 
> > Hi Lee:
> > 
> > Could you please help on review this patchset? They are some
> > improvements for intel-m10-bmc MFD driver.
> 
> Please don't send contentless pings 1 week after submitting a set.
> 
> Also please refrain from top-posting.
> 
> This patch is on my TO-REVIEW list.
> 
> Unfortunately, since I work in reverse chronological order, you just
> pushed the set to the back of the list.
> 
> If after a suitable period, usually around 2 weeks, you think your
> submission has been missed, please submit a [RESEND] instead.

Thanks for clarification, I'll follow it.

I thought my submission was missed cause I didn't got your response
since v2 at Jan 26, maybe some misunderstanding, so I'm a little hurry
this time. Sorry.

Yilun

> 
> > On Mon, Mar 01, 2021 at 01:59:41PM +0800, Xu Yilun wrote:
> > > This patchset is some improvements for intel-m10-bmc and its subdevs.
> > > 
> > > Main changes from v1:
> > > - Add a patch (#2) to simplify the definition of the legacy version reg.
> > > - Add a patch (#4), add entry in MAINTAINERS for intel-m10-bmc mfd driver
> > >   and the subdev drivers.
> > > 
> > > Main changes from v2:
> > > - Add Tom Rix as the reviewer for intel-m10-bmc mfd driver and the subdev
> > >   drivers.
> > > - Rebased to 5.12-rc1
> > > 
> > > 
> > > Matthew Gerlach (1):
> > >   mfd: intel-m10-bmc: Add access table configuration to the regmap
> > > 
> > > Xu Yilun (3):
> > >   mfd: intel-m10-bmc: Fix the register access range
> > >   mfd: intel-m10-bmc: Simplify the legacy version reg definition
> > >   MAINTAINERS: Add entry for Intel MAX 10 mfd driver
> > > 
> > >  MAINTAINERS   | 10 ++
> > >  drivers/mfd/intel-m10-bmc.c   | 25 ++---
> > >  include/linux/mfd/intel-m10-bmc.h |  7 +--
> > >  3 files changed, 33 insertions(+), 9 deletions(-)
> > > 
> 
> -- 
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 0/4] Some improvement for Intel MAX 10 MFD drivers

[Xu Yilun]

Hi Lee:

Could you please help on review this patchset? They are some
improvements for intel-m10-bmc MFD driver.

Thanks,
Yilun

On Mon, Mar 01, 2021 at 01:59:41PM +0800, Xu Yilun wrote:
> This patchset is some improvements for intel-m10-bmc and its subdevs.
> 
> Main changes from v1:
> - Add a patch (#2) to simplify the definition of the legacy version reg.
> - Add a patch (#4), add entry in MAINTAINERS for intel-m10-bmc mfd driver
>   and the subdev drivers.
> 
> Main changes from v2:
> - Add Tom Rix as the reviewer for intel-m10-bmc mfd driver and the subdev
>   drivers.
> - Rebased to 5.12-rc1
> 
> 
> Matthew Gerlach (1):
>   mfd: intel-m10-bmc: Add access table configuration to the regmap
> 
> Xu Yilun (3):
>   mfd: intel-m10-bmc: Fix the register access range
>   mfd: intel-m10-bmc: Simplify the legacy version reg definition
>   MAINTAINERS: Add entry for Intel MAX 10 mfd driver
> 
>  MAINTAINERS   | 10 ++
>  drivers/mfd/intel-m10-bmc.c   | 25 ++---
>  include/linux/mfd/intel-m10-bmc.h |  7 +--
>  3 files changed, 33 insertions(+), 9 deletions(-)
> 
> -- 
> 2.7.4

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Reviewed-by: Wu Hao 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
v10: no change.
v11: add description that interrupt support is not implemented yet.
v12: rebase to 5.12-rc2, no change
---
 Documentation/fpga/dfl.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..f3a1223 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,31 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+Currently the uio_dfl driver only supports the Ether Group sub feature, which
+has no irq in hardware. So the interrupt handling is not added in this driver.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

[PATCH v12 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

There are some Q about why UIO driver is needed in v11:

>From Greg:
  Why are you saying that an ethernet driver should be using the UIO
  interface?

  And why can't you use the existing UIO drivers that bind to memory
  regions specified by firmware?  Without an interrupt being used, why is
  UIO needed at all?

>From Moritz:
  Essentially I see two options:
  - Have a DFL bus driver instantiate a platform driver (uio_pdrv_genirq)
which I *think* you described above?
  - What this patch implements -- a UIO driver on the DFL bus

  These FPGA devices can on the fly change their contents and -- even if
  just for test -- being able to expose a bunch of registers via UIO can
  be extremely useful.

  Whether a device should expose registers or not should be up to the
  implemeneter of the FPGA design I think (policy). This patch (or the
  previous version) provides a mechanism to do so via DFL.

  This is similar in nature to uio_pdrv_genirq on a DT based platform, to
  expose the registers you instantiate the DT node.

  Re-implementing a new driver for each of these instances doesn't seem
  desirable and tying DFL as enumeration mechanism to UIO seems like a
  good compromise for enabling this kind of functionality.

  Note this is *not* an attempt to bypass the network stack or other
  existing subsystems.

See the original message in:
  
https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m66ba2c96848e3dea38d1a4f16dfea3cb291f7975


>From Yilun:
  The ETH GROUP IP is not designed as the full functional ethernet
  controller. It is specially developed for the Intel N3000 NIC. Since it
  is an FPGA based card, it is designed for the users to runtime reload
  part of the MAC layer logic developed by themselves, while the ETH GROUP
  is another part of the MAC which is not expected to be reloaded by
  customers, but it provides some configurations for software to work with
  the user logic.

  So I category the feature as the devices that "designed for specific
  purposes and does not fit into one of the standard kernel subsystems".
  Some related description could be found in Patch #2, to illustrate why
  using UIO for some DFL devices.

  There are now UIO drivers for PCI or platform devices, but in this case
  we are going to export a DFL(Device Feature List) bus device to
  userspace, a DFL driver for UIO is needed to bind to it.

See the original message in:
  
https://lore.kernel.org/linux-fpga/ydvq8ao8v3nhl...@epycbox.lan/T/#m91b303fd61485644353fad1e1e9c11d528844684


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 26 ++
 MAINTAINERS|  1 +
 drivers/uio/Kconfig| 17 
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 5 files changed, 111 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

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

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v9: switch to add a uio driver in drivers/uio
v10: add the source file in MAINTAINERS
 more descriptive Kconfig header
 add detailed path for opae uio example
v11: no change
v12: rebase to 5.12-rc2, no change
---
 MAINTAINERS   |  1 +
 drivers/uio/Kconfig   | 17 +
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 4 files changed, 85 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85c..b58a469 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6992,6 +6992,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl*
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: drivers/uio/uio_dfl.c
 F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..5531f3a 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,21 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL (Device Feature List) bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ It could be found at:
+
+   opae-sdk/tools/libopaeuio/
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = >mmio_res;
+   struct device *dev = >dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = >mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

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

[Xu Yilun]

This patch adds maintainer info for Intel MAX 10 mfd driver.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v3: Add Tom Rix as the reviewer.
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b58a469..ab31c01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9116,6 +9116,16 @@ F:   include/linux/mei_cl_bus.h
 F: include/uapi/linux/mei.h
 F: samples/mei/*
 
+INTEL MAX 10 BMC MFD DRIVER
+M: Xu Yilun 
+R: Tom Rix 
+S: Maintained
+F: Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+F: Documentation/hwmon/intel-m10-bmc-hwmon.rst
+F: drivers/hwmon/intel-m10-bmc-hwmon.c
+F: drivers/mfd/intel-m10-bmc.c
+F: include/linux/mfd/intel-m10-bmc.h
+
 INTEL MENLOW THERMAL DRIVER
 M: Sujith Thomas 
 L: platform-driver-...@vger.kernel.org
-- 
2.7.4

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

[Xu Yilun]

From: Matthew Gerlach 

This patch adds access tables to the MAX 10 BMC regmap. This prevents
the host from accessing the unwanted I/O space. It also filters out the
invalid outputs when reading the regmap debugfs interface.

Signed-off-by: Matthew Gerlach 
Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v2: Use the new macro M10BMC_LEGACY_BUILD_VER
v3: No change, rebased to 5.12-rc1
---
 drivers/mfd/intel-m10-bmc.c   | 13 +
 include/linux/mfd/intel-m10-bmc.h |  5 -
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index 0d2c03f..1932101 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -23,10 +23,23 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
{ .name = "n3000bmc-secure" },
 };
 
+static const struct regmap_range m10bmc_regmap_range[] = {
+   regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
+   regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
+   regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
+};
+
+static const struct regmap_access_table m10bmc_access_table = {
+   .yes_ranges = m10bmc_regmap_range,
+   .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
+};
+
 static struct regmap_config intel_m10bmc_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
+   .wr_table = _access_table,
+   .rd_table = _access_table,
.max_register = M10BMC_MEM_END,
 };
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 4f1071f..c4eb38c 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,10 @@
 
 #define M10BMC_LEGACY_BUILD_VER0x300468
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x1fff
+#define M10BMC_SYS_END 0x300fff
+#define M10BMC_FLASH_BASE  0x1000
+#define M10BMC_FLASH_END   0x1fff
+#define M10BMC_MEM_END M10BMC_FLASH_END
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

[PATCH v3 1/4] mfd: intel-m10-bmc: Fix the register access range

[Xu Yilun]

This patch fixes the max register address of MAX 10 BMC. The range
0x2000 ~ 0x20fc are for control registers of the QSPI flash
controller, which are not accessible to host.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v2: no change.
v3: no change, rebased to 5.12-rc1
---
 include/linux/mfd/intel-m10-bmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 74d4e19..9b54ca1 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,7 @@
 
 #define M10BMC_LEGACY_SYS_BASE 0x300400
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x20fc
+#define M10BMC_MEM_END 0x1fff
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

[PATCH v3 0/4] Some improvement for Intel MAX 10 MFD drivers

[Xu Yilun]

This patchset is some improvements for intel-m10-bmc and its subdevs.

Main changes from v1:
- Add a patch (#2) to simplify the definition of the legacy version reg.
- Add a patch (#4), add entry in MAINTAINERS for intel-m10-bmc mfd driver
  and the subdev drivers.

Main changes from v2:
- Add Tom Rix as the reviewer for intel-m10-bmc mfd driver and the subdev
  drivers.
- Rebased to 5.12-rc1


Matthew Gerlach (1):
  mfd: intel-m10-bmc: Add access table configuration to the regmap

Xu Yilun (3):
  mfd: intel-m10-bmc: Fix the register access range
  mfd: intel-m10-bmc: Simplify the legacy version reg definition
  MAINTAINERS: Add entry for Intel MAX 10 mfd driver

 MAINTAINERS   | 10 ++
 drivers/mfd/intel-m10-bmc.c   | 25 ++---
 include/linux/mfd/intel-m10-bmc.h |  7 +--
 3 files changed, 33 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[Xu Yilun]

The version register is the only one in the legacy I/O space to be
accessed, so it is not necessary to define the legacy base & version
register offset. A direct definition of the legacy version register
address would be fine.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v3: no change, rebased to 5.12-rc1
---
 drivers/mfd/intel-m10-bmc.c   | 12 +---
 include/linux/mfd/intel-m10-bmc.h |  2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

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

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

[Xu Yilun]

On Sat, Feb 27, 2021 at 04:42:55PM +0100, Greg KH wrote:
> On Sat, Feb 27, 2021 at 11:27:03PM +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 now only binds the ether group feature, which has no irq. So
> > the irq support is not implemented yet.
> > 
> > Signed-off-by: Xu Yilun 
> > Reviewed-by: Tom Rix 
> > ---
> > v9: switch to add a uio driver in drivers/uio
> > v10: add the source file in MAINTAINERS
> >  more descriptive Kconfig header
> >  add detailed path for opae uio example
> > v11: no change
> > ---
> >  MAINTAINERS   |  1 +
> >  drivers/uio/Kconfig   | 17 +
> >  drivers/uio/Makefile  |  1 +
> >  drivers/uio/uio_dfl.c | 66 
> > +++
> >  4 files changed, 85 insertions(+)
> >  create mode 100644 drivers/uio/uio_dfl.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 000fe0b..4dc0354 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6943,6 +6943,7 @@ S:Maintained
> >  F: Documentation/ABI/testing/sysfs-bus-dfl*
> >  F: Documentation/fpga/dfl.rst
> >  F: drivers/fpga/dfl*
> > +F: drivers/uio/uio_dfl.c
> >  F: include/linux/dfl.h
> >  F: include/uapi/linux/fpga-dfl.h
> >  
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index 202ee81..5531f3a 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -165,4 +165,21 @@ config UIO_HV_GENERIC
> >   to network and storage devices from userspace.
> >  
> >   If you compile this as a module, it will be called uio_hv_generic.
> > +
> > +config UIO_DFL
> > +   tristate "Generic driver for DFL (Device Feature List) bus"
> > +   depends on FPGA_DFL
> > +   help
> > + Generic DFL (Device Feature List) driver for Userspace I/O devices.
> > + It is useful to provide direct access to DFL devices from userspace.
> > + A sample userspace application using this driver is available for
> > + download in a git repository:
> > +
> > +   git clone https://github.com/OPAE/opae-sdk.git
> > +
> > + It could be found at:
> > +
> > +   opae-sdk/tools/libopaeuio/
> > +
> > + If you compile this as a module, it will be called uio_dfl.
> >  endif
> > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > index c285dd2..f2f416a1 100644
> > --- a/drivers/uio/Makefile
> > +++ b/drivers/uio/Makefile
> > @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> >  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> >  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
> >  obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
> > +obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
> > diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
> > new file mode 100644
> > index 000..89c0fc7
> > --- /dev/null
> > +++ b/drivers/uio/uio_dfl.c
> > @@ -0,0 +1,66 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Generic DFL driver for Userspace I/O devicess
> > + *
> > + * Copyright (C) 2021 Intel Corporation, Inc.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "uio_dfl"
> > +
> > +static int uio_dfl_probe(struct dfl_device *ddev)
> > +{
> > +   struct resource *r = >mmio_res;
> > +   struct device *dev = >dev;
> > +   struct uio_info *uioinfo;
> > +   struct uio_mem *uiomem;
> > +   int ret;
> > +
> > +   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
> > +   if (!uioinfo)
> > +   return -ENOMEM;
> > +
> > +   uioinfo->name = DRIVER_NAME;
> > +   uioinfo->version = "0";
> > +
> > +   uiomem = >mem[0];
> > +   uiomem->memtype = UIO_MEM_PHYS;
> > +   uiomem->addr = r->start & PAGE_MASK;
> > +   uiomem->offs = r->start & ~PAGE_MASK;
> > +   uiomem->size = (uiomem->offs + resource_size(r)
> > +   + PAGE_SIZE - 1) & PAGE_MASK;
> > +   uiomem->name = r->name;
> > +
> > +   /* Irq is yet to be supported */
> > +   uioinfo->irq = UIO_IRQ_NONE;
> > +
> > +   ret = devm_uio_register_device(dev, uioinfo);
> > +   if (ret)
> > +   dev_err(dev, "unable to register uio device\n");
> >

[RESEND PATCH v11 2/2] Documentation: fpga: dfl: Add description for DFL UIO support

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Reviewed-by: Wu Hao 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
v10: no change.
v11: add description that interrupt support is not implemented yet.
---
 Documentation/fpga/dfl.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..f3a1223 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,31 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+Currently the uio_dfl driver only supports the Ether Group sub feature, which
+has no irq in hardware. So the interrupt handling is not added in this driver.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v9: switch to add a uio driver in drivers/uio
v10: add the source file in MAINTAINERS
 more descriptive Kconfig header
 add detailed path for opae uio example
v11: no change
---
 MAINTAINERS   |  1 +
 drivers/uio/Kconfig   | 17 +
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 4 files changed, 85 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 000fe0b..4dc0354 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6943,6 +6943,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl*
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: drivers/uio/uio_dfl.c
 F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..5531f3a 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,21 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL (Device Feature List) bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ It could be found at:
+
+   opae-sdk/tools/libopaeuio/
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = >mmio_res;
+   struct device *dev = >dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = >mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

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

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq
support is not implemented yet.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Main changes from v8:
- switch to add a uio driver in drivers/uio

Main changes from v9:
- add this source file in MAINTAINERS
- improve the Kconfig, add more descriptive Kconfig header, add detailed
  path for opae uio example in Kconfig.

Main changes from v10:
- add description in doc that interrupt support is not implemented yet.


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 26 ++
 MAINTAINERS|  1 +
 drivers/uio/Kconfig| 17 
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 5 files changed, 111 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

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

[Xu Yilun]

Hi Greg:

On Fri, Feb 26, 2021 at 07:40:56AM +0100, Greg KH wrote:
> On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > > Yilun,
> > > 
> > > Is there anything outstanding or remaining to be done ?
> > 
> > Sorry for late reply. No, this is my lastest version now.
> > 
> > 
> > Hi Greg:
> > 
> > Do you have some comments on this patchset?
> 
> It's the middle of the merge window, I can't accept anything right
> now...
> 
> But this doesn't even look like it is in my "to review" queue anymore,
> which means that there must have been a lot of discussion on it and
> others asking for changes, so why not work on that right now while you
> can and resubmit it when you have done that?
> 
> No need to ever wait on me for fixing things up.

I checked the mails again and confirmed all the comments from Moritz,
Tom and Hao are fixed. So could you help review it so it could be
accepted in next cycle?

Thanks,
Yilun

> 
> greg k-h

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

[Xu Yilun]

On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> Yilun,
> 
> Is there anything outstanding or remaining to be done ?

Sorry for late reply. No, this is my lastest version now.


Hi Greg:

Do you have some comments on this patchset?

Thanks,
Yilun

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

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Reviewed-by: Wu Hao 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
v10: no change.
v11: add description that interrupt support is not implemented yet.
---
 Documentation/fpga/dfl.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..f3a1223 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,31 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+Currently the uio_dfl driver only supports the Ether Group sub feature, which
+has no irq in hardware. So the interrupt handling is not added in this driver.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v9: switch to add a uio driver in drivers/uio
v10: add the source file in MAINTAINERS
 more descriptive Kconfig header
 add detailed path for opae uio example
v11: no change
---
 MAINTAINERS   |  1 +
 drivers/uio/Kconfig   | 17 +
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 4 files changed, 85 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 000fe0b..4dc0354 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6943,6 +6943,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl*
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: drivers/uio/uio_dfl.c
 F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..5531f3a 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,21 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL (Device Feature List) bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ It could be found at:
+
+   opae-sdk/tools/libopaeuio/
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = >mmio_res;
+   struct device *dev = >dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = >mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

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

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the 
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new 
DFL devices which are not supported by kernel. The concern is the UIO may 
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq 
support is not implemented yet.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Main changes from v8:
- switch to add a uio driver in drivers/uio

Main changes from v9:
- add this source file in MAINTAINERS
- improve the Kconfig, add more descriptive Kconfig header, add detailed
  path for opae uio example in Kconfig.

Main changes from v10:
- add description in doc that interrupt support is not implemented yet.


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 26 ++
 MAINTAINERS|  1 +
 drivers/uio/Kconfig| 17 
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 5 files changed, 111 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

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

[Xu Yilun]

On Mon, Feb 01, 2021 at 08:59:06PM +0800, Wu, Hao wrote:
> > Subject: [PATCH v10 2/2] Documentation: fpga: dfl: Add description for DFL 
> > UIO
> > support
> >
> > This patch adds description for UIO support for dfl devices on DFL
> > bus.
> >
> > Signed-off-by: Xu Yilun 
> > Reviewed-by: Tom Rix 
> > ---
> > v2: no doc in v1, add it for v2.
> > v3: some documentation fixes.
> > v4: documentation change since the driver matching is changed.
> > v5: no change.
> > v6: improve the title of the userspace driver support section.
> > some word improvement.
> > v7: rebased to next-20210119
> > v8: some doc fixes.
> > v9: some doc change since we switch to the driver in drivers/uio.
> > v10: no change.
> > ---
> >  Documentation/fpga/dfl.rst | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index c41ac76..e35cf87 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -7,6 +7,7 @@ Authors:
> >  - Enno Luebbers 
> >  - Xiao Guangrong 
> >  - Wu Hao 
> > +- Xu Yilun 
> >
> >  The Device Feature List (DFL) FPGA framework (and drivers according to
> >  this framework) hides the very details of low layer hardwares and provides
> > @@ -530,6 +531,28 @@ Being able to specify more than one DFL per BAR has
> > been considered, but it
> >  was determined the use case did not provide value.  Specifying a single DFL
> >  per BAR simplifies the implementation and allows for extra error checking.
> >
> > +
> > +Userspace driver support for DFL devices
> > +
> > +The purpose of an FPGA is to be reprogrammed with newly developed
> > hardware
> > +components. New hardware can instantiate a new private feature in the DFL,
> > and
> > +then present a DFL device in the system. In some cases users may need a
> > +userspace driver for the DFL device:
> > +
> > +* Users may need to run some diagnostic test for their hardware.
> > +* Users may prototype the kernel driver in user space.
> > +* Some hardware is designed for specific purposes and does not fit into 
> > one of
> > +  the standard kernel subsystems.
> > +
> > +This requires direct access to MMIO space and interrupt handling from
> > +userspace. The uio_dfl module exposes the UIO device interfaces for this
> > +purpose.
> 
> Current uio_dfl doesn't have interrupt handling support, right? I guess we 
> need
> to make sure no confusion on the description here. other place looks good to 
> me.

Will fix it.

Thanks,
Yilun

[PATCH v10 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the 
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new 
DFL devices which are not supported by kernel. The concern is the UIO may 
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq 
support is not implemented yet.


Main changes from v1: 
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2: 
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3: 
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4: 
- refactor the irq handling code.

Main changes from v5: 
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6: 
- use platform_device_register_resndata() for pdev creation.

Main changes from v7: 
- some doc fixes.

Main changes from v8:
- switch to add a uio driver in drivers/uio

Main changes from v9:
- add this source file in MAINTAINERS
- improve the Kconfig, add more descriptive Kconfig header, add detailed
  path for opae uio example in Kconfig.


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 23 
 MAINTAINERS|  1 +
 drivers/uio/Kconfig| 17 
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 5 files changed, 108 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
v10: no change.
---
 Documentation/fpga/dfl.rst | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..e35cf87 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,28 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
---
v9: switch to add a uio driver in drivers/uio
v10: add the source file in MAINTAINERS
 more descriptive Kconfig header
 add detailed path for opae uio example
---
 MAINTAINERS   |  1 +
 drivers/uio/Kconfig   | 17 +
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 4 files changed, 85 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 147d1d9..4d01a21 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6943,6 +6943,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl*
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: drivers/uio/uio_dfl.c
 F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..5531f3a 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,21 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL (Device Feature List) bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ It could be found at:
+
+   opae-sdk/tools/libopaeuio/
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = >mmio_res;
+   struct device *dev = >dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = >mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

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

[Xu Yilun]

On Tue, Jan 26, 2021 at 07:06:17AM -0800, Tom Rix wrote:
> 
> On 1/25/21 10:50 PM, Xu Yilun wrote:
> > This patch adds maintainer info for Intel MAX 10 mfd driver.
> >
> > Signed-off-by: Xu Yilun 
> > ---
> >  MAINTAINERS | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5aa18cb..10985d3 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9132,6 +9132,15 @@ F:   include/linux/mei_cl_bus.h
> >  F: include/uapi/linux/mei.h
> >  F: samples/mei/*
> >  
> 
> I am interested in reviewing these files like I do with
> 
> FPGA DFL DRIVERS
> 
> So can you add
> 
> R:    Tom Rix 
> 
> if you have to rev this patchset ?

It's good to me. I'll add it if I need to send v3.

Thanks,
Yilun

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

[PATCH v9 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq
support is not implemented yet.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Main changes from v9:
- switch to add a uio driver in drivers/uio 

Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 23 
 drivers/uio/Kconfig| 13 +
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 4 files changed, 103 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

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

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
---
v9: switch to add a uio driver in drivers/uio
---
 drivers/uio/Kconfig   | 13 ++
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 3 files changed, 80 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..44778f8 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,17 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = >mmio_res;
+   struct device *dev = >dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = >mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

[PATCH v2 1/4] mfd: intel-m10-bmc: Fix the register access range

[Xu Yilun]

This patch fixes the max register address of MAX 10 BMC. The range
0x2000 ~ 0x20fc are for control registers of the QSPI flash
controller, which are not accessible to host.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v2: no change.
---
 include/linux/mfd/intel-m10-bmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index c8ef2f1..06da62c 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,7 @@
 
 #define M10BMC_LEGACY_SYS_BASE 0x300400
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x20fc
+#define M10BMC_MEM_END 0x1fff
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

[PATCH v2 0/4] Some improvement for Intel MAX 10 MFD drivers

[Xu Yilun]

This patchset is some improvements for intel-m10-bmc and its subdevs.

Main changes from v1:
- Add a patch (#2) to simplify the definition of the legacy version reg.
- Add a patch (#4), add entry in MAINTAINERS for intel-m10-bmc mfd driver
  and the subdev drivers.

Matthew Gerlach (1):
  mfd: intel-m10-bmc: Add access table configuration to the regmap

Xu Yilun (3):
  mfd: intel-m10-bmc: Fix the register access range
  mfd: intel-m10-bmc: Simplify the legacy version reg definition
  MAINTAINERS: Add entry for Intel MAX 10 mfd driver

 MAINTAINERS   |  9 +
 drivers/mfd/intel-m10-bmc.c   | 25 ++---
 include/linux/mfd/intel-m10-bmc.h |  7 +--
 3 files changed, 32 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[Xu Yilun]

From: Matthew Gerlach 

This patch adds access tables to the MAX 10 BMC regmap. This prevents
the host from accessing the unwanted I/O space. It also filters out the
invalid outputs when reading the regmap debugfs interface.

Signed-off-by: Matthew Gerlach 
Signed-off-by: Xu Yilun 
---
v2: no change.
---
 drivers/mfd/intel-m10-bmc.c   | 13 +
 include/linux/mfd/intel-m10-bmc.h |  5 -
 2 files changed, 17 insertions(+), 1 deletion(-)

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

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

[Xu Yilun]

This patch adds maintainer info for Intel MAX 10 mfd driver.

Signed-off-by: Xu Yilun 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5aa18cb..10985d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9132,6 +9132,15 @@ F:   include/linux/mei_cl_bus.h
 F: include/uapi/linux/mei.h
 F: samples/mei/*
 
+INTEL MAX 10 BMC MFD DRIVER
+M: Xu Yilun 
+S: Maintained
+F: Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+F: Documentation/hwmon/intel-m10-bmc-hwmon.rst
+F: drivers/hwmon/intel-m10-bmc-hwmon.c
+F: drivers/mfd/intel-m10-bmc.c
+F: include/linux/mfd/intel-m10-bmc.h
+
 INTEL MENLOW THERMAL DRIVER
 M: Sujith Thomas 
 L: platform-driver-...@vger.kernel.org
-- 
2.7.4

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

[Xu Yilun]

The version register is the only one in the legacy I/O space to be
accessed, so it is not necessary to define the legacy base & version
register offset. A direct definition of the legacy version register
address would be fine.

Signed-off-by: Xu Yilun 
---
 drivers/mfd/intel-m10-bmc.c   | 12 +---
 include/linux/mfd/intel-m10-bmc.h |  2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

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

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

[Xu Yilun]

On Mon, Jan 25, 2021 at 06:22:55PM -0800, Moritz Fischer wrote:
> On Mon, Jan 25, 2021 at 11:00:38AM -0800, Tom Rix wrote:
> > 
> > On 1/25/21 12:49 AM, Xu Yilun wrote:
> > > This patch supports the DFL drivers be written in userspace. This is
> > > realized by exposing the userspace I/O device interfaces.
> > >
> > > The driver now only binds the ether group feature, which has no irq. So
> > > the irq support is not implemented yet.
> > >
> > > Signed-off-by: Xu Yilun 
> > > ---
> > > v9: switch to add a uio driver in drivers/uio
> > > ---
> > >  drivers/uio/Kconfig   | 13 ++
> > >  drivers/uio/Makefile  |  1 +
> > >  drivers/uio/uio_dfl.c | 66 
> > > +++
> > 
> > You should add this to the MAINTAINERS file.
> 
> This is covered by MAINTAINERS under drivers/uio.

Yes. But is it OK I also add the file in "FPGA DFL DRIVERS"? So DFL
developers would also be aware if there is change. It is a little
different from other feature driver, it is like a generic driver for
DFL bus.

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

Do you mean the OPAE link? I see several uio drivers provide their
userspace application link in Kconfig. I guess the uio drivers are
selected for these applications so it may be better pointing out where
they are.

Thanks,
Yilun

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

[Xu Yilun]

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

OK. I could add recored the file under "FPGA DFL DRIVERS"

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

The bus is named as "DFL bus", how about we add the full name like the
following help message.

  tristate "Generic driver for DFL (Device Feature List) bus"

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

You can find the example in tools/libopaeuio/. I could add the path in
help message.

Thanks,
Yilun

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

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
---
 Documentation/fpga/dfl.rst | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..e35cf87 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,28 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

On Thu, Jan 21, 2021 at 12:03:47PM -0800, Moritz Fischer wrote:
> Hi Tom,
> 
> On Thu, Jan 21, 2021 at 06:30:20AM -0800, Tom Rix wrote:
> > 
> > On 1/17/21 8:22 AM, Moritz Fischer wrote:
> > > Greg,
> > >
> > > On Sun, Jan 17, 2021 at 04:45:04PM +0100, Greg KH wrote:
> > >> On Wed, Jan 13, 2021 at 09:54:07AM +0800, Xu Yilun wrote:
> > >>> This patch supports the DFL drivers be written in userspace. This is
> > >>> realized by exposing the userspace I/O device interfaces.
> > >>>
> > >>> The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
> > >>> platform device with the DFL device's resources, and let the generic UIO
> > >>> platform device driver provide support to userspace access to kernel
> > >>> interrupts and memory locations.
> > >> Why doesn't the existing uio driver work for this, why do you need a new
> > >> one?
> > >>
> > >>> ---
> > >>>  drivers/fpga/Kconfig| 10 +
> > >>>  drivers/fpga/Makefile   |  1 +
> > >>>  drivers/fpga/dfl-uio-pdev.c | 93 
> > >>> +
> > >> uio drivers traditionally go in drivers/uio/ and start with "uio", so
> > >> shouldn't this be drivers/uio/uio_dfl_pdev.c to match the same naming
> > >> scheme?
> > > I had considered suggesting that, but ultimately this driver only
> > > creates a 'uio_pdrv_genirq' platform device, so it didn't seem like a
> > > good fit.
> > >> But again, you need to explain in detail, why the existing uio driver
> > >> doesn't work properly, or why you can't just add a few lines to an
> > >> existing one.
> > > Ultimately there are three options I see:
> > > 1) Do what Xu does, which is re-use the 'uio_pdrv_genirq' uio driver by
> > >   creating a platform device for it as sub-device of the dfl device that
> > >   we bind to uio_pdrv_genirq
> > > 2) Add a module_dfl_driver part to drivers/uio/uio_pdrv_genirq.c and
> > >   corresponding id table
> > > 3) Create a new uio_dfl_genirq kind of driver that uses the dfl bus and
> > >   that would make sense to then put into drivers/uio. (This would
> > >   duplicate code in uio_pdrv_genirq to some extend)
> > >
> > > Overall I think in terms of code re-use I think Xu's choice might be
> > > less new code as it simply wraps the uio platform device driver, and
> > > allows for defining the resources passed to the UIO driver to be defined
> > > by hardware through a DFL.
> > >
> > > I've seen the pattern that Xu proposed used in other places like the
> > > macb network driver where you'd have macb_main (the platform driver) and
> > > macb_pci that wraps it for a pci usage.
> > >
> > > - Moritz
> > 
> > Thinking of this problem more generally.
> > 
> > Every fpga will have a handful of sub devices.
> > 
> > Do we want to carry them in the fpga subsystem or carry them in the other 
> > subsystems ?
> 
> Yeah no we really don't. I think that was the point of the whole DFL
> bus :)
> > 
> > Consider the short term reviewing and long term maintenance of the sub 
> > devices by the subsystem maintainers.
> > 
> > It easier for them if the sub devices are in the other subsystems.
> 
> Agreed.
> > 
> > 
> > Applying this to specifically for dfl_uio.
> > 
> > No one from the uio subsystem reviewing this change is a problem.
> 
> Greg will.
> > I think this change needs to go to the uio subsystem.
> 
> Yeah I've thought about this some for the last few days, maybe it's
> easier that way.
> 
> Tbh, there's so little code here even if we went with option 3 above
> it's probably fairly short. It would set a better prcedent.
> 
> Xu, how do you feel about giving that a spin? See if option 3 will be
> way more code.

Yes, I'll try to put it to drivers/uio.

I see the implementation in vfio_platform.c/vfio_amba.c/vfio_platform_common.c.
I'm wondering if we could handle it in that way.

Thanks,
yilun

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

[Xu Yilun]

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

It looks hacky to me.

If the first one has to be marked RO, I think it could be like:

  static const struct regmap_range m10bmc_regmap_ro_range[] = {
regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
  };

  static const struct regmap_range m10bmc_regmap_range[] = {
regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
regmap_reg_range(...),
...
  };

  static const struct regmap_access_table m10bmc_write_table = {
.yes_ranges = m10bmc_regmap_range,
.n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
.no_range   = m10bmc_regmap_ro_range,
.n_no_range = ARRAY_SIZE(m10bmc_regmap_ro_range),
  };

  static const struct regmap_access_table m10bmc_read_table = {
.yes_ranges = m10bmc_regmap_range,
.n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
  };

But I think this is unnecessary. I feel it is indicating all the other
registers are RW in spec, actually they are not. So I tend to keep
it simple, just tell the valid range.

Thanks,
Yilun

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
---
 Documentation/fpga/dfl.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..14b8413 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,30 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module driver.
+To support a new DFL feature via UIO direct access, its feature id should be
+added to the driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

[PATCH v8 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Xu Yilun (2):
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  | 25 ++
 drivers/fpga/Kconfig| 10 ++
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 84 +
 4 files changed, 120 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

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

[Xu Yilun]

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().
v7: use platform_device_register_resndata() for pdev creation.
remove some unnecessary head file includings.
some minor fixes.
v8: no change.
---
 drivers/fpga/Kconfig| 10 ++
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 84 +
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5ff9438..0a21bf2 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 DFL drivers to be written in userspace. 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 000..9572ffd
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,84 @@
+// 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 
+
+#define DRIVER_NAME "dfl-uio-pdev"
+
+static int dfl_uio_pdev_probe(struct dfl_device *ddev)
+{
+   struct resource res[2] = { { 0 } };
+   struct uio_info uio_pdata = { 0 };
+   struct platform_device *uio_pdev;
+   struct device *dev = >dev;
+   unsigned int num_res = 1;
+
+   res[0].parent = >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(dev,
+"%d irqs for %s, but UIO only supports the 
first one\n",
+ddev->num_irqs, dev_name(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";
+
+   uio_pdev = platform_device_register_resndata(dev,
+"uio_pdrv_genirq",
+PLATFORM_DEVID_AUTO,
+res, num_res,
+_pdata,
+sizeof(uio_pdata));
+   if (IS_ERR(uio_pdev))
+   return PTR_ERR(uio_pdev);
+
+   dev_set_drvdata(dev, uio_pdev);
+
+   

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

[Xu Yilun]

On Wed, Jan 20, 2021 at 07:32:53AM -0800, Tom Rix wrote:
> 
> On 1/19/21 6:34 PM, Xu Yilun wrote:
> > From: Matthew Gerlach 
> >
> > This patch adds access tables to the MAX 10 BMC regmap. This prevents
> > the host from accessing the unwanted I/O space. It also filters out the
> > invalid outputs when reading the regmap debugfs interface.
> >
> > Signed-off-by: Matthew Gerlach 
> > Signed-off-by: Xu Yilun 
> > ---
> >  drivers/mfd/intel-m10-bmc.c   | 14 ++
> >  include/linux/mfd/intel-m10-bmc.h |  5 -
> >  2 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> > index b84579b..0ae3053 100644
> > --- a/drivers/mfd/intel-m10-bmc.c
> > +++ b/drivers/mfd/intel-m10-bmc.c
> > @@ -23,10 +23,24 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
> > { .name = "n3000bmc-secure" },
> >  };
> >  
> > +static const struct regmap_range m10bmc_regmap_range[] = {
> > +   regmap_reg_range(M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER,
> > +M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER),
> 
> If this is the only value in the legacy map to be accessed, could it have its 
> own #define ?
> 
> Something like
> 
> #define M10BMC_LEGACY_BUILD_VER ?

Yes, it could be more clear. I'll change it.

> 
> > +   regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
> > +   regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
> > +};
> > +
> > +static const struct regmap_access_table m10bmc_access_table = {
> > +   .yes_ranges = m10bmc_regmap_range,
> > +   .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
> > +};
> > +
> >  static struct regmap_config intel_m10bmc_regmap_config = {
> > .reg_bits = 32,
> > .val_bits = 32,
> > .reg_stride = 4,
> > +   .wr_table = _access_table,
> > +   .rd_table = _access_table,
> 
> The legacy build ver should only be read, so shouldn't these tables be 
> different ?

I'm not sure if a register could be regarded as writable if hardware
ensures writing it has no effect but makes no harm. Usually these
registers are marked as RO in spec.

I think it could be quite common case in hardware design. But it could
be trivial if we pick every such register out of wr_table. I just want
to define the valid reg range.

So could I keep the current implementation?

Thanks,
Yilun

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

[Xu Yilun]

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

Thanks for the fix. Looks good to me.

Yilun

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

[Xu Yilun]

From: Matthew Gerlach 

This patch adds access tables to the MAX 10 BMC regmap. This prevents
the host from accessing the unwanted I/O space. It also filters out the
invalid outputs when reading the regmap debugfs interface.

Signed-off-by: Matthew Gerlach 
Signed-off-by: Xu Yilun 
---
 drivers/mfd/intel-m10-bmc.c   | 14 ++
 include/linux/mfd/intel-m10-bmc.h |  5 -
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index b84579b..0ae3053 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -23,10 +23,24 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
{ .name = "n3000bmc-secure" },
 };
 
+static const struct regmap_range m10bmc_regmap_range[] = {
+   regmap_reg_range(M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER,
+M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER),
+   regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
+   regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
+};
+
+static const struct regmap_access_table m10bmc_access_table = {
+   .yes_ranges = m10bmc_regmap_range,
+   .n_yes_ranges   = ARRAY_SIZE(m10bmc_regmap_range),
+};
+
 static struct regmap_config intel_m10bmc_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
+   .wr_table = _access_table,
+   .rd_table = _access_table,
.max_register = M10BMC_MEM_END,
 };
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index 06da62c..4ba88ed 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,10 @@
 
 #define M10BMC_LEGACY_SYS_BASE 0x300400
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x1fff
+#define M10BMC_SYS_END 0x300fff
+#define M10BMC_FLASH_BASE  0x1000
+#define M10BMC_FLASH_END   0x1fff
+#define M10BMC_MEM_END M10BMC_FLASH_END
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

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

[Xu Yilun]

On Tue, Jan 19, 2021 at 07:12:24PM -0800, Randy Dunlap wrote:
> Doc suggestions:
> 
> On 1/19/21 6:43 PM, Xu Yilun wrote:
> > This patch adds description for UIO support for dfl devices on DFL
> > bus.
> > 
> > Signed-off-by: Xu Yilun 
> > ---
> > v2: no doc in v1, add it for v2.
> > v3: some documentation fixes.
> > v4: documentation change since the driver matching is changed.
> > v5: no change.
> > v6: improve the title of the userspace driver support section.
> > some word improvement.
> > v7: rebased to next-20210119
> > ---
> >  Documentation/fpga/dfl.rst | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index c41ac76..f96a6fb 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -7,6 +7,7 @@ Authors:
> >  - Enno Luebbers 
> >  - Xiao Guangrong 
> >  - Wu Hao 
> > +- Xu Yilun 
> >  
> >  The Device Feature List (DFL) FPGA framework (and drivers according to
> >  this framework) hides the very details of low layer hardwares and provides
> > @@ -530,6 +531,30 @@ Being able to specify more than one DFL per BAR has 
> > been considered, but it
> >  was determined the use case did not provide value.  Specifying a single DFL
> >  per BAR simplifies the implementation and allows for extra error checking.
> >  
> > +
> > +Userspace driver support for DFL devices
> > +
> > +The purpose of an FPGA is to be reprogrammed with newly developed hardware
> > +components. New hardware can instantiate a new private feature in the DFL, 
> > and
> > +then get a DFL device in their system. In some cases users may need a 
> > userspace
> 
>then present a DFL device in the system.
> 
> > +driver for the DFL device:
> > +
> > +* Users may need to run some diagnostic test for their hardwares.
> 
>   hardware.
> 
> > +* Users may prototype the kernel driver in user space.
> > +* Some hardware is designed for specific purposes and does not fit into 
> > one of
> > +  the standard kernel subsystems.
> > +
> > +This requires direct access to MMIO space and interrupt handling from
> > +userspace. The dfl-uio-pdev module exposes the UIO device interfaces for 
> > this
> > +purpose. It adds the uio_pdrv_genirq platform device with the resources of
> > +the DFL feature, and lets the generic UIO platform device driver provide 
> > UIO
> > +support to userspace.
> > +
> > +FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module 
> > driver.
> > +To support a new DFL feature been directly accessed via UIO, its feature id
> 
>To support a new DFL feature via UIO direct access, its feature id

Thanks for the fixes. Will fix them all.

Yilun

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
---
 Documentation/fpga/dfl.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..f96a6fb 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,30 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then get a DFL device in their system. In some cases users may need a userspace
+driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardwares.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module driver.
+To support a new DFL feature been directly accessed via UIO, its feature id
+should be added to the driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

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().
v7: use platform_device_register_resndata() for pdev creation.
remove some unnecessary head file includings.
some minor fixes.
---
 drivers/fpga/Kconfig| 10 ++
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 84 +
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5ff9438..0a21bf2 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 DFL drivers to be written in userspace. 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 000..9572ffd
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,84 @@
+// 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 
+
+#define DRIVER_NAME "dfl-uio-pdev"
+
+static int dfl_uio_pdev_probe(struct dfl_device *ddev)
+{
+   struct resource res[2] = { { 0 } };
+   struct uio_info uio_pdata = { 0 };
+   struct platform_device *uio_pdev;
+   struct device *dev = >dev;
+   unsigned int num_res = 1;
+
+   res[0].parent = >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(dev,
+"%d irqs for %s, but UIO only supports the 
first one\n",
+ddev->num_irqs, dev_name(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";
+
+   uio_pdev = platform_device_register_resndata(dev,
+"uio_pdrv_genirq",
+PLATFORM_DEVID_AUTO,
+res, num_res,
+_pdata,
+sizeof(uio_pdata));
+   if (IS_ERR(uio_pdev))
+   return PTR_ERR(uio_pdev);
+
+   dev_set_drvdata(dev, uio_pdev);
+
+   return 0;

[PATCH v7 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.


Xu Yilun (2):
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  | 25 ++
 drivers/fpga/Kconfig| 10 ++
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 84 +
 4 files changed, 120 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

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

[Xu Yilun]

This patch fixes the max register address of MAX 10 BMC. The range
0x2000 ~ 0x20fc are for control registers of the QSPI flash
controller, which are not accessible to host.

Signed-off-by: Xu Yilun 
---
 include/linux/mfd/intel-m10-bmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index c8ef2f1..06da62c 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -11,7 +11,7 @@
 
 #define M10BMC_LEGACY_SYS_BASE 0x300400
 #define M10BMC_SYS_BASE0x300800
-#define M10BMC_MEM_END 0x20fc
+#define M10BMC_MEM_END 0x1fff
 
 /* Register offset of system registers */
 #define NIOS2_FW_VERSION   0x0
-- 
2.7.4

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

[Xu Yilun]

On Sat, Jan 16, 2021 at 07:57:48PM -0800, Moritz Fischer wrote:
> Hi Xu,
> 
> On Wed, Jan 13, 2021 at 09:54:08AM +0800, Xu Yilun wrote:
> > This patch adds description for UIO support for dfl devices on DFL
> > bus.
> > 
> > Signed-off-by: Xu Yilun 
> > ---
> > v2: no doc in v1, add it for v2.
> > v3: some documentation fixes.
> > v4: documentation change since the driver matching is changed.
> > v5: no change.
> > v6: improve the title of the userspace driver support section.
> > some word improvement.
> > ---
> >  Documentation/fpga/dfl.rst | 24 
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index 0404fe6..c33b6d0 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -7,6 +7,7 @@ Authors:
> >  - Enno Luebbers 
> >  - Xiao Guangrong 
> >  - Wu Hao 
> > +- Xu Yilun 
> >  
> >  The Device Feature List (DFL) FPGA framework (and drivers according to
> >  this framework) hides the very details of low layer hardwares and provides
> > @@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see 
> > drivers/fpga/dfl-fme-pr.c)
> >  could be a reference.
> >  
> >  
> > +Userspace driver support for DFL devices
> > +
> > +The purpose of an FPGA is to be reprogrammed with newly developed hardware
> > +components. New hardware can instantiate a new private feature in the DFL, 
> > and
> > +then get a DFL device in their system. In some cases users may need a 
> > userspace
> > +driver for the DFL device:
> > +
> > +* Users may need to run some diagnostic test for their hardwares.
> > +* Users may prototype the kernel driver in user space.
> > +* Some hardware is designed for specific purposes and does not fit into 
> > one of
> > +  the standard kernel subsystems.
> > +
> > +This requires direct access to MMIO space and interrupt handling from
> > +userspace. The dfl-uio-pdev module exposes the UIO device interfaces for 
> > this
> > +purpose. It adds the uio_pdrv_genirq platform device with the resources of
> > +the DFL feature, and lets the generic UIO platform device driver provide 
> > UIO
> > +support to userspace.
> > +
> > +FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module 
> > driver.
> > +To support a new DFL feature been directly accessed via UIO, its feature id
> > +should be added to the driver's id_table.
> > +
> > +
> >  Open discussion
> >  ===
> >  FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial 
> > reconfiguration
> > -- 
> > 2.7.4
> > 
> 
> Looks fine to me, can you resend with changes for the other patch?

Yes, I will. I may wait for a while to check more comments from Greg.

Thanks,
Yilun

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

[Xu Yilun]

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 000..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 = >dev;
> > +   unsigned int num_res = 1;
> > +
> > +   res[0].parent = >mmio_res;
> > +   res[0].flags = IORESOURCE_MEM;
> > +   res[0].start = ddev->mmio_res.start;
> > +  

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
---
 Documentation/fpga/dfl.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 0404fe6..c33b6d0 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see 
drivers/fpga/dfl-fme-pr.c)
 could be a reference.
 
 
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then get a DFL device in their system. In some cases users may need a userspace
+driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardwares.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module driver.
+To support a new DFL feature been directly accessed via UIO, its feature id
+should be added to the driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

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
+ 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 000..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 = >dev;
+   unsigned int num_res = 1;
+
+   res[0].parent = >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(>dev,
+"%d irqs for %s, but UIO only supports the 
first one\n",
+ddev->num_irqs, dev_name(>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 = >dev;
+   pdevinfo.id = PLATFORM_DEVID_AUTO;
+   pdevinfo.data = _pdata;
+   pdevinfo.size_data = sizeof(uio_pdata);
+
+   uio_pdev = platform_device_register_full();
+   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(>dev);
+

[PATCH v6 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.


Xu Yilun (2):
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  | 24 
 drivers/fpga/Kconfig| 10 +
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 93 +
 4 files changed, 128 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

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

[Xu Yilun]

On Mon, Jan 11, 2021 at 06:59:10AM -0800, Tom Rix wrote:
> 
> On 1/10/21 10:16 PM, Xu Yilun wrote:
> > On Sun, Jan 10, 2021 at 12:11:17PM -0800, Moritz Fischer wrote:
> >> On Sat, Jan 02, 2021 at 11:13:01AM +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 
> >>> ---
> >>> 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.
> >>> ---
> >>>  drivers/fpga/Kconfig| 10 +
> >>>  drivers/fpga/Makefile   |  1 +
> >>>  drivers/fpga/dfl-uio-pdev.c | 91 
> >>> +
> >>>  3 files changed, 102 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
> >>> +   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 000..a4cd581
> >>> --- /dev/null
> >>> +++ b/drivers/fpga/dfl-uio-pdev.c
> >>> @@ -0,0 +1,91 @@
> >>> +// 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_

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

[Xu Yilun]

On Sun, Jan 10, 2021 at 11:58:44AM -0800, Moritz Fischer wrote:
> Hi Xu,
> 
> On Sat, Jan 02, 2021 at 11:13:00AM +0800, Xu Yilun wrote:
> > This patchset supports some dfl device drivers written in userspace.
> > 
> > In the patchset v1, the "driver_override" interface should be used to bind
> > the DFL UIO driver to DFL devices. But there is concern that the
> > "driver_override" interface is not OK itself.
> > 
> > In v2, we use a new matching algorithem. The "driver_override" interface
> > is abandoned, the DFL UIO driver matches any DFL device which could not be
> > handled by other DFL drivers. So the DFL UIO driver could be used for new
> > DFL devices which are not supported by kernel. The concern is the UIO may
> > not be suitable as a default/generic driver for all dfl features, such as
> > features with multiple interrupts.
> > 
> > In v4, we specify each matching device in the id_table of the UIO driver,
> > just the same as other dfl drivers do. Now the UIO driver supports Ether
> > Group feature. To support more DFL features, their feature ids should be
> > added to the driver's id_table.
> 
> I think this is what you want, yes. Instead of doing a driver override
> or such, add devices that should always be bound to UIO to a device id
> table. For those you temporarily want to bind, make sure you can unbind
> them and use 'new_id' or 'bind' in sysfs, similar to what sysfs does.

"new_id" is not generic to all bus drivers, we need to add the attr in
dfl bus driver like pci do, actually I think quite similar to
"driver_override", How do you think?

I'm glad we restarted the discussion for the temporary binding of UIO
driver.

Thanks,
Yilun

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

[Xu Yilun]

On Sun, Jan 10, 2021 at 12:11:17PM -0800, Moritz Fischer wrote:
> On Sat, Jan 02, 2021 at 11:13:01AM +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 
> > ---
> > 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.
> > ---
> >  drivers/fpga/Kconfig| 10 +
> >  drivers/fpga/Makefile   |  1 +
> >  drivers/fpga/dfl-uio-pdev.c | 91 
> > +
> >  3 files changed, 102 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
> > + 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 000..a4cd581
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio-pdev.c
> > @@ -0,0 +1,91 @@
> > +// 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 uio_info uio_pdata = { 0 };
> > +   struct platform_device *uio_pdev;
> > +   struct device *dev = >dev;
> > +   unsigned int num_res = 1;
> > +   struct resource res[2];
> > +
> > +   res[0].parent = >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(>dev,
> > +"%d irqs for 

Re: [RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

On Thu, Jan 07, 2021 at 03:51:38PM +0100, Andrew Lunn wrote:
> On Thu, Jan 07, 2021 at 10:26:12AM +0100, Greg KH wrote:
> > On Thu, Jan 07, 2021 at 02:07:08PM +0800, Xu Yilun wrote:
> > > This driver supports the ethernet retimers (C827) for the Intel PAC
> > > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> > > 
> > > C827 is an Intel(R) Ethernet serdes transceiver chip that supports
> > > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
> > > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
> > > 10G/25G retimer mode. Host could query their link states and firmware
> > > version information via retimer interfaces (Shared registers) on Intel
> > > MAX 10 BMC. The driver creates sysfs interfaces for users to query these
> > > information.
> > 
> > Networking people, please look at this sysfs file:
> > 
> > > +What:
> > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
> > > +Date:Jan 2021
> > > +KernelVersion:   5.12
> > > +Contact: Xu Yilun 
> > > +Description: Read only. Returns the status of each line side link. 
> > > "1" for
> > > + link up, "0" for link down.
> > > + Format: "%u".
> > 
> > as I need your approval to add it because it is not the "normal" way for
> > link status to be exported to userspace.
> 
> Hi Greg
> 
> Correct, this is not going to be acceptable.
> 
> The whole architecture needs to cleanly fit into the phylink model for
> controlling the SFP and the retimer.
> 
> I'm guessing Intel needs to rewrite portions of the BMC firmware to
> either transparently pass through access to the SFP socket and the
> retimer for phylink and a C827 specific driver, or add a high level
> API which a MAC driver can use, and completely hide away these PHY
> details from Linux, which is what many of the Intel Ethernet drivers
> do.

Got it, Thanks for your explanation.

Yilun

Re: [RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

On Thu, Jan 07, 2021 at 10:26:12AM +0100, Greg KH wrote:
> On Thu, Jan 07, 2021 at 02:07:08PM +0800, Xu Yilun wrote:
> > This driver supports the ethernet retimers (C827) for the Intel PAC
> > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> > 
> > C827 is an Intel(R) Ethernet serdes transceiver chip that supports
> > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
> > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
> > 10G/25G retimer mode. Host could query their link states and firmware
> > version information via retimer interfaces (Shared registers) on Intel
> > MAX 10 BMC. The driver creates sysfs interfaces for users to query these
> > information.
> 
> Networking people, please look at this sysfs file:
> 
> > +What:  
> > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
> > +Date:  Jan 2021
> > +KernelVersion: 5.12
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the status of each line side link. 
> > "1" for
> > +   link up, "0" for link down.
> > +   Format: "%u".
> 
> as I need your approval to add it because it is not the "normal" way for
> link status to be exported to userspace.
> 
> One code issue:
> 
> > +#define to_link_attr(dev_attr) \
> > +   container_of(dev_attr, struct link_attr, attr)
> > +
> > +static ssize_t
> > +link_status_show(struct device *dev, struct device_attribute *attr, char 
> > *buf)
> > +{
> > +   struct m10bmc_retimer *retimer = dev_get_drvdata(dev);
> > +   struct link_attr *lattr = to_link_attr(attr);
> > +   unsigned int val;
> > +   int ret;
> > +
> > +   ret = m10bmc_sys_read(retimer->m10bmc, M10BMC_PKVL_LSTATUS, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   return sysfs_emit(buf, "%u\n",
> > + !!(val & BIT((retimer->id << 2) + lattr->index)));
> > +}
> > +
> > +#define link_status_attr(_index)   \
> > +   static struct link_attr link_attr_status##_index =  \
> > +   { .attr = __ATTR(link_status##_index, 0444, \
> > +link_status_show, NULL),   \
> > + .index = (_index) }
> 
> Why is this a "raw" attribute and not a device attribute?

It is actually a device_attribute. The device_attribute is embedded in
link_attr, like:

  struct link_attr {
struct device_attribute attr;
u32 index;
  };

An index for the link is appended along with the device_attribute, so we
could identify which link is being queried on link_status_show(). There
are 4 links and this is to avoid duplicated code like
link_status_1_show(), link_status_2_show() ...

> 
> Please just use a normal DEVICE_ATTR_RO() macro to make it simpler and

DEVICE_ATTR_RO() is to define a standalone device_attribute variable, but
here we are initializing a field in struct link_attr.

Thanks,
Yilun

> easier to understand over time, what you are doing here.  I can't
> determine what is happening with this code now...
> 
> thanks,
> 
> greg k-h

[RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

This driver supports the ethernet retimers (C827) for the Intel PAC
(Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.

C827 is an Intel(R) Ethernet serdes transceiver chip that supports
up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
10G/25G retimer mode. Host could query their link states and firmware
version information via retimer interfaces (Shared registers) on Intel
MAX 10 BMC. The driver creates sysfs interfaces for users to query these
information.

Signed-off-by: Xu Yilun 
---
 .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
 drivers/misc/Kconfig   |  10 ++
 drivers/misc/Makefile  |   1 +
 drivers/misc/intel-m10-bmc-retimer.c   | 158 +
 4 files changed, 201 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
 create mode 100644 drivers/misc/intel-m10-bmc-retimer.c

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer 
b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
new file mode 100644
index 000..528712a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
@@ -0,0 +1,32 @@
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/tag
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the tag of the retimer chip. Now there are 2
+   retimer chips on Intel PAC N3000, they are tagged as
+   'retimer_A' and 'retimer_B'.
+   Format: "retimer_%c".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/sbus_version
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the Transceiver bus firmware version of
+   the retimer chip.
+   Format: "0x%04x".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/serdes_version
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the SERDES firmware version of the retimer
+   chip.
+   Format: "0x%04x".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the status of each line side link. "1" for
+   link up, "0" for link down.
+   Format: "%u".
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0..7cb9433 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -466,6 +466,16 @@ config HISI_HIKEY_USB
  switching between the dual-role USB-C port and the USB-A host ports
  using only one USB controller.
 
+config INTEL_M10_BMC_RETIMER
+   tristate "Intel(R) MAX 10 BMC ethernet retimer interface support"
+   depends on MFD_INTEL_M10_BMC
+   help
+ This driver supports the ethernet retimer (C827) on Intel(R) MAX 10
+ BMC, which is used by Intel PAC N3000 FPGA based Smart NIC.
+
+ To compile this driver as a module, choose M here: the module will
+ be called intel-m10-bmc-retimer.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e..67883cf 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI)   += habanalabs/
 obj-$(CONFIG_UACCE)+= uacce/
 obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
 obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
+obj-$(CONFIG_INTEL_M10_BMC_RETIMER)+= intel-m10-bmc-retimer.o
diff --git a/drivers/misc/intel-m10-bmc-retimer.c 
b/drivers/misc/intel-m10-bmc-retimer.c
new file mode 100644
index 000..d845342b
--- /dev/null
+++ b/drivers/misc/intel-m10-bmc-retimer.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Max10 BMC Retimer Interface Driver
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define N3000BMC_RETIMER_DEV_NAME "n3000bmc-retimer"
+
+struct m10bmc_retimer {
+   struct device *dev;
+   struct intel_m10bmc *m10bmc;
+   u32 ver_reg;
+   u32 id;
+};
+
+static ssize_t tag_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct m10bmc_retimer *retimer = dev_get_drvdata(dev);
+
+   return sysfs_emit(buf, "retimer_%c\n", 'A' + retimer->id);
+}
+static DEVICE_ATTR_RO(tag);
+
+static ssize_t sbus_version_show(struct device *dev,
+struct device_attribute *attr, char *buf)

[RESEND PATCH 0/2] Add retimer interfaces support for Intel MAX 10 BMC

[Xu Yilun]

I resend this patchset to loop in networking developers for comments. This
is the previous thread. I'll fix other comments when I have a v2.

https://lore.kernel.org/lkml/x%2fv9hvxyluot9...@kroah.com/


The patchset is for the retimers connected to Intel MAX 10 BMC on Intel
PAC (Programmable Acceleration Card) N3000 Card. The network part of the
N3000 card is like the following:

   ++
   |  FPGA  |
  ++   +---+   +---+  +--+  +---+   +--+
  |QSFP|---|retimer|---|Line Side  |--|User logic|--|Host Side  |---|XL710 |
  ++   +---+   |Ether Group|  |  |  |Ether Group|   |Ethernet  |
   |(PHY + MAC)|  |wiring &  |  |(MAC + PHY)|   |Controller|
   +---+  |offloading|  +---+   +--+
   |  +--+  |
   ||
   ++

I had sent some RFC patches to expose the Line Side Ether Group + retimer +
QSFP as a netdev, and got some comments from netdev Maintainers.

https://lore.kernel.org/netdev/1603442745-13085-2-git-send-email-yilun...@intel.com/

The blocking issues I have is that physically the QSFP & retimer is
managed by the BMC and host could only get the retimer link states. This
is not enough to support some necessary netdev ops.  E.g. host cannot
realize the type/speed of the SFP by "ethtool -m", then users could not
configure the various layers accordingly.

This means the existing net tool can not work with it, so this patch just
expose the link states as custom sysfs attrs.


This patchset supports the ethernet retimers (C827) for the Intel PAC
(Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.

The 2 retimer chips connect to the Intel MAX 10 BMC on the card. They are
managed by the BMC firmware. Host could query their link states and
firmware version information via retimer interfaces (Shared registers) on
the BMC. The driver creates sysfs interfaces for users to query these
information.

The Intel OPAE (Open Programmable Acceleration Engine) lib provides tools
to read these attributes.

This is the source of the OPAE lib.

https://github.com/OPAE/opae-sdk/

Generally it facilitate the development on all the DFL (Device Feature
List) based FPGA Cards, including the management of static region &
dynamic region reprogramming, accelerators accessing and the board
specific peripherals.


Xu Yilun (2):
  mfd: intel-m10-bmc: specify the retimer sub devices
  misc: add support for retimers interfaces on Intel MAX 10 BMC

 .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
 drivers/mfd/intel-m10-bmc.c|  19 ++-
 drivers/misc/Kconfig   |  10 ++
 drivers/misc/Makefile  |   1 +
 drivers/misc/intel-m10-bmc-retimer.c   | 158 +
 include/linux/mfd/intel-m10-bmc.h  |   7 +
 6 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
 create mode 100644 drivers/misc/intel-m10-bmc-retimer.c

-- 
2.7.4

[RESEND PATCH 1/2] mfd: intel-m10-bmc: specify the retimer sub devices

[Xu Yilun]

The patch specifies the 2 retimer sub devices and their resources in the
parent driver's mfd_cell. It also adds the register definition of the
retimer sub devices.

There are 2 ethernet retimer chips (C827) connected to the Intel MAX 10
BMC. They are managed by the BMC firmware, and host could query them via
retimer interfaces (shared registers) on the BMC. The 2 retimers have
identical register interfaces in different register addresses or fields,
so it is better we define 2 retimer devices and handle them with the same
driver.

Signed-off-by: Xu Yilun 
---
 drivers/mfd/intel-m10-bmc.c   | 19 ++-
 include/linux/mfd/intel-m10-bmc.h |  7 +++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index b84579b..e0a99a0 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -17,9 +17,26 @@ enum m10bmc_type {
M10_N3000,
 };
 
+static struct resource retimer0_resources[] = {
+   {M10BMC_PKVL_A_VER, M10BMC_PKVL_A_VER, "version", IORESOURCE_REG, },
+};
+
+static struct resource retimer1_resources[] = {
+   {M10BMC_PKVL_B_VER, M10BMC_PKVL_B_VER, "version", IORESOURCE_REG, },
+};
+
 static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
{ .name = "n3000bmc-hwmon" },
-   { .name = "n3000bmc-retimer" },
+   {
+   .name = "n3000bmc-retimer",
+   .num_resources = ARRAY_SIZE(retimer0_resources),
+   .resources = retimer0_resources,
+   },
+   {
+   .name = "n3000bmc-retimer",
+   .num_resources = ARRAY_SIZE(retimer1_resources),
+   .resources = retimer1_resources,
+   },
{ .name = "n3000bmc-secure" },
 };
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index c8ef2f1..d6216f9 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -21,6 +21,13 @@
 #define M10BMC_VER_PCB_INFO_MSKGENMASK(31, 24)
 #define M10BMC_VER_LEGACY_INVALID  0x
 
+/* Retimer related registers, in system register region */
+#define M10BMC_PKVL_LSTATUS0x164
+#define M10BMC_PKVL_A_VER  0x254
+#define M10BMC_PKVL_B_VER  0x258
+#define M10BMC_PKVL_SERDES_VER GENMASK(15, 0)
+#define M10BMC_PKVL_SBUS_VER   GENMASK(31, 16)
+
 /**
  * struct intel_m10bmc - Intel MAX 10 BMC parent driver data structure
  * @dev: this device
-- 
2.7.4

Re: [PATCH 1/2] mfd: intel-m10-bmc: specify the retimer sub devices

[Xu Yilun]

On Wed, Jan 06, 2021 at 08:23:30AM +, Lee Jones wrote:
> On Wed, 06 Jan 2021, Xu Yilun wrote:
> 
> > The patch specifies the 2 retimer sub devices and their resources in the
> > parent driver's mfd_cell. It also adds the register definition of the
> > retimer sub devices.
> > 
> > There are 2 ethernet retimer chips (C827) connected to the Intel MAX 10
> > BMC. They are managed by the BMC firmware, and host could query them via
> > retimer interfaces (shared registers) on the BMC. The 2 retimers have
> > identical register interfaces in different register addresses or fields,
> > so it is better we define 2 retimer devices and handle them with the same
> > driver.
> > 
> > Signed-off-by: Xu Yilun 
> > ---
> >  drivers/mfd/intel-m10-bmc.c   | 19 ++-
> >  include/linux/mfd/intel-m10-bmc.h |  7 +++
> >  2 files changed, 25 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> > index b84579b..e0a99a0 100644
> > --- a/drivers/mfd/intel-m10-bmc.c
> > +++ b/drivers/mfd/intel-m10-bmc.c
> > @@ -17,9 +17,26 @@ enum m10bmc_type {
> > M10_N3000,
> >  };
> >  
> > +static struct resource retimer0_resources[] = {
> > +   {M10BMC_PKVL_A_VER, M10BMC_PKVL_A_VER, "version", IORESOURCE_REG, },
> > +};
> > +
> > +static struct resource retimer1_resources[] = {
> > +   {M10BMC_PKVL_B_VER, M10BMC_PKVL_B_VER, "version", IORESOURCE_REG, },
> > +};
> 
> Please use the DEFINE_RES_*() helpers for this.

Yes, will change it.

Thanks,
Yilun

Re: [PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

On Wed, Jan 06, 2021 at 10:06:14AM +0100, Greg KH wrote:
> On Wed, Jan 06, 2021 at 04:53:29PM +0800, Xu Yilun wrote:
> > On Wed, Jan 06, 2021 at 08:56:42AM +0100, Greg KH wrote:
> > > On Wed, Jan 06, 2021 at 03:36:07PM +0800, Xu Yilun wrote:
> > > > This driver supports the ethernet retimers (C827) for the Intel PAC
> > > > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> > > > 
> > > > C827 is an Intel(R) Ethernet serdes transceiver chip that supports
> > > > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
> > > > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
> > > > 10G/25G retimer mode. Host could query their link states and firmware
> > > > version information via retimer interfaces (Shared registers) on Intel
> > > > MAX 10 BMC. The driver creates sysfs interfaces for users to query these
> > > > information.
> > > > 
> > > > Signed-off-by: Xu Yilun 
> > > > ---
> > > >  .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
> > > >  drivers/misc/Kconfig   |  10 ++
> > > >  drivers/misc/Makefile  |   1 +
> > > >  drivers/misc/intel-m10-bmc-retimer.c   | 158 
> > > > +
> > > >  4 files changed, 201 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> > > >  create mode 100644 drivers/misc/intel-m10-bmc-retimer.c
> > > > 
> > > > diff --git 
> > > > a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer 
> > > > b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> > > > new file mode 100644
> > > > index 000..528712a
> > > > --- /dev/null
> > > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> > > > @@ -0,0 +1,32 @@
> > > > +What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/tag
> > > > +Date:  Jan 2021
> > > > +KernelVersion: 5.12
> > > > +Contact:   Xu Yilun 
> > > > +Description:   Read only. Returns the tag of the retimer chip. Now 
> > > > there are 2
> > > > +   retimer chips on Intel PAC N3000, they are tagged as
> > > > +   'retimer_A' and 'retimer_B'.
> > > > +   Format: "retimer_%c".
> > > > +
> > > > +What:  
> > > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/sbus_version
> > > > +Date:  Jan 2021
> > > > +KernelVersion: 5.12
> > > > +Contact:   Xu Yilun 
> > > > +Description:   Read only. Returns the Transceiver bus firmware version 
> > > > of
> > > > +   the retimer chip.
> > > > +   Format: "0x%04x".
> > > > +
> > > > +What:  
> > > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/serdes_version
> > > > +Date:  Jan 2021
> > > > +KernelVersion: 5.12
> > > > +Contact:   Xu Yilun 
> > > > +Description:   Read only. Returns the SERDES firmware version of the 
> > > > retimer
> > > > +   chip.
> > > > +   Format: "0x%04x".
> > > > +
> > > > +What:  
> > > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
> > > > +Date:  Jan 2021
> > > > +KernelVersion: 5.12
> > > > +Contact:   Xu Yilun 
> > > > +Description:   Read only. Returns the status of each line side link. 
> > > > "1" for
> > > > +   link up, "0" for link down.
> > > > +   Format: "%u".
> > > 
> > > Who is going to use all of these read-only attributes?
> > 
> > The Intel OPAE (Open Programmable Acceleration Engine) lib handles these
> > attrs.
> 
> I have no idea what that is, you should put a pointer to the source for
> this in either the changelog comment, or here in the sysfs entries to
> show who is using this.

This is the source of the OPAE lib.

https://github.com/OPAE/opae-sdk/

Generally it facilitate the development on all the DFL (Device Feature
List) based FPGA Cards, including the management of static region &
dynamic region reprogramming, accelerators accessing and the board
specific pe

Re: [PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

On Wed, Jan 06, 2021 at 08:56:42AM +0100, Greg KH wrote:
> On Wed, Jan 06, 2021 at 03:36:07PM +0800, Xu Yilun wrote:
> > This driver supports the ethernet retimers (C827) for the Intel PAC
> > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> > 
> > C827 is an Intel(R) Ethernet serdes transceiver chip that supports
> > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
> > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
> > 10G/25G retimer mode. Host could query their link states and firmware
> > version information via retimer interfaces (Shared registers) on Intel
> > MAX 10 BMC. The driver creates sysfs interfaces for users to query these
> > information.
> > 
> > Signed-off-by: Xu Yilun 
> > ---
> >  .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
> >  drivers/misc/Kconfig   |  10 ++
> >  drivers/misc/Makefile  |   1 +
> >  drivers/misc/intel-m10-bmc-retimer.c   | 158 
> > +
> >  4 files changed, 201 insertions(+)
> >  create mode 100644 
> > Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> >  create mode 100644 drivers/misc/intel-m10-bmc-retimer.c
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer 
> > b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> > new file mode 100644
> > index 000..528712a
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
> > @@ -0,0 +1,32 @@
> > +What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/tag
> > +Date:  Jan 2021
> > +KernelVersion: 5.12
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the tag of the retimer chip. Now 
> > there are 2
> > +   retimer chips on Intel PAC N3000, they are tagged as
> > +   'retimer_A' and 'retimer_B'.
> > +   Format: "retimer_%c".
> > +
> > +What:  
> > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/sbus_version
> > +Date:  Jan 2021
> > +KernelVersion: 5.12
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the Transceiver bus firmware version 
> > of
> > +   the retimer chip.
> > +   Format: "0x%04x".
> > +
> > +What:  
> > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/serdes_version
> > +Date:  Jan 2021
> > +KernelVersion: 5.12
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the SERDES firmware version of the 
> > retimer
> > +   chip.
> > +   Format: "0x%04x".
> > +
> > +What:  
> > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
> > +Date:  Jan 2021
> > +KernelVersion: 5.12
> > +Contact:   Xu Yilun 
> > +Description:   Read only. Returns the status of each line side link. 
> > "1" for
> > +   link up, "0" for link down.
> > +   Format: "%u".
> 
> Who is going to use all of these read-only attributes?

The Intel OPAE (Open Programmable Acceleration Engine) lib handles these
attrs.

For the version attrs, the OPAE retimer firmware update tool will query
them to make sure the update is succeed.

For the link_status attrs, the OPAE net tools handles it.

> 
> And why isn't this information exported in the "normal" way for network
> devices?  Having them as custom sysfs attributes ensures that no
> existing tools will work with these at all, right?  Why not do the
> standard thing here isntead?

I had sent some RFC patches to expose the Line Side Ether Group + retimer +
QSFP as a netdev, and got some comments from netdev Maintainers.

The network part of the N3000 card is like the following:

   ++
   |  FPGA  |
  ++   +---+   +---+  +--+  +---+   +--+
  |QSFP|---|retimer|---|Line Side  |--|User logic|--|Host Side  |---|XL710 |
  ++   +---+   |Ether Group|  |  |  |Ether Group|   |Ethernet  |
   |(PHY + MAC)|  |wiring &  |  |(MAC + PHY)|   |Controller|
   +---+  |offloading|  +---+   +--+
   |  +--+  |
   ||
   ++

The main concern is that physically the QSFP & retimer is managed by the
BMC and host could only get the retimer link states. This is not enough
to support some necessary netdev ops.  E.g. host cannot realize the
type/speed of the SFP by "ethtool -m", then users could not configure the
various layers accordingly.

This means the existing net tool can not work with it, so this patch just
expose the link states as custom sysfs attrs.

Thanks,
Yilun 

[PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

[Xu Yilun]

This driver supports the ethernet retimers (C827) for the Intel PAC
(Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.

C827 is an Intel(R) Ethernet serdes transceiver chip that supports
up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
10G/25G retimer mode. Host could query their link states and firmware
version information via retimer interfaces (Shared registers) on Intel
MAX 10 BMC. The driver creates sysfs interfaces for users to query these
information.

Signed-off-by: Xu Yilun 
---
 .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
 drivers/misc/Kconfig   |  10 ++
 drivers/misc/Makefile  |   1 +
 drivers/misc/intel-m10-bmc-retimer.c   | 158 +
 4 files changed, 201 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
 create mode 100644 drivers/misc/intel-m10-bmc-retimer.c

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer 
b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
new file mode 100644
index 000..528712a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
@@ -0,0 +1,32 @@
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/tag
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the tag of the retimer chip. Now there are 2
+   retimer chips on Intel PAC N3000, they are tagged as
+   'retimer_A' and 'retimer_B'.
+   Format: "retimer_%c".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/sbus_version
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the Transceiver bus firmware version of
+   the retimer chip.
+   Format: "0x%04x".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/serdes_version
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the SERDES firmware version of the retimer
+   chip.
+   Format: "0x%04x".
+
+What:  /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
+Date:  Jan 2021
+KernelVersion: 5.12
+Contact:   Xu Yilun 
+Description:   Read only. Returns the status of each line side link. "1" for
+   link up, "0" for link down.
+   Format: "%u".
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0..7cb9433 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -466,6 +466,16 @@ config HISI_HIKEY_USB
  switching between the dual-role USB-C port and the USB-A host ports
  using only one USB controller.
 
+config INTEL_M10_BMC_RETIMER
+   tristate "Intel(R) MAX 10 BMC ethernet retimer interface support"
+   depends on MFD_INTEL_M10_BMC
+   help
+ This driver supports the ethernet retimer (C827) on Intel(R) MAX 10
+ BMC, which is used by Intel PAC N3000 FPGA based Smart NIC.
+
+ To compile this driver as a module, choose M here: the module will
+ be called intel-m10-bmc-retimer.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e..67883cf 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI)   += habanalabs/
 obj-$(CONFIG_UACCE)+= uacce/
 obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
 obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
+obj-$(CONFIG_INTEL_M10_BMC_RETIMER)+= intel-m10-bmc-retimer.o
diff --git a/drivers/misc/intel-m10-bmc-retimer.c 
b/drivers/misc/intel-m10-bmc-retimer.c
new file mode 100644
index 000..d845342b
--- /dev/null
+++ b/drivers/misc/intel-m10-bmc-retimer.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Max10 BMC Retimer Interface Driver
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define N3000BMC_RETIMER_DEV_NAME "n3000bmc-retimer"
+
+struct m10bmc_retimer {
+   struct device *dev;
+   struct intel_m10bmc *m10bmc;
+   u32 ver_reg;
+   u32 id;
+};
+
+static ssize_t tag_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct m10bmc_retimer *retimer = dev_get_drvdata(dev);
+
+   return sysfs_emit(buf, "retimer_%c\n", 'A' + retimer->id);
+}
+static DEVICE_ATTR_RO(tag);
+
+static ssize_t sbus_version_show(struct device *dev,
+struct device_attribute *attr, char *buf)

[PATCH 1/2] mfd: intel-m10-bmc: specify the retimer sub devices

[Xu Yilun]

The patch specifies the 2 retimer sub devices and their resources in the
parent driver's mfd_cell. It also adds the register definition of the
retimer sub devices.

There are 2 ethernet retimer chips (C827) connected to the Intel MAX 10
BMC. They are managed by the BMC firmware, and host could query them via
retimer interfaces (shared registers) on the BMC. The 2 retimers have
identical register interfaces in different register addresses or fields,
so it is better we define 2 retimer devices and handle them with the same
driver.

Signed-off-by: Xu Yilun 
---
 drivers/mfd/intel-m10-bmc.c   | 19 ++-
 include/linux/mfd/intel-m10-bmc.h |  7 +++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
index b84579b..e0a99a0 100644
--- a/drivers/mfd/intel-m10-bmc.c
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -17,9 +17,26 @@ enum m10bmc_type {
M10_N3000,
 };
 
+static struct resource retimer0_resources[] = {
+   {M10BMC_PKVL_A_VER, M10BMC_PKVL_A_VER, "version", IORESOURCE_REG, },
+};
+
+static struct resource retimer1_resources[] = {
+   {M10BMC_PKVL_B_VER, M10BMC_PKVL_B_VER, "version", IORESOURCE_REG, },
+};
+
 static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
{ .name = "n3000bmc-hwmon" },
-   { .name = "n3000bmc-retimer" },
+   {
+   .name = "n3000bmc-retimer",
+   .num_resources = ARRAY_SIZE(retimer0_resources),
+   .resources = retimer0_resources,
+   },
+   {
+   .name = "n3000bmc-retimer",
+   .num_resources = ARRAY_SIZE(retimer1_resources),
+   .resources = retimer1_resources,
+   },
{ .name = "n3000bmc-secure" },
 };
 
diff --git a/include/linux/mfd/intel-m10-bmc.h 
b/include/linux/mfd/intel-m10-bmc.h
index c8ef2f1..d6216f9 100644
--- a/include/linux/mfd/intel-m10-bmc.h
+++ b/include/linux/mfd/intel-m10-bmc.h
@@ -21,6 +21,13 @@
 #define M10BMC_VER_PCB_INFO_MSKGENMASK(31, 24)
 #define M10BMC_VER_LEGACY_INVALID  0x
 
+/* Retimer related registers, in system register region */
+#define M10BMC_PKVL_LSTATUS0x164
+#define M10BMC_PKVL_A_VER  0x254
+#define M10BMC_PKVL_B_VER  0x258
+#define M10BMC_PKVL_SERDES_VER GENMASK(15, 0)
+#define M10BMC_PKVL_SBUS_VER   GENMASK(31, 16)
+
 /**
  * struct intel_m10bmc - Intel MAX 10 BMC parent driver data structure
  * @dev: this device
-- 
2.7.4

[PATCH 0/2] Add retimer interfaces support for Intel MAX 10 BMC

[Xu Yilun]

This patchset supports the ethernet retimers (C827) for the Intel PAC
(Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.

The 2 retimer chips connect to the Intel MAX 10 BMC on the card. They are
managed by the BMC firmware. Host could query their link states and
firmware version information via retimer interfaces (Shared registers) on
the BMC. The driver creates sysfs interfaces for users to query these
information.


Xu Yilun (2):
  mfd: intel-m10-bmc: specify the retimer sub devices
  misc: add support for retimers interfaces on Intel MAX 10 BMC

 .../ABI/testing/sysfs-driver-intel-m10-bmc-retimer |  32 +
 drivers/mfd/intel-m10-bmc.c|  19 ++-
 drivers/misc/Kconfig   |  10 ++
 drivers/misc/Makefile  |   1 +
 drivers/misc/intel-m10-bmc-retimer.c   | 158 +
 include/linux/mfd/intel-m10-bmc.h  |   7 +
 6 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-retimer
 create mode 100644 drivers/misc/intel-m10-bmc-retimer.c

-- 
2.7.4

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

[Xu Yilun]

On Mon, Jan 04, 2021 at 09:19:24AM -0800, Russ Weight wrote:
> 
> 
> On 1/1/21 7:13 PM, Xu Yilun wrote:
> > This patch adds description for UIO support for dfl devices on DFL
> > bus.
> >
> > Signed-off-by: Xu Yilun 
> > ---
> > v2: no doc in v1, add it for v2.
> > v3: some documentation fixes.
> > v4: documentation change since the driver matching is changed.
> > v5: no change.
> > ---
> >  Documentation/fpga/dfl.rst | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index 0404fe6..b8497f3 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -7,6 +7,7 @@ Authors:
> >  - Enno Luebbers 
> >  - Xiao Guangrong 
> >  - Wu Hao 
> > +- Xu Yilun 
> >  
> >  The Device Feature List (DFL) FPGA framework (and drivers according to
> >  this framework) hides the very details of low layer hardwares and provides
> > @@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see 
> > drivers/fpga/dfl-fme-pr.c)
> >  could be a reference.
> >  
> >  
> > +UIO support for DFL devices
> > +===
> > +The purpose of an FPGA is to be reprogrammed with newly developed hardware
> > +components. New hardware can instantiate a new private feature in the DFL, 
> > and
> > +then get a DFL device in their system. In some cases users may need a 
> > userspace
> > +driver for the DFL device:
> > +
> > +* Users may need to run some diagnostic test for their hardwares.
> > +* Users may prototype the kernel driver in user space.
> > +* Some hardware is designed for specific purposes and does not fit into 
> > one of
> > +  the standard kernel subsystems.
> > +
> > +This requires the direct access to the MMIO space and interrupt handling in
> This may be better stated as:
> 
> "This requires direct access to MMIO space and interrupt handling from 
> userspace."

Thanks for the correction, I'll change it.

Yilun

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

[Xu Yilun]

On Mon, Jan 04, 2021 at 12:24:05PM +0800, Wu, Hao wrote:
> > Subject: [PATCH v5 2/2] Documentation: fpga: dfl: Add description for DFL
> > UIO support
> >
> > This patch adds description for UIO support for dfl devices on DFL
> > bus.
> >
> > Signed-off-by: Xu Yilun 
> > ---
> > v2: no doc in v1, add it for v2.
> > v3: some documentation fixes.
> > v4: documentation change since the driver matching is changed.
> > v5: no change.
> > ---
> >  Documentation/fpga/dfl.rst | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index 0404fe6..b8497f3 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -7,6 +7,7 @@ Authors:
> >  - Enno Luebbers 
> >  - Xiao Guangrong 
> >  - Wu Hao 
> > +- Xu Yilun 
> >
> >  The Device Feature List (DFL) FPGA framework (and drivers according to
> >  this framework) hides the very details of low layer hardwares and provides
> > @@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see
> > drivers/fpga/dfl-fme-pr.c)
> >  could be a reference.
> >
> >
> > +UIO support for DFL devices
> > +===
> 
> I think the main purpose is to support userspace driver for DFL devices, and
> UIO is the option for now. Do you think if the title could be userspace driver
> support for DFL devices?

Yes, I could change it.

Thanks,
Yilun

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

[Xu Yilun]

On Mon, Jan 04, 2021 at 12:16:30PM +0800, Wu, Hao wrote:
> > Subject: [PATCH v5 1/2] fpga: dfl: add the userspace I/O device support for
> > DFL devices
> >
> > 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 
> > ---
> > 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.
> > ---
> >  drivers/fpga/Kconfig| 10 +
> >  drivers/fpga/Makefile   |  1 +
> >  drivers/fpga/dfl-uio-pdev.c | 91
> > +
> >  3 files changed, 102 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
> > +  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 000..a4cd581
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio-pdev.c
> > @@ -0,0 +1,91 @@
> > +// 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 uio_info uio_pdata = { 0 };
> > +struct platform_device *uio_pdev;
> > +struct device *dev = >dev;
> > +unsigned int num_res = 1;
> > +struct resource res[2];
> > +
> > +res[0].parent = >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(>dev,
> > + "%d irqs for %s, but UIO only supports the
> > first one\n",
> > + ddev->num_irqs, dev_name(>dev));
> > +
> > +res[1].flags = IORESOURCE_IRQ;
> > +res[1].start = ddev->irqs[0];
> > +res[1].end = ddev->irqs[0];
> 
> Looks like res[] needs to be zeroed for other fields not used here.

Thanks for catching this. Will fix it.

Yilun

[PATCH v3] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

The xfer waiting time is the result of xfer->len / xfer->speed_hz. This
patch makes the assumption of 100khz xfer speed if the xfer->speed_hz is
not assigned and stays 0. This avoids the divide by 0 issue and ensures
a reasonable tolerant waiting time.

Signed-off-by: Xu Yilun 
---
v2: use the normal conditional statement instead of the ternery operator
change the default xfer speed from 1khz to 100khz
v3: fix the commit message
---
 drivers/spi/spi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 51d7c00..aacae88 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1108,6 +1108,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
 {
struct spi_statistics *statm = >statistics;
struct spi_statistics *stats = >spi->statistics;
+   u32 speed_hz = xfer->speed_hz;
unsigned long long ms;
 
if (spi_controller_is_slave(ctlr)) {
@@ -1116,8 +1117,11 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
return -EINTR;
}
} else {
+   if (!speed_hz)
+   speed_hz = 10;
+
ms = 8LL * 1000LL * xfer->len;
-   do_div(ms, xfer->speed_hz);
+   do_div(ms, speed_hz);
ms += ms + 200; /* some tolerance */
 
if (ms > UINT_MAX)
-- 
2.7.4

Re: [PATCH v2] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

On Sat, Jan 02, 2021 at 11:11:14AM -0300, Fabio Estevam wrote:
> On Sat, Jan 2, 2021 at 12:07 AM Xu Yilun  wrote:
> >
> > The xfer waiting time is the result of xfer->len / xfer->speed_hz. This
> > patch makes the assumption of 1khz xfer speed if the xfer->speed_hz is
> 
> You missed to update the commit log to 100kHz.

Thanks for the catching, I'll fix it.

Yilun

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

[Xu Yilun]

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 
---
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.
---
 drivers/fpga/Kconfig| 10 +
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 91 +
 3 files changed, 102 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
+ 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 000..a4cd581
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,91 @@
+// 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 uio_info uio_pdata = { 0 };
+   struct platform_device *uio_pdev;
+   struct device *dev = >dev;
+   unsigned int num_res = 1;
+   struct resource res[2];
+
+   res[0].parent = >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(>dev,
+"%d irqs for %s, but UIO only supports the 
first one\n",
+ddev->num_irqs, dev_name(>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 = >dev;
+   pdevinfo.id = PLATFORM_DEVID_AUTO;
+   pdevinfo.data = _pdata;
+   pdevinfo.size_data = sizeof(uio_pdata);
+
+   uio_pdev = platform_device_register_full();
+   if (!IS_ERR(uio_pdev))
+   dev_set_drvdata(dev, uio_pdev);
+
+   return PTR_ERR_OR_ZERO(uio_pdev);
+}
+
+static void dfl_uio_pdev_remove(struct dfl_device *ddev)
+{
+   struct platform_device *uio_pdev = dev_get_drvdata(>dev);
+
+   platform_device_unregister(uio_pdev);
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_de

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
---
 Documentation/fpga/dfl.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 0404fe6..b8497f3 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see 
drivers/fpga/dfl-fme-pr.c)
 could be a reference.
 
 
+UIO support for DFL devices
+===
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then get a DFL device in their system. In some cases users may need a userspace
+driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardwares.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires the direct access to the MMIO space and interrupt handling in
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module driver.
+To support a new DFL feature been directly accessed via UIO, its feature id
+should be added to the driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

[PATCH v5 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Xu Yilun (2):
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  | 24 
 drivers/fpga/Kconfig| 10 +
 drivers/fpga/Makefile   |  1 +
 drivers/fpga/dfl-uio-pdev.c | 91 +
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

[PATCH v2] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

The xfer waiting time is the result of xfer->len / xfer->speed_hz. This
patch makes the assumption of 1khz xfer speed if the xfer->speed_hz is
not assigned and stays 0. This avoids the divide by 0 issue and ensures
a reasonable tolerant waiting time.

Signed-off-by: Xu Yilun 
---
v2: use the normal conditional statement instead of the ternery operator
change the default xfer speed from 1khz to 100khz
---
 drivers/spi/spi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 51d7c00..aacae88 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1108,6 +1108,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
 {
struct spi_statistics *statm = >statistics;
struct spi_statistics *stats = >spi->statistics;
+   u32 speed_hz = xfer->speed_hz;
unsigned long long ms;
 
if (spi_controller_is_slave(ctlr)) {
@@ -1116,8 +1117,11 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
return -EINTR;
}
} else {
+   if (!speed_hz)
+   speed_hz = 10;
+
ms = 8LL * 1000LL * xfer->len;
-   do_div(ms, xfer->speed_hz);
+   do_div(ms, speed_hz);
ms += ms + 200; /* some tolerance */
 
if (ms > UINT_MAX)
-- 
2.7.4

Re: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

On Wed, Dec 30, 2020 at 01:46:44PM +, Mark Brown wrote:
> On Wed, Dec 30, 2020 at 10:24:20AM +0800, Xu Yilun wrote:
> > On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
> 
> > > Does this still apply with current code?  There have been some fixes in
> > > this area which I think should ensure that we don't turn the speed down
> > > to 0 if the controller doesn't supply a limit IIRC.
> 
> > Yes, there is chance the speed is set to 0, some related code from 5.11-rc1
> 
> Please check the code in the SPI tree and -next.

I see the fix patches in maillist, thanks.

> 
> > BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz?
> > Always clamp the spi->max_speed_hz to 0 makes no sense.
> 
> Right, that's the fix.

Seems it still doesn't fix the case that neither controller nor client dev
provides the non-zero max_speed_hz. Do you think the patch is still
necessary?

Thanks,
Yilun

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

[Xu Yilun]

On Tue, Dec 29, 2020 at 06:37:37AM -0800, Tom Rix wrote:
> 
> On 12/28/20 6:42 PM, Xu Yilun wrote:
> > This patch supports the DFL drivers be written in userspace. This is
> > realized by exposing the userspace I/O device interfaces.
> >
> > The driver 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 
> > ---
> > 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.
> > ---
> >  drivers/fpga/Kconfig|  10 +
> >  drivers/fpga/Makefile   |   1 +
> >  drivers/fpga/dfl-uio-pdev.c | 101 
> > 
> >  3 files changed, 112 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
> > + 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 000..1100434
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio-pdev.c
> > @@ -0,0 +1,101 @@
> > +// 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 device *dev = >dev;
> > +   struct platform_device_info pdevinfo = { 0 };
> > +   struct uio_info uio_pdata = { 0 };
> > +   struct platform_device *uio_pdev;
> > +   unsigned int num_res = 1;
> > +   struct resource *res;
> > +
> > +   if (ddev->num_irqs > 1)
> This num_irq check could be combined with the one below.

Yes, I'll change it.

> > +   dev_warn(>dev,
> > +"%d irqs for %s, but UIO only supports the first 
> > one\n",
> > +ddev->num_irqs, dev_name(>dev));
> > +
> > +   pdevinfo.name = "uio_pdrv_genirq";
> > +
> > +   if (ddev->num_irqs)
> > +   num_res++;
> > +
> > +   res = kcalloc(num_res, sizeof(*res), GFP_KERNEL);
> 
> Since num_res is at most 2, could res be converted to a stack array ?

Yes, I could refactor the code.

Thanks,
Yilun

> 
> Reviewed-by: Tom Rix  

Re: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 01:27:42PM +0800, Xu Yilun wrote:
> > The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
> > when the following patch is merged,
> > 
> > commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's 
> > max speed")
> > 
> > the xfer->speed_hz may always be clamped to 0 if the controller doesn't
> > provide its max_speed_hz. There may be no hardware indication of the
> > max_speed_hz so the controller driver leaves it, but exception happens
> > when it tries to do irq mode transfer.
> 
> Does this still apply with current code?  There have been some fixes in
> this area which I think should ensure that we don't turn the speed down
> to 0 if the controller doesn't supply a limit IIRC.

Yes, there is chance the speed is set to 0, some related code from 5.11-rc1

  int spi_setup(struct spi_device *spi)
  {
...

if (!spi->max_speed_hz ||
spi->max_speed_hz > spi->controller->max_speed_hz)
spi->max_speed_hz = spi->controller->max_speed_hz;

If the controller doesn't supply a limit, spi->max_speed_hz will always
be clamped to 0 here, no matter what the client inputs.

BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz?
Always clamp the spi->max_speed_hz to 0 makes no sense.

...
  }

  static int __spi_validate(struct spi_device *spi, struct spi_message
*message)
  {
...

if (!xfer->speed_hz)
xfer->speed_hz = spi->max_speed_hz;

if (ctlr->max_speed_hz && xfer->speed_hz > ctlr->max_speed_hz)
xfer->speed_hz = ctlr->max_speed_hz;

If spi->max_speed_hz & controller->max_speed_hz are 0, xfer->speed_hz is
always 0.

...
  }


I tested it on 5.11-rc1 with spi-altera.

> 
> > This patch makes the assumption of 1khz xfer speed if the xfer->speed_hz
> > is not assigned. This avoids the divide by 0 issue and ensures a
> > reasonable tolerant waiting time.
> 
> It will cause absurdly slow transfers if the controller does actually
> implement speed setting though, if we're going to pick a default value

Maybe I didn't describe clearly, if the controller has a valid limit setting,
the xfer->speed_hz will be set to max_speed_hz and will not fall through to
a default value. The fix code takes function when all the checks in spi_setup &
spi_validate fails to assign the xfer->speed_hz. 

This fix only affects the waiting timeout, it will not slow down the normal
xfer anyway.

> I'd go for at least 100kHz. 

If some controller is actually working at a speed lower than the default
value, xfer will always be unexpectly early terminated.

I'm not sure how slow the controllers in the world could be. If 100kHz
is slow enough to everyone it's OK.
 
> 
> > } else {
> > +   speed_hz = xfer->speed_hz ? : 1000;
> 
> Please don't abuse the ternery operator, write normal conditional
> statements to make things more legible.

OK, I'll change it.

Thanks,
Yilun

[PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time

[Xu Yilun]

The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
when the following patch is merged,

commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max 
speed")

the xfer->speed_hz may always be clamped to 0 if the controller doesn't
provide its max_speed_hz. There may be no hardware indication of the
max_speed_hz so the controller driver leaves it, but exception happens
when it tries to do irq mode transfer.

This patch makes the assumption of 1khz xfer speed if the xfer->speed_hz
is not assigned. This avoids the divide by 0 issue and ensures a
reasonable tolerant waiting time.

Signed-off-by: Xu Yilun 
---
 drivers/spi/spi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 51d7c00..2f3c2c9 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1109,6 +1109,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
struct spi_statistics *statm = >statistics;
struct spi_statistics *stats = >spi->statistics;
unsigned long long ms;
+   u32 speed_hz;
 
if (spi_controller_is_slave(ctlr)) {
if (wait_for_completion_interruptible(>xfer_completion)) {
@@ -1116,8 +1117,9 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
return -EINTR;
}
} else {
+   speed_hz = xfer->speed_hz ? : 1000;
ms = 8LL * 1000LL * xfer->len;
-   do_div(ms, xfer->speed_hz);
+   do_div(ms, speed_hz);
ms += ms + 200; /* some tolerance */
 
if (ms > UINT_MAX)
-- 
2.7.4

[PATCH 1/2] spi: altera: fix return value for altera_spi_txrx()

[Xu Yilun]

This patch fixes the return value for altera_spi_txrx. It should return
1 for interrupt transfer mode, and return 0 for polling transfer mode.

The altera_spi_txrx() implements the spi_controller.transfer_one
callback. According to the spi-summary.rst, the transfer_one should
return 0 when transfer is finished, return 1 when transfer is still in
progress.

Signed-off-by: Xu Yilun 
---
 drivers/spi/spi-altera.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 809bfff..cbc4c28 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -189,24 +189,26 @@ static int altera_spi_txrx(struct spi_master *master,
 
/* send the first byte */
altera_spi_tx_word(hw);
-   } else {
-   while (hw->count < hw->len) {
-   altera_spi_tx_word(hw);
 
-   for (;;) {
-   altr_spi_readl(hw, ALTERA_SPI_STATUS, );
-   if (val & ALTERA_SPI_STATUS_RRDY_MSK)
-   break;
+   return 1;
+   }
+
+   while (hw->count < hw->len) {
+   altera_spi_tx_word(hw);
 
-   cpu_relax();
-   }
+   for (;;) {
+   altr_spi_readl(hw, ALTERA_SPI_STATUS, );
+   if (val & ALTERA_SPI_STATUS_RRDY_MSK)
+   break;
 
-   altera_spi_rx_word(hw);
+   cpu_relax();
}
-   spi_finalize_current_transfer(master);
+
+   altera_spi_rx_word(hw);
}
+   spi_finalize_current_transfer(master);
 
-   return t->len;
+   return 0;
 }
 
 static irqreturn_t altera_spi_irq(int irq, void *dev)
-- 
2.7.4

[PATCH 0/2] fix the issue when xfer by spi-altera

[Xu Yilun]

When doing spi xfer by spi-altera, divide by 0 exception happens in
spi_transfer_wait(), This is because the xfer->speed_hz is always
clamped to 0 by spi->controller->max_speed_hz, the feature is
introduced in:

commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max 
speed")

The spi-altera doesn't have hardware indication for controller's
max_speed_hz, so its value is uninitialized as 0.

Patch #1 fixes the issue of spi_altera driver. When doing polling
mode xfer, its transfer_one() callback should return 1, to indicate
the xfer is finished. It should return 0 for irq mode xfer. With
this patch the polling mode xfer is OK as it needs no
spi_transfer_wait() anymore.

But the irq mode xfer is still broken. So Patch #2 assumes 1khz xfer
speed if the xfer->speed_hz is not assigned. I try to avoid the
divide by 0 issue and ensures a reasonable tolerant waiting time in
a generic way.

Xu Yilun (2):
  spi: altera: fix return value for altera_spi_txrx()
  spi: fix the divide by 0 error when calculating xfer waiting time

 drivers/spi/spi-altera.c | 26 ++
 drivers/spi/spi.c|  4 +++-
 2 files changed, 17 insertions(+), 13 deletions(-)

-- 
2.7.4

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

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
---
 Documentation/fpga/dfl.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 0404fe6..b8497f3 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see 
drivers/fpga/dfl-fme-pr.c)
 could be a reference.
 
 
+UIO support for DFL devices
+===
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then get a DFL device in their system. In some cases users may need a userspace
+driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardwares.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires the direct access to the MMIO space and interrupt handling in
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module driver.
+To support a new DFL feature been directly accessed via UIO, its feature id
+should be added to the driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

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

[Xu Yilun]

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 
---
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.
---
 drivers/fpga/Kconfig|  10 +
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/dfl-uio-pdev.c | 101 
 3 files changed, 112 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
+ 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 000..1100434
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,101 @@
+// 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 device *dev = >dev;
+   struct platform_device_info pdevinfo = { 0 };
+   struct uio_info uio_pdata = { 0 };
+   struct platform_device *uio_pdev;
+   unsigned int num_res = 1;
+   struct resource *res;
+
+   if (ddev->num_irqs > 1)
+   dev_warn(>dev,
+"%d irqs for %s, but UIO only supports the first 
one\n",
+ddev->num_irqs, dev_name(>dev));
+
+   pdevinfo.name = "uio_pdrv_genirq";
+
+   if (ddev->num_irqs)
+   num_res++;
+
+   res = kcalloc(num_res, sizeof(*res), GFP_KERNEL);
+   if (!res)
+   return -ENOMEM;
+
+   res[0].parent = >mmio_res;
+   res[0].flags = IORESOURCE_MEM;
+   res[0].start = ddev->mmio_res.start;
+   res[0].end = ddev->mmio_res.end;
+
+   /* then add irq resource */
+   if (num_res > 1) {
+   res[1].flags = IORESOURCE_IRQ;
+   res[1].start = ddev->irqs[0];
+   res[1].end = ddev->irqs[0];
+   }
+
+   uio_pdata.name = DRIVER_NAME;
+   uio_pdata.version = "0";
+
+   pdevinfo.res = res;
+   pdevinfo.num_res = num_res;
+   pdevinfo.parent = >dev;
+   pdevinfo.id = PLATFORM_DEVID_AUTO;
+   pdevinfo.data = _pdata;
+   pdevinfo.size_data = sizeof(uio_pdata);
+
+   uio_pdev = platform_device_register_full();
+   if (!IS_ERR(uio_pdev))
+   dev_set_drvdata(dev, uio_pdev);
+
+   kfree(res);
+
+   return PTR_ERR_OR_ZERO(uio_pdev);
+}
+
+static void dfl_uio_pdev_remove(struct dfl_device *ddev)
+{
+   struct platform_device *uio_pdev = dev_get_drvdata(>dev);
+
+   pla

[PATCH v4 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Xu Yilun (2):
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  |  24 +++
 drivers/fpga/Kconfig|  10 +
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/dfl-uio-pdev.c | 101 
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

[PATCH v14 6/6] memory: dfl-emif: add the DFL EMIF private feature driver

[Xu Yilun]

This driver is for the EMIF private feature implemented under FPGA
Device Feature List (DFL) framework. It is used to expose memory
interface status information as well as memory clearing control.

The purpose of memory clearing block is to zero out all private memory
when FPGA is to be reprogrammed. This gives users a reliable method to
prevent potential data leakage.

Signed-off-by: Xu Yilun 
Signed-off-by: Russ Weight 
Reviewed-by: Tom Rix 
Acked-by: Krzysztof Kozlowski 
---
v2: Adjust the position of this driver in Kconfig.
Improves the name of the Kconfig option.
Change the include dfl-bus.h to dfl.h, cause the previous patchset
 renames the file.
Some minor fixes and comment improvement.
v3: Adjust the position of the driver in Makefile.
v9: Add static prefix for emif attributes macro.
Update the kernel version of the sysfs interfaces in Doc.
v10: Rebase due to the dfl head file moves to include/linux.
v11: Use sysfs_emit instead of sprintf.
 Rebase to rebase to 5.10-rc1.
v12: no change.
v13: no change.
v14: no change, rebase to 5.11-rc1
---
 .../ABI/testing/sysfs-bus-dfl-devices-emif |  25 +++
 drivers/memory/Kconfig |   9 +
 drivers/memory/Makefile|   2 +
 drivers/memory/dfl-emif.c  | 207 +
 4 files changed, 243 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
 create mode 100644 drivers/memory/dfl-emif.c

diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif 
b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
new file mode 100644
index 000..1ae8ebd
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
@@ -0,0 +1,25 @@
+What:  /sys/bus/dfl/devices/dfl_dev.X/infX_cal_fail
+Date:  Oct 2020
+KernelVersion: 5.11
+Contact:   Xu Yilun 
+Description:   Read-only. It indicates if the calibration failed on this
+   memory interface. "1" for calibration failure, "0" for OK.
+   Format: %u
+
+What:  /sys/bus/dfl/devices/dfl_dev.X/infX_init_done
+Date:  Oct 2020
+KernelVersion: 5.11
+Contact:   Xu Yilun 
+Description:   Read-only. It indicates if the initialization completed on
+   this memory interface. "1" for initialization complete, "0"
+   for not yet.
+   Format: %u
+
+What:  /sys/bus/dfl/devices/dfl_dev.X/infX_clear
+Date:  Oct 2020
+KernelVersion: 5.11
+Contact:   Xu Yilun 
+Description:   Write-only. Writing "1" to this file will zero out all memory
+   data in this memory interface. Writing of other values is
+   invalid.
+   Format: %u
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 3ea6913..3c9a988 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -137,6 +137,15 @@ config TI_EMIF_SRAM
  sequence so this driver provides several relocatable PM functions
  for the SoC PM code to use.
 
+config FPGA_DFL_EMIF
+   tristate "FPGA DFL EMIF Driver"
+   depends on FPGA_DFL && HAS_IOMEM
+   help
+ This driver is for the EMIF private feature implemented under
+ FPGA Device Feature List (DFL) framework. It is used to expose
+ memory interface status information as well as memory clearing
+ control.
+
 config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
default y if PLAT_ORION
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e71cf7b..bc7663e 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_STM32_FMC2_EBI)  += stm32-fmc2-ebi.o
 obj-$(CONFIG_SAMSUNG_MC)   += samsung/
 obj-$(CONFIG_TEGRA_MC) += tegra/
 obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
+obj-$(CONFIG_FPGA_DFL_EMIF)+= dfl-emif.o
+
 ti-emif-sram-objs  := ti-emif-pm.o ti-emif-sram-pm.o
 
 AFLAGS_ti-emif-sram-pm.o   :=-Wa,-march=armv7-a
diff --git a/drivers/memory/dfl-emif.c b/drivers/memory/dfl-emif.c
new file mode 100644
index 000..3f71981
--- /dev/null
+++ b/drivers/memory/dfl-emif.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL device driver for EMIF private feature
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FME_FEATURE_ID_EMIF0x9
+
+#define EMIF_STAT  0x8
+#define EMIF_STAT_INIT_DONE_SFT0
+#define EMIF_STAT_CALC_FAIL_SFT8
+#define EMIF_STAT_CLEAR_BUSY_SFT   16
+#define EMIF_CTRL  0x10
+#define EMIF_CTRL_CLEAR_EN_SFT 0
+#define EMIF_CTRL_CLEAR_EN_MSK GENMASK_ULL(3, 0)
+
+#define EMIF_POLL_INVL 1 /* us 

[PATCH v14 5/6] fpga: dfl: add support for N3000 Nios private feature

[Xu Yilun]

This patch adds support for the Nios handshake private feature on Intel
PAC (Programmable Acceleration Card) N3000.

The Nios is the embedded processor on the FPGA card. This private feature
provides a handshake interface to FPGA Nios firmware, which receives
retimer configuration command from host and executes via an internal SPI
master (spi-altera). When Nios finishes the configuration, host takes over
the ownership of the SPI master to control an Intel MAX10 BMC (Board
Management Controller) Chip on the SPI bus.

For Nios firmware handshake part, this driver requests the retimer
configuration for Nios firmware on probe, and adds some sysfs nodes for
user to query the onboard retimer's working mode and Nios firmware
version.

For SPI part, this driver adds a spi-altera platform device as well as
the MAX10 BMC spi slave info. A spi-altera driver will be matched to
handle the following SPI work.

[m...@kernel.org: Fixed up MAINTAINERS file to include added ABI doc]
Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
Signed-off-by: YueHaibing 
Reviewed-by: Tom Rix 
---
v3: add the doc for this driver
minor fixes for comments from Tom
v4: move the err log in regmap implementation, and delete
 n3000_nios_writel/readl(), they have nothing to wrapper now.
some minor fixes and comments improvement.
v5: fix the output of fec_mode sysfs inf to "no" on 10G configuration,
 cause no FEC mode could be configured for 10G.
rename the dfl_n3000_nios_* to n3000_nios_*
improves comments.
v6: fix the output of fec_mode sysfs inf to "not supported" if in 10G,
 or the firmware version major < 3.
minor fixes and improves comments.
v7: improves comments.
v8: add sysfs interfaces for retimer mode, also doc update.
delete duplicated sysfs interfaces description in doc.
minor fixes.
v9: delete the retimer FEC mode configuration via module_parameter.
update the kernel version of the sysfs interfaces in Doc.
merge the patch "Make m10_n3000_info static" 
(https://lore.kernel.org/linux-fpga/52d8411e-13d8-1e91-756d-131802f5f...@huawei.com/T/#t)
remove the tags of Maintainers, this implementation is changed.
v10: improve the name of some macros, functions and variables.
 refactor the FEC mode setting and reading.
 refactor the retimer init error checking and dumping.
 refactor the loop timeout for regbus reading & write.
 some minor fixes.
v11: use sysfs_emit instead of sprintf.
 rebase to 5.10-rc1.
v12: move the MODULE_DEVICE_TABLE() right after its definition.
v13: fix the wrong use of logical'||', should use '|' on Nios
 INIT_DONE and INIT_START check, reported by lkp check.
v14: no change, rebase to 5.11-rc1
---
 .../ABI/testing/sysfs-bus-dfl-devices-n3000-nios   |  47 ++
 MAINTAINERS|   2 +-
 drivers/fpga/Kconfig   |  11 +
 drivers/fpga/Makefile  |   2 +
 drivers/fpga/dfl-n3000-nios.c  | 588 +
 5 files changed, 649 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
 create mode 100644 drivers/fpga/dfl-n3000-nios.c

diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios 
b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
new file mode 100644
index 000..a505537
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios
@@ -0,0 +1,47 @@
+What:  /sys/bus/dfl/devices/dfl_dev.X/fec_mode
+Date:  Oct 2020
+KernelVersion: 5.11
+Contact:   Xu Yilun 
+Description:   Read-only. Returns the FEC mode of the 25G links of the
+   ethernet retimers configured by Nios firmware. "rs" for Reed
+   Solomon FEC, "kr" for Fire Code FEC, "no" for NO FEC.
+   "not supported" if the FEC mode setting is not supported, this
+   happens when the Nios firmware version major < 3, or no link is
+   configured to 25G.
+   Format: string
+
+What:  /sys/bus/dfl/devices/dfl_dev.X/retimer_A_mode
+Date:  Oct 2020
+KernelVersion: 5.11
+Contact:   Xu Yilun 
+Description:   Read-only. Returns the enumeration value of the working mode of
+   the retimer A configured by the Nios firmware. The value is
+   read out from shared registers filled by the Nios firmware. Now
+   the values could be:
+
+   - "0": Reset
+   - "1": 4x10G
+   - "2": 4x25G
+   - "3": 2x25G
+   - "4": 2x25G+2x10G
+   - "5": 1x25G
+
+   If the Nios firmware is updated in future to support more
+   retimer modes, more enumeration value is expected.
+  

[PATCH v14 4/6] fpga: dfl: move dfl bus related APIs to include/linux/dfl.h

[Xu Yilun]

Now the dfl drivers could be made as independent modules and put in
different folders according to their functionalities. In order for
scattered dfl device drivers to include dfl bus APIs, move the
dfl bus APIs to a new header file in the public folder.

[m...@kernel.org: Fixed up header guards to match filename]
Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Acked-by: Wu Hao 
Signed-off-by: Moritz Fischer 
---
v2: updated the MAINTAINERS under FPGA DFL DRIVERS
improve the comments
rename the dfl-bus.h to dfl.h
v3: rebase the patch for previous changes
v9: rebase the patch for bus name changes back to "dfl"
v10: move the head file from inlude/linux/fpga to include/linux
v11: no change
v12: Fixed up header guards to match filename by Moritz
v13: no change
v14: no change, rebase to 5.11-rc1
---
 MAINTAINERS |  1 +
 drivers/fpga/dfl.c  |  1 +
 drivers/fpga/dfl.h  | 72 
 include/linux/dfl.h | 86 +
 4 files changed, 88 insertions(+), 72 deletions(-)
 create mode 100644 include/linux/dfl.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66..a044b58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6957,6 +6957,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
 FPGA MANAGER FRAMEWORK
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 5a6ba3b..511b20f 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -10,6 +10,7 @@
  *   Wu Hao 
  *   Xiao Guangrong 
  */
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 549c790..2b82c96 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -517,76 +517,4 @@ long dfl_feature_ioctl_set_irq(struct platform_device 
*pdev,
   struct dfl_feature *feature,
   unsigned long arg);
 
-/**
- * enum dfl_id_type - define the DFL FIU types
- */
-enum dfl_id_type {
-   FME_ID = 0,
-   PORT_ID = 1,
-   DFL_ID_MAX,
-};
-
-/**
- * struct dfl_device - represent an dfl device on dfl bus
- *
- * @dev: generic device interface.
- * @id: id of the dfl device.
- * @type: type of DFL FIU of the device. See enum dfl_id_type.
- * @feature_id: feature identifier local to its DFL FIU type.
- * @mmio_res: mmio resource of this dfl device.
- * @irqs: list of Linux IRQ numbers of this dfl device.
- * @num_irqs: number of IRQs supported by this dfl device.
- * @cdev: pointer to DFL FPGA container device this dfl device belongs to.
- * @id_entry: matched id entry in dfl driver's id table.
- */
-struct dfl_device {
-   struct device dev;
-   int id;
-   u16 type;
-   u16 feature_id;
-   struct resource mmio_res;
-   int *irqs;
-   unsigned int num_irqs;
-   struct dfl_fpga_cdev *cdev;
-   const struct dfl_device_id *id_entry;
-};
-
-/**
- * struct dfl_driver - represent an dfl device driver
- *
- * @drv: driver model structure.
- * @id_table: pointer to table of device IDs the driver is interested in.
- *   { } member terminated.
- * @probe: mandatory callback for device binding.
- * @remove: callback for device unbinding.
- */
-struct dfl_driver {
-   struct device_driver drv;
-   const struct dfl_device_id *id_table;
-
-   int (*probe)(struct dfl_device *dfl_dev);
-   void (*remove)(struct dfl_device *dfl_dev);
-};
-
-#define to_dfl_dev(d) container_of(d, struct dfl_device, dev)
-#define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
-
-/*
- * use a macro to avoid include chaining to get THIS_MODULE.
- */
-#define dfl_driver_register(drv) \
-   __dfl_driver_register(drv, THIS_MODULE)
-int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner);
-void dfl_driver_unregister(struct dfl_driver *dfl_drv);
-
-/*
- * module_dfl_driver() - Helper macro for drivers that don't do
- * anything special in module init/exit.  This eliminates a lot of
- * boilerplate.  Each module may only use this macro once, and
- * calling it replaces module_init() and module_exit().
- */
-#define module_dfl_driver(__dfl_driver) \
-   module_driver(__dfl_driver, dfl_driver_register, \
- dfl_driver_unregister)
-
 #endif /* __FPGA_DFL_H */
diff --git a/include/linux/dfl.h b/include/linux/dfl.h
new file mode 100644
index 000..6cc1098
--- /dev/null
+++ b/include/linux/dfl.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for DFL driver and device API
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ */
+
+#ifndef __LINUX_DFL_H
+#define __LINUX_DFL_H
+
+#include 
+#include 
+
+/**
+ * enum dfl_id_type - define the DFL FIU types
+ */
+enum dfl_id_type {
+   FME_ID = 0,
+   PORT_ID = 1,
+   DFL_ID_MAX,
+};
+
+/**
+ * struct dfl_device - represent an dfl device on dfl bus
+