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  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:   Tue, 4 Apr 2017 17:09:23 -0500
From:   Alan Tull <atull@...nel.org>
To:     Wu Hao <hao.wu@...el.com>
Cc:     Moritz Fischer <moritz.fischer@...us.com>,
        linux-fpga@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        luwei.kang@...el.com, yi.z.zhang@...el.com,
        Xiao Guangrong <guangrong.xiao@...ux.intel.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>
Subject: Re: [PATCH 04/16] fpga: intel: pcie: parse feature list and create
 platform device for features.

On Thu, Mar 30, 2017 at 7:08 AM, Wu Hao <hao.wu@...el.com> wrote:
> From: Xiao Guangrong <guangrong.xiao@...ux.intel.com>
>
> Device Featuer List structure creates a link list of feature headers
> within the MMIO space to provide an extensiable way of adding features.
>
> The Intel FPGA PCIe driver walks through the feature headers to enumerate
> feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> Function Unit (AFU), and their private sub features. For feature devices,
> it creates the platform devices and linked the private sub features into
> their platform data.
>

I'm still looking at this code and it's pretty new to me, but I think
it would be desirable and not really hard to separate the code
that enumerates from all the fixed feature code.  So pcie.c could see
that there is a pci device out there that it knows has these memory
mapped enumeration structs.  So it goes and reads the structs, parses
them, and knows what drivers to probe.  The FME and AFU and other
fpga device drivers could register their guids with the framework
and be discoverable in that way.

That way if you need to implement a different FME or anything else, it
could be added with a new guid to this framework and would get
enumerated.  I'm thinking of the future and of more general usability
of this code.

Then the enumeration code wouldn't have to be 'intel' code or even
code dedicated to FME's and AFU's.  Any FPGA with a PCIe
port that has the right id's could have this struct and use this
enumeration method.  Actually if the parse* enumeration code could be in a
separate file as helper functions for the pcie code, this stuff would
be structured for future support this of the same framework on
embedded FPGA devices.

Alan

Powered by blists - more mailing lists