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]
Date:   Sat, 1 Apr 2017 20:18:04 +0800
From:   Wu Hao <hao.wu@...el.com>
To:     matthew.gerlach@...ux.intel.com
Cc:     Greg KH <greg@...ah.com>, 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 12:01:13PM -0700, matthew.gerlach@...ux.intel.com wrote:
> On Fri, 31 Mar 2017, Wu Hao wrote:
> >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
> 
> I completely understand the need for a container device.  The fpga-region is
> also primarily a container, and in some cases the fpga-region may represent
> the entire fpga.  Over time this code may become redundant.

Thanks a lot for your review and comments.

I feel that the fpga-region implies that it supports reconfiguration, but
in our cases, the Intel FPGA device, doesn't have base fpga-region for
full reconfiguration, but many accelerators with partial reconfiguration
support. A fpga-region brings together everything needed for the
reconfiguration, and a fpga-dev is trying to brings everything on a FPGA
device together, including fpga-region/bridge/manager, access different
accelerators and other function units.

I think it's not mandatory to use fpga-dev, as fpga-dev is just trying to
provide one more option here for some complex hardware.

Thanks
Hao
 
> >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
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> >the body of a message to majordomo@...r.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >