linux-kernel - RE: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support

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: <BE8371DA886269458E0220A16DC1F8277D619CB7@SHSMSX101.ccr.corp.intel.com>
Date:   Wed, 5 Apr 2017 11:40:05 +0000
From:   "Wu, Hao" <hao.wu@...el.com>
To:     Alan Tull <atull@...nel.org>
CC:     Moritz Fischer <moritz.fischer@...us.com>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Kang, Luwei" <luwei.kang@...el.com>,
        "Zhang, Yi Z" <yi.z.zhang@...el.com>,
        "Whisonant, Tim" <tim.whisonant@...el.com>,
        "Luebbers, Enno" <enno.luebbers@...el.com>,
        "Rao, Shiva" <shiva.rao@...el.com>,
        "Rauer, Christopher" <christopher.rauer@...el.com>,
        "Tull, Alan" <alan.tull@...el.com>,
        Xiao Guangrong <guangrong.xiao@...ux.intel.com>
Subject: RE: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub
 feature support

> >> The  fpga_image_info struct started life as just image specific info,
> >> but I want it to go in the direction of including parameters needed to
> >> program it this specific time. Otherwise we are stuck having to keep
> >> adding parameters as our use of FPGA develops.  It probably could be
> >> documented better as 'information needed to program a FPGA image'
> >> rather than strictly 'information about this particular FPGA image'.
> >> My patch "fpga-mgr: pass parameters for loading fpga in image info"
> >> goes in this direction by having the buf, firmware name, or sg list
> >> passed in the info for the added fpga_mgr_load() function.  Actually I
> >> should probably simplify the API and get rid of fpga_mgr_buf_load,
> >> fpga_mgr_buf_load_sg, and fpga_mgr_firmware_load and require people to
> >> use fpga_mgr_load (passing all parameters in fpga_image_info).
> >>
> >
> > Make sense.
> >
> >> > It may be a
> >> > little confusing. One rough idea is that keep this info under fpga region
> >> > (maybe its private data), and pass the fpga-region to fpga_mgr_buf_load,
> >>
> >> Yes, keep this info in fpga-region.  When the region wants to program
> >> using fpga-mgr, add the region id to fpga_image_info.  I propose
> >> calling it region_id.
> >
> > Hm.. Do we need a function which moves info from region to image info?
> 
> No, just code that sets that variable in the struct before calling the
> fpga_region_program_fpga function.
>
> >
> > Another idea is, add a priv to fpga_image_info, and use a common function
> > to pass the fpga_region's priv to fpga_image_info's priv before PR.
> > fpga-mgr then knows fpga_region priv info from the fpga_image_info.
> >
> 
> Adding priv would make the interface for fpga-mgr non-uniform.  The point
> of having a fpga-mgr framework is that there
> is the potential of the upper layers working for different FPGA devices.
> If the interface for each FPGA device were different, that would then
> be broken.
> 

I mean drivers can register their own fpga-mgr ops, and handle priv of
fpga_image_info in driver specific way for pr (e.g write_init function).
We don't need to change the any upper layer interfaces.

If you prefer the region_id for fpga_image_info, we can go with region_id
for sure. : )

Thanks
Hao