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:   Wed, 3 May 2017 19:58:31 +0800
From:   Wu Hao <hao.wu@...el.com>
To:     Alan Tull <atull@...nel.org>
Cc:     Moritz Fischer <moritz.fischer@...us.com>,
        linux-kernel@...r.kernel.org, linux-fpga@...r.kernel.org
Subject: Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
> Add two functions for getting the FPGA bridge from the device
> rather than device tree node.  This is to enable writing code
> that will support using FPGA bridges without device tree.
> Rename one old function to make it clear that it is device
> tree-ish.  This leaves us with 3 functions for getting a bridge:
> 
> * fpga_bridge_get
>   Get the bridge given the device.
> 
> * fpga_bridges_get_to_list
>   Given the device, get the bridge and add it to a list.
> 
> * of_fpga_bridges_get_to_list
>   Renamed from priviously existing fpga_bridges_get_to_list.
>   Given the device node, get the bridge and add it to a list.
> 

Hi Alan

Thanks a lot for providing this patch set for non device tree support. :)
Actually I am reworking the Intel FPGA device drivers based on this patch
set, and I find some problems with the existing APIs including fpga bridge
and manager. My idea is to create all fpga bridges/regions/manager under
the same platform device (FME), it allows FME driver to establish the
relationship for the bridges/regions/managers it creates in an easy way.
But I found current fpga class API doesn't support this very well.
e.g fpga_bridge_get/get_to_list only accept parent device as the input
parameter, but it doesn't work if we have multiple bridges (and
regions/manager) under the same platform device. fpga_mgr has similar
issue, but fpga_region APIs work better, as they accept fpga_region as
parameter not the shared parent device.

Do you think if having multiple fpga-* under one parent device is in the
right direction? If yes, shall we provide some more APIs which accept
fpga_bridge (and same for fpga-mgr) as parameter instead of the parent
device just like fpga-region?

Thanks
Hao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ