Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756902Ab3EWGnX (ORCPT ); Thu, 23 May 2013 02:43:23 -0400 Received: from mail-qa0-f53.google.com ([209.85.216.53]:55856 "EHLO mail-qa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616Ab3EWGnR (ORCPT ); Thu, 23 May 2013 02:43:17 -0400 MIME-Version: 1.0 In-Reply-To: <519D3B61.5030700@redhat.com> References: <1368498506-25857-1-git-send-email-yinghai@kernel.org> <1368498506-25857-7-git-send-email-yinghai@kernel.org> <51925FB0.4080504@intel.com> <5192946F.1050700@intel.com> <5192AEF4.1070905@intel.com> <519BE778.9040800@redhat.com> <20130521214912.GA21713@redhat.com> <519BEEA4.2030804@gmail.com> <20130521221117.GB803@redhat.com> <519BF594.1020607@gmail.com> <519D3B61.5030700@redhat.com> Date: Thu, 23 May 2013 09:43:16 +0300 Message-ID: Subject: Re: [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's From: Or Gerlitz To: Don Dutile Cc: Alexander Duyck , "Michael S. Tsirkin" , Alexander Duyck , Yinghai Lu , Bjorn Helgaas , Gu Zheng , "linux-pci@vger.kernel.org" , Linux Kernel Mailing List , NetDev , Jack Morgenstein Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2805 Lines: 66 On Thu, May 23, 2013 at 12:40 AM, Don Dutile wrote: > On 05/22/2013 04:16 PM, Or Gerlitz wrote: [...] >> Hi Alex, all, so to clarify: >> >> 1. currently due to current firmware limitation we must call pci_enable_sriov before the >> PF ends its initialization sequence done in the PCI probe callback, hence >> >> 2. we can't move to the new sysfs API for enabling SRIOV >> >> 3. as of 3.9-rc1 we see these nested brobes, bisected that to be as of >> commit 90888ac01d059e38ffe77a2291d44cafa9016fb "driver core: fix >> possible missing of device probe". But we didn't reach into consensus >> with the author that this wasn't possible before the commit, nor this >> is something that needs to be avoided, see >> http://marc.info/?t=136249697200007&r=1&w=2 >> >> 4. I am not sure if/how we can modify the PF code to support the case >> where VFs are probed and start thier initialization sequence before >> the PF is done with its initialization >> >> 5. etc >> >> all in all, we will look into returning -EPROBE_DEFER from the VF >> when they identify the problematic situation -- so for how much time >> this is deferred? or if this isn't time based what the logical >> condition which once met the VF probe is attempted again? >> > ah, sounds device specific.... i.e., it goes back to PF probe.... > > So, I'm assuming some sort of init/info-xchg is done btwn VF & PF > and has to be done to some level before PF can continue it's pci-probe > operation. In that case, has the VF & PF done sufficient init/info-xchg > on 1st call, that the PF can continue, and then queue up a sriov-enable > at the end of PF probe ? not exactly (sorry if repeating myself) -- currently we must call pci_enable_sriov before the PF ends its initialization sequence done in its probe function. As soon as pci_enable_sriov is called, VFs are started to get probed and they detect that the PF has not done its initialization and hence the VF init/info-xchng can't be done. As to your question, we can't allow for VFs to start their probing before the PF did sriov-enable b/c of the that very same limitation. Summing up my recollection of the the 2-3 related thread that were around lately 1. when the VF see they can't probe, we will return -EPROBE_DEFER - this will fix the mlx4 specific issue 2. once the limitation is removed, mlx4 will implement the sysfs method so doing sriov-enable will be decoupled from PF probing 3. since nested probing is more general, still need to see if/which of Michael/Tejun/Alex patch needs to go in makes sense? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/