linux-kernel - RE: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Dec 2020 02:44:58 +0000
From:   "Wu, Hao" <hao.wu@...el.com>
To:     Tom Rix <trix@...hat.com>, "Xu, Yilun" <yilun.xu@...el.com>,
        "mdf@...nel.org" <mdf@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "lgoncalv@...hat.com" <lgoncalv@...hat.com>
Subject: RE: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device support
 for DFL devices


> Subject: Re: [PATCH v3 2/3] fpga: dfl: add the userspace I/O device support
> for DFL devices
> 
> On 12/18/20 12:05 AM, Wu, Hao wrote:
> >> Subject: [PATCH v3 2/3] 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 matches DFL devices in a different way. It has no device id
> >> table, instead it matches any DFL device which could not be handled by
> >> other DFL drivers.
> > Looks like we want to build UIO driver as the default/generic driver for DFL,
> > it seems fine but my concern is that UIO has its own limitation, if some day,
> > dfl device is extended, but UIO has limitation, then we may need to select
> > another one as the default driver.. or we can just match them using
> > id_table as we know UIO meets the requirement for those DFL devices?
> 
> When we have multiple defaults, could this be handled in the configury ?

Do you mean select it using configuration options? But if people have already
created the software stack on the old one, then it's a valid requirement that
we need both old and new defaults working at the same time... it's hard to
ask everybody to switch to the new one.

Hao

> 
> Tom
>