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:   Wed, 5 Apr 2017 11:40:05 +0000
From:   "Wu, Hao" <>
To:     Alan Tull <>
CC:     Moritz Fischer <>,
        "" <>,
        linux-kernel <>,
        "Kang, Luwei" <>,
        "Zhang, Yi Z" <>,
        "Whisonant, Tim" <>,
        "Luebbers, Enno" <>,
        "Rao, Shiva" <>,
        "Rauer, Christopher" <>,
        "Tull, Alan" <>,
        Xiao Guangrong <>
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. : )


Powered by blists - more mailing lists