linux-kernel - Re: [PATCH 02/16] fpga: add FPGA device framework

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]

Message-ID: <20170331074842.GA17067@hao-dev>
Date:   Fri, 31 Mar 2017 15:48:42 +0800
From:   Wu Hao <hao.wu@...el.com>
To:     Greg KH <greg@...ah.com>
Cc:     atull@...nel.org, moritz.fischer@...us.com,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        luwei.kang@...el.com, yi.z.zhang@...el.com,
        Tim Whisonant <tim.whisonant@...el.com>,
        Enno Luebbers <enno.luebbers@...el.com>,
        Shiva Rao <shiva.rao@...el.com>,
        Christopher Rauer <christopher.rauer@...el.com>,
        Xiao Guangrong <guangrong.xiao@...ux.intel.com>
Subject: Re: [PATCH 02/16] fpga: add FPGA device framework

On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote:
> On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote:
> > During FPGA device (e.g PCI-based) discovery, platform devices are
> > registered for different FPGA function units. But the device node path
> > isn't quite friendly to applications.
> > 
> > Consider this case, applications want to access child device's sysfs file
> > for some information.
> > 
> > 1) Access using bus-based path (e.g PCI)
> > 
> >   /sys/bus/pci/devices/xxxxx/fpga_func_a.0/sysfs_file
> > 
> >   From the path, it's clear which PCI device is the parent, but not perfect
> >   solution for applications. PCI device BDF is not fixed, application may
> >   need to search all PCI device to find the actual FPGA Device.
> > 
> > 2) Or access using platform device path
> > 
> >   /sys/bus/platform/devices/fpga_func_a.0/sysfs_file
> > 
> >   Applications find the actual function by name easily, but no information
> >   about which fpga device it belongs to. It's quite confusing if multiple
> >   FPGA devices are in one system.
> > 
> > 'FPGA Device' class is introduced to resolve this problem. Each node under
> > this class represents a fpga device, which may have one or more child
> > devices. Applications only need to search under this FPGA Device class
> > folder to find the child device node it needs.
> > 
> > For example, for the platform has 2 fpga devices, each fpga device has
> > 3 child devices, the hierarchy looks like this.
> > 
> > Two nodes are under /sys/class/fpga/:
> > /sys/class/fpga/fpga.0
> > /sys/class/fpga/fpga.1
> > 
> > Each node has 1 function A device and 2 function B devices:
> > /sys/class/fpga/fpga.0/func_a.0
> > /sys/class/fpga/fpga.0/func_b.0
> > /sys/class/fpga/fpga.0/func_b.1
> > 
> > /sys/class/fpga/fpga.1/func_a.1
> > /sys/class/fpga/fpga.1/func_b.2
> > /sys/class/fpga/fpga.1/func_b.3
> > 
> > This following APIs are provided by FPGA device framework:
> > * fpga_dev_create
> >   Create fpga device under the given parent device.
> > * fpga_dev_destroy
> >   Destroy fpga device
> > 
> > The following sysfs files are created:
> > * /sys/class/fpga/<fpga.x>/name
> >   Name of the fpga device.
> 
> How does this interact with the existing "fpga class" that is in the
> kernel already?

The fpga-dev introduced by this patch, is only a container device, and
drivers could register different functions under it. Per my understanding,
the existing "fpga class", including fpga-region, fpga-bridge and 
fpga-manager, is used to provide reconfiguration function for FPGA. So
driver can create child node using this existing "fpga class" to provide
FPGA reconfiguration function, and more nodes under this container for
different functions for given FPGA device.

For Intel FPGA device, partial reconfiguration is only one function of 
Intel FPGA Management Engine (FME). FME driver creates fpga_manager under
below path for partial reconfiguration, and other interfaces for more
functions, e.g power management, virtualization support and etc.

/sys/class/fpga/<fpga.x>/<intel-fpga-fme.x>/fpga_manager

Thanks
Hao

> 
> thanks,
> 
> greg k-h