@@ -210,7 +210,7 @@ device and etc. Its driver module is always loaded first once the device is created by the system. This driver plays an infrastructural role in the driver architecture. It locates the DFLs in the device memory, handles them and related resources to common interfaces from DFL framework for enumeration.-(Please refer to drivers/fpga/dfl.c for detailed enumeration APIs).+(Please refer to drivers/fpga/dfl/dfl.c for detailed enumeration APIs). The FPGA Management Engine (FME) driver is a platform driver which is loaded automatically after FME platform device creation from the DFL device module. It
@@ -499,7 +499,7 @@ In some cases, we may need to add some new private features to existing FIUs framework, as each private feature will be parsed automatically and related mmio resources can be found under FIU platform device created by DFL framework. Developer only needs to provide a sub feature driver with matched feature id.-FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)+FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl/dfl-fme-pr.c) could be a reference. Location of DFLs on a PCI Device
diff --git a/drivers/fpga/dfl-afu-dma-region.c b/drivers/fpga/dfl/dfl-afu-dma-region.csimilarity index 100%rename from drivers/fpga/dfl-afu-dma-region.crename to drivers/fpga/dfl/dfl-afu-dma-region.cdiff --git a/drivers/fpga/dfl-afu-error.c b/drivers/fpga/dfl/dfl-afu-error.csimilarity index 100%rename from drivers/fpga/dfl-afu-error.crename to drivers/fpga/dfl/dfl-afu-error.cdiff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl/dfl-afu-main.csimilarity index 100%rename from drivers/fpga/dfl-afu-main.crename to drivers/fpga/dfl/dfl-afu-main.cdiff --git a/drivers/fpga/dfl-afu-region.c b/drivers/fpga/dfl/dfl-afu-region.csimilarity index 100%rename from drivers/fpga/dfl-afu-region.crename to drivers/fpga/dfl/dfl-afu-region.cdiff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl/dfl-afu.hsimilarity index 100%rename from drivers/fpga/dfl-afu.hrename to drivers/fpga/dfl/dfl-afu.hdiff --git a/drivers/fpga/dfl-fme-br.c b/drivers/fpga/dfl/dfl-fme-br.csimilarity index 100%rename from drivers/fpga/dfl-fme-br.crename to drivers/fpga/dfl/dfl-fme-br.cdiff --git a/drivers/fpga/dfl-fme-error.c b/drivers/fpga/dfl/dfl-fme-error.csimilarity index 100%rename from drivers/fpga/dfl-fme-error.crename to drivers/fpga/dfl/dfl-fme-error.cdiff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl/dfl-fme-main.csimilarity index 100%rename from drivers/fpga/dfl-fme-main.crename to drivers/fpga/dfl/dfl-fme-main.cdiff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl/dfl-fme-mgr.csimilarity index 100%rename from drivers/fpga/dfl-fme-mgr.crename to drivers/fpga/dfl/dfl-fme-mgr.cdiff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl/dfl-fme-perf.csimilarity index 100%rename from drivers/fpga/dfl-fme-perf.crename to drivers/fpga/dfl/dfl-fme-perf.cdiff --git a/drivers/fpga/dfl-fme-pr.c b/drivers/fpga/dfl/dfl-fme-pr.csimilarity index 100%rename from drivers/fpga/dfl-fme-pr.crename to drivers/fpga/dfl/dfl-fme-pr.cdiff --git a/drivers/fpga/dfl-fme-pr.h b/drivers/fpga/dfl/dfl-fme-pr.hsimilarity index 100%rename from drivers/fpga/dfl-fme-pr.hrename to drivers/fpga/dfl/dfl-fme-pr.hdiff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl/dfl-fme-region.csimilarity index 100%rename from drivers/fpga/dfl-fme-region.crename to drivers/fpga/dfl/dfl-fme-region.cdiff --git a/drivers/fpga/dfl-fme.h b/drivers/fpga/dfl/dfl-fme.hsimilarity index 100%rename from drivers/fpga/dfl-fme.hrename to drivers/fpga/dfl/dfl-fme.hdiff --git a/drivers/fpga/dfl-n3000-nios.c b/drivers/fpga/dfl/dfl-n3000-nios.csimilarity index 100%rename from drivers/fpga/dfl-n3000-nios.crename to drivers/fpga/dfl/dfl-n3000-nios.cdiff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl/dfl-pci.csimilarity index 100%rename from drivers/fpga/dfl-pci.crename to drivers/fpga/dfl/dfl-pci.cdiff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl/dfl.csimilarity index 100%rename from drivers/fpga/dfl.crename to drivers/fpga/dfl/dfl.cdiff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl/dfl.hsimilarity index 100%rename from drivers/fpga/dfl.hrename to drivers/fpga/dfl/dfl.h
--
2.26.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the dfl/ subdir part.
Create a dfl/ subdir
Move dfl-* files to it.
Add a Kconfig and Makefile
Because FPGA_DFL is now used in dfl/Kconfig in a if/endif
block, all the other configs in dfl/Kconfig implicitly depend
on FPGA_DFL. So the explicit dependence can be removed. Also
since FPGA_DFL depends on HAS_IOMEM, it can be removed from the
other configs.
Hm.. sounds like this change (remove HAS_IOMEM) is better to be split
into another patch. How do you think?
Thanks
Hao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tom Rix <trix@redhat.com> Date: 2021-06-15 20:48:35
On 6/15/21 1:08 AM, Wu, Hao wrote:
quoted
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
xrt is also not a vendor, more a subdevice framework like dfl.
I am not sure what you mean by other dfl vendors can you give an example ?
quoted
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the dfl/ subdir part.
Create a dfl/ subdir
Move dfl-* files to it.
Add a Kconfig and Makefile
Because FPGA_DFL is now used in dfl/Kconfig in a if/endif
block, all the other configs in dfl/Kconfig implicitly depend
on FPGA_DFL. So the explicit dependence can be removed. Also
since FPGA_DFL depends on HAS_IOMEM, it can be removed from the
other configs.
Hm.. sounds like this change (remove HAS_IOMEM) is better to be split
into another patch. How do you think?
I'll drop this from the patchset so this so patchset does the one thing
of moving stuff around and do the HAS_IOMEM change after stuff settles.
Tom
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
xrt is also not a vendor, more a subdevice framework like dfl.
I am not sure what you mean by other dfl vendors can you give an example ?
It's fine, but the description here is a little confusing on vendor/framework
handling. No other vendor so far, but it's possible, DFL can be used in
non-intel device, and related drivers can be reused as well. Then a fpga
mgr driver depends on DFL, should be put inside dfl folder or new
vendor's subfolder?
Hao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Moritz Fischer <mdf@kernel.org> Date: 2021-06-17 04:43:37
On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote:
quoted
On 6/15/21 1:08 AM, Wu, Hao wrote:
quoted
quoted
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
xrt is also not a vendor, more a subdevice framework like dfl.
I am not sure what you mean by other dfl vendors can you give an example ?
It's fine, but the description here is a little confusing on vendor/framework
handling. No other vendor so far, but it's possible, DFL can be used in
non-intel device, and related drivers can be reused as well. Then a fpga
mgr driver depends on DFL, should be put inside dfl folder or new
vendor's subfolder?
Hao
I'm somewhat neutral on this. If someone non-intel starts using DFL we could also
move the common parts back ...
That being said, I'm not super convinced we have to move stuff in the
first place.
- Moritz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote:
quoted
quoted
On 6/15/21 1:08 AM, Wu, Hao wrote:
quoted
quoted
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
xrt is also not a vendor, more a subdevice framework like dfl.
I am not sure what you mean by other dfl vendors can you give an example ?
It's fine, but the description here is a little confusing on vendor/framework
handling. No other vendor so far, but it's possible, DFL can be used in
non-intel device, and related drivers can be reused as well. Then a fpga
mgr driver depends on DFL, should be put inside dfl folder or new
vendor's subfolder?
Hao
I'm somewhat neutral on this. If someone non-intel starts using DFL we could
also
move the common parts back ...
That's fine.
That being said, I'm not super convinced we have to move stuff in the
first place.
I remember that the first submission of our code is having everything inside a sub
folder, but was suggested that to have everything moved out, this is why we have
dfl files here now. To be honest, I have the similar feeling as you, I didn't see any
strong reason to make this something we must do, but both solutions should be
fine. : )
Thanks
Hao
From: Tom Rix <trix@redhat.com> Date: 2021-06-17 13:21:14
On 6/17/21 1:34 AM, Wu, Hao wrote:
quoted
On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote:
quoted
quoted
On 6/15/21 1:08 AM, Wu, Hao wrote:
quoted
quoted
Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
Hi Tom,
Thanks for this patch. : )
DFL is not a vendor, but something can be shared/reused. It's possible that
other vendors reuse the same concepts and the drivers of DFL. If vendor
drivers need to be moved inside sub folders, then maybe it's better to
leave DFL in the parent folder?
xrt is also not a vendor, more a subdevice framework like dfl.
I am not sure what you mean by other dfl vendors can you give an example ?
It's fine, but the description here is a little confusing on vendor/framework
handling. No other vendor so far, but it's possible, DFL can be used in
non-intel device, and related drivers can be reused as well. Then a fpga
mgr driver depends on DFL, should be put inside dfl folder or new
vendor's subfolder?
Hao
I'm somewhat neutral on this. If someone non-intel starts using DFL we could
also
move the common parts back ...
That's fine.
quoted
That being said, I'm not super convinced we have to move stuff in the
first place.
I remember that the first submission of our code is having everything inside a sub
folder, but was suggested that to have everything moved out, this is why we have
dfl files here now. To be honest, I have the similar feeling as you, I didn't see any
strong reason to make this something we must do, but both solutions should be
fine. : )
xrt is bringing in the subdir xrt/
Even after the likely move of xrt subdevices to other subsystems, there
will be about as many files in fpga/xrt/ as in fpga/
If both of you are fine with a mixed files and subdir organization, then
I'll drop this patchset.
If you want only files, then xrt needs to refactor, so let them know.
Tom
From: Moritz Fischer <mdf@kernel.org> Date: 2021-06-18 22:04:09
On Thu, Jun 17, 2021 at 06:21:07AM -0700, Tom Rix wrote:
xrt is bringing in the subdir xrt/
That alone I don't mind too much.
Even after the likely move of xrt subdevices to other subsystems, there will
be about as many files in fpga/xrt/ as in fpga/
If both of you are fine with a mixed files and subdir organization, then
I'll drop this patchset.
You've done most of the work for this already, so we might as well
finish what you started :)
Thanks,
Moritz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the xilinx/ subdir part
Create a xilinx/ subdir
Move xilinx-* and zynq* files to it.
Add a Kconfig and Makefile
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/fpga/Kconfig | 40 +-------------
drivers/fpga/Makefile | 5 +-
drivers/fpga/xilinx/Kconfig | 55 +++++++++++++++++++
drivers/fpga/xilinx/Makefile | 6 ++
.../fpga/{ => xilinx}/xilinx-pr-decoupler.c | 0
drivers/fpga/{ => xilinx}/xilinx-spi.c | 0
drivers/fpga/{ => xilinx}/zynq-fpga.c | 0
drivers/fpga/{ => xilinx}/zynqmp-fpga.c | 0
8 files changed, 63 insertions(+), 43 deletions(-)
create mode 100644 drivers/fpga/xilinx/Kconfig
create mode 100644 drivers/fpga/xilinx/Makefile
rename drivers/fpga/{ => xilinx}/xilinx-pr-decoupler.c (100%)
rename drivers/fpga/{ => xilinx}/xilinx-spi.c (100%)
rename drivers/fpga/{ => xilinx}/zynq-fpga.c (100%)
rename drivers/fpga/{ => xilinx}/zynqmp-fpga.c (100%)
diff --git a/drivers/fpga/xilinx-pr-decoupler.c b/drivers/fpga/xilinx/xilinx-pr-decoupler.csimilarity index 100%rename from drivers/fpga/xilinx-pr-decoupler.crename to drivers/fpga/xilinx/xilinx-pr-decoupler.cdiff --git a/drivers/fpga/xilinx-spi.c b/drivers/fpga/xilinx/xilinx-spi.csimilarity index 100%rename from drivers/fpga/xilinx-spi.crename to drivers/fpga/xilinx/xilinx-spi.cdiff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/xilinx/zynq-fpga.csimilarity index 100%rename from drivers/fpga/zynq-fpga.crename to drivers/fpga/xilinx/zynq-fpga.cdiff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/xilinx/zynqmp-fpga.csimilarity index 100%rename from drivers/fpga/zynqmp-fpga.crename to drivers/fpga/xilinx/zynqmp-fpga.c
--
2.26.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jun 14, 2021 at 01:16:46PM -0700, trix@redhat.com wrote:
quoted hunk
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the xilinx/ subdir part
Create a xilinx/ subdir
Move xilinx-* and zynq* files to it.
Add a Kconfig and Makefile
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/fpga/Kconfig | 40 +-------------
drivers/fpga/Makefile | 5 +-
drivers/fpga/xilinx/Kconfig | 55 +++++++++++++++++++
drivers/fpga/xilinx/Makefile | 6 ++
.../fpga/{ => xilinx}/xilinx-pr-decoupler.c | 0
drivers/fpga/{ => xilinx}/xilinx-spi.c | 0
drivers/fpga/{ => xilinx}/zynq-fpga.c | 0
drivers/fpga/{ => xilinx}/zynqmp-fpga.c | 0
8 files changed, 63 insertions(+), 43 deletions(-)
create mode 100644 drivers/fpga/xilinx/Kconfig
create mode 100644 drivers/fpga/xilinx/Makefile
rename drivers/fpga/{ => xilinx}/xilinx-pr-decoupler.c (100%)
rename drivers/fpga/{ => xilinx}/xilinx-spi.c (100%)
rename drivers/fpga/{ => xilinx}/zynq-fpga.c (100%)
rename drivers/fpga/{ => xilinx}/zynqmp-fpga.c (100%)
+ default y
+ help
+ If you have a xilinx fpga, say Y.
"Xilix FPGA"
But how about being a bit more descriptive here:
"Select this option if you want to enable support for Xilinx FPGA
drivers"
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about xilinx fpgas. If you say Y, you will be asked
+ for your specific device in the following questions.
Why this "note"? Do networking drivers have this type of description?
Same for the other patches in this series.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tom Rix <trix@redhat.com> Date: 2021-06-15 20:19:25
On 6/15/21 12:36 AM, Greg KH wrote:
On Mon, Jun 14, 2021 at 01:16:46PM -0700, trix@redhat.com wrote:
quoted
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the xilinx/ subdir part
Create a xilinx/ subdir
Move xilinx-* and zynq* files to it.
Add a Kconfig and Makefile
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/fpga/Kconfig | 40 +-------------
drivers/fpga/Makefile | 5 +-
drivers/fpga/xilinx/Kconfig | 55 +++++++++++++++++++
drivers/fpga/xilinx/Makefile | 6 ++
.../fpga/{ => xilinx}/xilinx-pr-decoupler.c | 0
drivers/fpga/{ => xilinx}/xilinx-spi.c | 0
drivers/fpga/{ => xilinx}/zynq-fpga.c | 0
drivers/fpga/{ => xilinx}/zynqmp-fpga.c | 0
8 files changed, 63 insertions(+), 43 deletions(-)
create mode 100644 drivers/fpga/xilinx/Kconfig
create mode 100644 drivers/fpga/xilinx/Makefile
rename drivers/fpga/{ => xilinx}/xilinx-pr-decoupler.c (100%)
rename drivers/fpga/{ => xilinx}/xilinx-spi.c (100%)
rename drivers/fpga/{ => xilinx}/zynq-fpga.c (100%)
rename drivers/fpga/{ => xilinx}/zynqmp-fpga.c (100%)
+ default y
+ help
+ If you have a xilinx fpga, say Y.
"Xilix FPGA"
Ok.
But how about being a bit more descriptive here:
"Select this option if you want to enable support for Xilinx FPGA
drivers"
ok
quoted
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about xilinx fpgas. If you say Y, you will be asked
+ for your specific device in the following questions.
Why this "note"? Do networking drivers have this type of description?
Yes, the NET_VENDOR_* configs all have this boilerplate.
Tom
Same for the other patches in this series.
thanks,
greg k-h
On Tue, Jun 15, 2021 at 01:19:11PM -0700, Tom Rix wrote:
On 6/15/21 12:36 AM, Greg KH wrote:
quoted
On Mon, Jun 14, 2021 at 01:16:46PM -0700, trix@redhat.com wrote:
quoted
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the xilinx/ subdir part
Create a xilinx/ subdir
Move xilinx-* and zynq* files to it.
Add a Kconfig and Makefile
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/fpga/Kconfig | 40 +-------------
drivers/fpga/Makefile | 5 +-
drivers/fpga/xilinx/Kconfig | 55 +++++++++++++++++++
drivers/fpga/xilinx/Makefile | 6 ++
.../fpga/{ => xilinx}/xilinx-pr-decoupler.c | 0
drivers/fpga/{ => xilinx}/xilinx-spi.c | 0
drivers/fpga/{ => xilinx}/zynq-fpga.c | 0
drivers/fpga/{ => xilinx}/zynqmp-fpga.c | 0
8 files changed, 63 insertions(+), 43 deletions(-)
create mode 100644 drivers/fpga/xilinx/Kconfig
create mode 100644 drivers/fpga/xilinx/Makefile
rename drivers/fpga/{ => xilinx}/xilinx-pr-decoupler.c (100%)
rename drivers/fpga/{ => xilinx}/xilinx-spi.c (100%)
rename drivers/fpga/{ => xilinx}/zynq-fpga.c (100%)
rename drivers/fpga/{ => xilinx}/zynqmp-fpga.c (100%)
+ default y
+ help
+ If you have a xilinx fpga, say Y.
"Xilix FPGA"
Ok.
quoted
But how about being a bit more descriptive here:
"Select this option if you want to enable support for Xilinx FPGA
drivers"
ok
quoted
quoted
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about xilinx fpgas. If you say Y, you will be asked
+ for your specific device in the following questions.
Why this "note"? Do networking drivers have this type of description?
Yes, the NET_VENDOR_* configs all have this boilerplate.
The first example I found drivers/net/ethernet/cavium/Kconfig, did not.
But you are right, others do.
But fix the case issues in this text please. Vendors get mad enough
when we use their names, we should at least get the case correct when
using them.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera/altera-cvp.csimilarity index 100%rename from drivers/fpga/altera-cvp.crename to drivers/fpga/altera/altera-cvp.cdiff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera/altera-fpga2sdram.csimilarity index 100%rename from drivers/fpga/altera-fpga2sdram.crename to drivers/fpga/altera/altera-fpga2sdram.cdiff --git a/drivers/fpga/altera-freeze-bridge.c b/drivers/fpga/altera/altera-freeze-bridge.csimilarity index 100%rename from drivers/fpga/altera-freeze-bridge.crename to drivers/fpga/altera/altera-freeze-bridge.cdiff --git a/drivers/fpga/altera-hps2fpga.c b/drivers/fpga/altera/altera-hps2fpga.csimilarity index 100%rename from drivers/fpga/altera-hps2fpga.crename to drivers/fpga/altera/altera-hps2fpga.cdiff --git a/drivers/fpga/altera-pr-ip-core-plat.c b/drivers/fpga/altera/altera-pr-ip-core-plat.csimilarity index 100%rename from drivers/fpga/altera-pr-ip-core-plat.crename to drivers/fpga/altera/altera-pr-ip-core-plat.cdiff --git a/drivers/fpga/altera-pr-ip-core.c b/drivers/fpga/altera/altera-pr-ip-core.csimilarity index 100%rename from drivers/fpga/altera-pr-ip-core.crename to drivers/fpga/altera/altera-pr-ip-core.cdiff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera/altera-ps-spi.csimilarity index 100%rename from drivers/fpga/altera-ps-spi.crename to drivers/fpga/altera/altera-ps-spi.cdiff --git a/drivers/fpga/socfpga-a10.c b/drivers/fpga/altera/socfpga-a10.csimilarity index 100%rename from drivers/fpga/socfpga-a10.crename to drivers/fpga/altera/socfpga-a10.cdiff --git a/drivers/fpga/socfpga.c b/drivers/fpga/altera/socfpga.csimilarity index 100%rename from drivers/fpga/socfpga.crename to drivers/fpga/altera/socfpga.cdiff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/altera/stratix10-soc.csimilarity index 100%rename from drivers/fpga/stratix10-soc.crename to drivers/fpga/altera/stratix10-soc.cdiff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/altera/ts73xx-fpga.csimilarity index 100%rename from drivers/fpga/ts73xx-fpga.crename to drivers/fpga/altera/ts73xx-fpga.c
--
2.26.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tom Rix <trix@redhat.com>
Follow drivers/net/ethernet/ which has control configs
NET_VENDOR_BLA that map to drivers/net/ethernet/bla
Since fpgas do not have many vendors, drop the 'VENDOR' and use
FPGA_BLA.
There are several new subdirs
altera/
dfl/
lattice/
xilinx/
Each subdir has a Kconfig that has a new/reused
if FPGA_BLA
... existing configs ...
endif FPGA_BLA
Which is sourced into the main fpga/Kconfig
Each subdir has a Makefile whose transversal is controlled in the
fpga/Makefile by
obj-$(CONFIG_FPGA_BLA) += bla/
This is the lattice/ subdir part.
Create a lattice/ subdir
Move ice40* and machxo2* files to it.
Add a Kconfig and Makefile
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/fpga/Kconfig | 14 +-----------
drivers/fpga/Makefile | 13 ++++-------
drivers/fpga/lattice/Kconfig | 29 ++++++++++++++++++++++++
drivers/fpga/lattice/Makefile | 4 ++++
drivers/fpga/{ => lattice}/ice40-spi.c | 0
drivers/fpga/{ => lattice}/machxo2-spi.c | 0
6 files changed, 39 insertions(+), 21 deletions(-)
create mode 100644 drivers/fpga/lattice/Kconfig
create mode 100644 drivers/fpga/lattice/Makefile
rename drivers/fpga/{ => lattice}/ice40-spi.c (100%)
rename drivers/fpga/{ => lattice}/machxo2-spi.c (100%)
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/lattice/ice40-spi.csimilarity index 100%rename from drivers/fpga/ice40-spi.crename to drivers/fpga/lattice/ice40-spi.cdiff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/lattice/machxo2-spi.csimilarity index 100%rename from drivers/fpga/machxo2-spi.crename to drivers/fpga/lattice/machxo2-spi.c
--
2.26.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel