linux-kernel - Re: [PATCH v2 02/22] 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:   Thu, 27 Jul 2017 14:10:01 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Alan Tull <atull@...nel.org>
Cc:     Wu Hao <hao.wu@...el.com>, Moritz Fischer <mdf@...nel.org>,
        linux-fpga@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "Kang, Luwei" <luwei.kang@...el.com>,
        "Zhang, Yi Z" <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>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 02/22] fpga: add FPGA device framework

On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull <atull@...nel.org> wrote:
> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao <hao.wu@...el.com> wrote:
>
> Hi Rob,
>
> I was hoping to pick your brain a bit on a DT question.
>
>> 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.
>
> There's a proposal for adding sysfs nodes that correspond to each FPGA
> device., with the devices located on each FPGA under them.  It makes
> it easier to see which device is on which FPGA.

Makes sense.

>> '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

A class is generally what is the function of the device, not how it is
attached. Seems like what you want here is a new bus type if the
existing PCI and platform bus types don't work.

>
> I can see the value of having sysfs nodes that correspond to fpga
> devices and being able to find devices under them.  I'm thinking what
> that would mean for Device Tree when fpga-dev is used on DT enabled
> systems.  In Device Tree, what is a fpga-dev?

Just properly setting the parent struct device on the functions should
be enough to figure out which function is in which fpga. I don't see
why a new class is needed.

> Currently the DT would have a FPGA bridge corresponding to each FPGA's
> hardware bridge and a heirarchy of bridges, regions and devices under
> it.  On systems that don't support partial reconfiguration under the
> OS (so not main bridge that was controlled by the OS), there would be
> a FPGA region, then its child regions, bridges, and devices.

The FPGA bridges could instantiate fpga bus type devices instead of
platform devices. That's really up to Linux and outside the scope of
the bindings.

Rob