Message ID | 1615168776-8553-1-git-send-email-yilun.xu@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | UIO support for dfl devices | expand |
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&A 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/YDvQ8aO8v3NhLKzx@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/YDvQ8aO8v3NhLKzx@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
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&A 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/YDvQ8aO8v3NhLKzx@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/YDvQ8aO8v3NhLKzx@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
Hi Xu, On Wed, Mar 24, 2021 at 04:22:17PM +0800, Xu Yilun wrote: > 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? In its current form it's a UIO driver and needs at least Greg's Acked-by before I could apply it. Greg, can you take another look? > > 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&A 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/YDvQ8aO8v3NhLKzx@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/YDvQ8aO8v3NhLKzx@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 Thanks, Moritz
On Tue, Mar 16, 2021 at 01:10:05PM +0800, Xu Yilun wrote: > Hi Greg: > > I listed below some answers from Moritz and Yilun from previous mails for > your question. > > Do you have more comments? Nah, it's fine, now queued up, thanks. greg k-h