From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1996015-1517441021-2-2453066881298807757 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='org', MailFrom='org' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: linux-api-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1517441021; b=O5fEes0pT7tTJatqCaFIYJX85+DZwgItJPkwNrHjuchajmC J+8j749Psj6eVZKVNVkMzEwZ4aXv7LK2a7Is7lFCZ+U8B4RJ2r5Cns10OyX6sy+R 9om8PJeDgg1c1MVTryzj+s02xkjW7UJ5tK6QJ2dmLdqBp9kTLx/ZuUXY1EXQB4Tk ihd0mkop2OfJKOsrhIAVUcKEjvUv9XOmswpgHf4vXBVsX6X/zUN9Oquz95bfIMgH c9LAmPrml3tD6i+xy2KYbOc4GjZnoPU0m0+JflUlimKmhSBJp0aanXeI3PWqme+W I52C3xik4GgDpSCxeMqiin0kN6Q2C3eVF94ORUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:in-reply-to:references:from :date:message-id:subject:to:cc:content-type:sender:list-id; s= arctest; t=1517441021; bh=mVX7JTlooeIiZzl4eW4dJefH3+PVQIwGwiYhrn LUPvY=; b=ecL2uncO6p7Od3VmrbwX4q1mBU1fWsmbythF1kztBVH3Hrdk+mBLIx 4ErcV4BwPy18jEgjWABfwxBtBrtgI9Y4TM8krHpxY5rHtL/C6vjRzItgPyYuU3lm IHegIj//6/xYb5uxJSIUEX9dnaCi5qrWvq4R7D6iMq8e93C9RJbPNDDPzIx2U1rw uwnhZ6eZpwwRM7OrVsvC5p/3dvHIqqVwsoxEn39hODYp7FnGYXZeS/1w8xnIdsyb 7Xp4peH/iOsDn5RS70GF8dFNok2vGk6WFCdPcU/OiHA1pMAKaiKbL9rKiMNrlHVN 4wzA0Um1kZ8rspPYggte1snFdkZofbNg== ARC-Authentication-Results: i=1; mx1.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes Authentication-Results: mx1.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753706AbeAaXXi (ORCPT ); Wed, 31 Jan 2018 18:23:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:33768 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbeAaXXh (ORCPT ); Wed, 31 Jan 2018 18:23:37 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F16CD21796 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=atull@kernel.org X-Google-Smtp-Source: AH8x225xfRRIE69e9cxwBe3chw0OfiIFKjC5KAfkbgwoIq0Qby5MPRWIp+6IGP0oxW1lDSW1mv9b2TxLGnWcehU1H2o= MIME-Version: 1.0 In-Reply-To: <20171222084501.GA10662@hao-dev> References: <1511764948-20972-1-git-send-email-hao.wu@intel.com> <1511764948-20972-5-git-send-email-hao.wu@intel.com> <20171221072242.GB4861@hao-dev> <20171222084501.GA10662@hao-dev> From: Alan Tull Date: Wed, 31 Jan 2018 17:22:55 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 04/21] fpga: add device feature list support To: Wu Hao Cc: Moritz Fischer , linux-fpga@vger.kernel.org, linux-kernel , linux-api@vger.kernel.org, "Kang, Luwei" , "Zhang, Yi Z" , Tim Whisonant , Enno Luebbers , Shiva Rao , Christopher Rauer Content-Type: text/plain; charset="UTF-8" Sender: linux-api-owner@vger.kernel.org X-Mailing-List: linux-api@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Dec 22, 2017 at 2:45 AM, Wu Hao wrote: >> > > >> > > I see that the port code is included as part of the enumeration code. >> > > This is not very future-proofed, if a different port needs to be >> > > supported. >> > > >> > > The port is a FPGA fabric based bridge with expanded functionality, >> > > right? So it is similar to the altera freeze bridge, but adds the >> > > ability to reset the fabric and some other features are promised in >> > > the future, IIUC. I still think that the port could be implemented in >> > > the bridge driver .c file instead of being here as part of the >> > > enumeration code. For that to happen, some APIs would need to be >> > > added to the bridge framework and the FPGA region framework. Then the >> > > reset can be requested through a new FPGA region API function. >> > > >> > > The advantage of this is that if this patchset evolves and there is >> > > some other v2 port driver needed, it can be a different driver if it >> > > needs to be. >> > > >> > > If the port reset is really a fabric reset, >> > >> > Actually 'fabric reset' is probably not clear enough. It's resetting >> > the hardware in a partial reconfiguration region, not just resetting >> > the bridge. I'm trying to come up with a term that makes that clear >> > what is getting reset is the contents of the region. >> > >> > > (correct me if I'm >> > > remembering wrongly) then it would be helpful to call it a >> > > fabric_reset. This would be the first bridge driver supporting fabric >> > > reset. I think it won't be the last. >> > > >> > > So what I'm proposing would be added/changed would be: >> > > * move all the bridge code to fpga-dfl-fme-br.c >> > > * add .fabric_reset to bridge ops >> > > * add fpga_bridges_reset to fpga-bridge.c (a new function that goes >> > > through a list of bridges and calls the reset ops if it exists, >> > > ignores the bridges where it doesn't exist) >> > > * add fpga_region_fabric_reset to fpga-region.c. This function gets >> > > the region, gets the bridges, calls fpga_bridges_reset (can steal code >> > > from fpga_region_program_fpga) >> > > * the rest of the patchset can use fpga_region_fabric_reset instead of >> > > fpga_port_reset >> >> Hi Alan >> >> Actually I think we can't move all the bridge code to fpga-dfl-fme-br.c as >> this bridge (and region) is created by FME PR sub feature code, mainly for >> PR function. But user may need the reset function when run some workload >> on target Port/AFU, if consider virtualization case (SRIOV), there is only >> Port/AFU in each VF, and no FME in VF (that means nobody creates the fpga >> region/bridge/region). So it's need from port platform driver side as well. >> >> The orignal idea that creates fpga-mgr/bridges/regions under FME, is that >> even we turned all Ports/AFUs into VFs (user can not see port platform >> device and the user interfaces exposed by port driver on PF), but user >> still can use FME to do PR to those Ports/AFUs in turned into VFs (assigned >> in different virtual machines). >> >> I fully agree with you, that we should avoid feature specific code in the >> common enumeration code and feature device framework if possible. I guess >> I need some time to check and see if any other solutions (e.g export those >> functions from port driver not DFL framework). Will back here once I have >> some clear idea.:) > > Hi Alan > > I checked further on this, it seems no good method to avoid feature_dev > specific code (e.g port/fme related code) in DFL framework, as it needs to > manage feature devices for virtualization cases. I tried that, make some > changes that the port reset code could be exported by the port platform > device instead, and fpga-dfl-fme-br.c depends on port platform device to > implement the bridge ops, but 1) it introduced more dependency between > these driver modules which seems not good. (ideally it's better that PR > could be done by FME module itself, no need to have some dependency on > other modules, e.g Port). 2) still have other port code (e.g fpga_port_id > which is useful for port management code in framework) can't be moved to > port platform driver module in the same method. As hardware is designed > this way, even we see separated device features in the DFL, but they have > a lot of dependency internally in different use cases (e.g PR, SRIOV and > etc). Hi Hao, OK, well sounds like it's not feasible then. Thanks for looking into it. Alan > > Thanks > Hao > >> >> Thanks >> Hao >> >> > > >> > > Alan >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html