From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp09.au.ibm.com ([202.81.31.142]:35078 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbaKYJ2L (ORCPT ); Tue, 25 Nov 2014 04:28:11 -0500 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Nov 2014 19:28:06 +1000 Received: from d23relay08.au.ibm.com (d23relay08.au.ibm.com [9.185.71.33]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 43D452BB0068 for ; Tue, 25 Nov 2014 20:28:04 +1100 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAP9S0oN39387216 for ; Tue, 25 Nov 2014 20:28:00 +1100 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAP9S3sv021497 for ; Tue, 25 Nov 2014 20:28:03 +1100 Date: Tue, 25 Nov 2014 17:28:01 +0800 From: Wei Yang To: Gavin Shan Cc: Bjorn Helgaas , Wei Yang , benh@au1.ibm.com, linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH V9 08/18] powrepc/pci: Refactor pci_dn Message-ID: <20141125092801.GA3931@richard> Reply-To: Wei Yang References: <1414942894-17034-1-git-send-email-weiyang@linux.vnet.ibm.com> <1414942894-17034-9-git-send-email-weiyang@linux.vnet.ibm.com> <20141119233024.GF23467@google.com> <20141120072057.GC8562@richard> <20141120190541.GA5110@google.com> <20141121000411.GA19858@shangw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20141121000411.GA19858@shangw> Sender: linux-pci-owner@vger.kernel.org List-ID: On Fri, Nov 21, 2014 at 11:04:11AM +1100, Gavin Shan wrote: >>> 2.4 The potential problem for [Patch 08/18] >>> =============================================================================== >>> According to the SPEC, the offset/stride will change after each >>> sriov_enable(). This means the bus/devfn will change after each >>> sriov_enable(). >>> >>> My current thought is to fix it up in virtfn_add(). If the total VF number >>> will not change, we could create those pci_dn at the beginning and fix the >>> bus/devfn at each time the VF is truely created. >> >>By "fix it up," I assume you mean call an arch function that does the >>pci_pdn setup you need. >> >>It sounds reasonable to do this either in virtfn_add()/virtfn_remove() or >>at the points where we write PCI_SRIOV_CTRL_VFE, i.e., in sriov_init(), >>sriov_enable(), sriov_disable(), and sriov_restore_state(). From a >>hardware point of view, the VFs exist whenever PCI_SRIOV_CTRL_VFE is set, >>so it might be nice to have this setup connected to that. >> > >Yes, Both ways can fix the issue. For couple reasons, I want add weak >pcibios_virtfn_add(), which is called in virtfn_add() if you agree. > >- PCI_SRIOV_CTRL_VFE might be set somewhere except the functions you pointed. > Set/clear PCI_SRIOV_CTRL_VFE will invoke background work to check pci_dn > and add/remove accordingly. It would be overhead which we can avoid. >- We plan to support EEH for VFs in future. virtfn_add() way matches with > current EEH implementation better. EEH device and PE are created based > on (struct pci_dev), and EEH devices and PE can be destroied in time in > pcibios_release_device(), which is invoked by virtfn_remove(). So we only > need one weak function. In contrast, we have to create EEH device and PE > for VFs a bit early before any VFs are instantiated, and destroy them a > bit late after all VFs are offline. > Bjorn, Since my mail box got some problem in the last few days, I am not sure you agree with Gavin's proposal or not? And if you agree to enumerate the maximum VF bus range, I will add this logic in the next versin. >Thanks, >Gavin > >>Bjorn >> > >-- >To unsubscribe from this list: send the line "unsubscribe linux-pci" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Richard Yang Help you, Help me