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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon,  8 Mar 2021 09:59:34 +0800
From:   Xu Yilun <yilun.xu@...el.com>
To:     gregkh@...uxfoundation.org, mdf@...nel.org,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     trix@...hat.com, lgoncalv@...hat.com, yilun.xu@...el.com,
        hao.wu@...el.com
Subject: [PATCH v12 0/2] UIO support for dfl devices

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