Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:56824 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720Ab1GAPIM convert rfc822-to-8bit (ORCPT ); Fri, 1 Jul 2011 11:08:12 -0400 Received: by eyx24 with SMTP id 24so1149560eyx.19 for ; Fri, 01 Jul 2011 08:08:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <294849c5-16f3-491b-98c2-2a96275e8378@exht1.ad.emulex.com> References: <1309196346-15749-1-git-send-email-jdmason@kudzu.us> <4E0CDF8B.3020505@emulex.com> <294849c5-16f3-491b-98c2-2a96275e8378@exht1.ad.emulex.com> Date: Fri, 1 Jul 2011 10:08:10 -0500 Message-ID: (sfid-20110701_170815_002429_F64214F2) Subject: Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP From: Jon Mason To: James Smart Cc: "linux-wireless@vger.kernel.org" , Richard Lary , wey-yi.w.guy@intel.com, Stanislaw Gruszka , Larry.Finger@lwfinger.net, chaoming_li@realsil.com.cn Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: pci_is_pcie checks for a PCI-E capability offset that was determined by calling pci_find_capability during the PCI bus walking. Based on your description above this should be functionally equivalent. If this is not safe, then the PCI bus walking code is most likely busted on EEH enabled PPC systems (and that is a BIG problem). Thanks, Jon On Fri, Jul 1, 2011 at 9:49 AM, James Smart wrote: > All, > > I wanted to communicate a potential warning to those drivers that had a > patch submitted to replace config space searches of PCI_CAP_ID_EXP with > shorthand options such as is_pcie and pci_is_pcie(). > > Testing with the lpfc driver and AER/EEH identified cases where the > short-hand search options would fail on PPC platforms. ?The only successful > option in all cases was the explicit search via PCI_CAP_ID_EXP. ? Therefore, > I recommend that this change not be accepted until the platform level issue > can be identified and corrected. > > -- james s > > > > On 6/30/2011 4:41 PM, James Smart wrote: >> >> Jon, >> >> I must NACK this patch to the lpfc driver and recommend that all other >> patches >> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with >> "pci_is_pcie(pdev)" are NACK'd as well. >> >> The reason is due to an issue on PPC platforms whereby use of >> "pdev->is_pcie" >> and pci_is_pcie() will erroneously fail under some conditions, but >> explicit >> search for the capability struct via pci_find_capability() is always >> successful. ? I expect this to be due a shadowing of pci config space in >> the >> hal/platform that isn't sufficiently built up. ?We detected this issue >> while >> testing AER/EEH, and are functional only if the pci_find_capability() >> option >> is used. >> >> -- james s >> >> >> >> On 6/27/2011 1:39 PM, Jon Mason wrote: >>> >>> The PCIE capability offset is saved during PCI bus walking. ?It will >>> remove an unnecessary search in the PCI configuration space if this >>> value is referenced instead of reacquiring it. ?Also, pci_is_pcie is a >>> better way of determining if the device is PCIE or not (as it uses the >>> same saved PCIE capability offset). >>> >>> Signed-off-by: Jon Mason >>> --- >>> ? drivers/scsi/lpfc/lpfc_init.c | ? ?2 +- >>> ? 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/scsi/lpfc/lpfc_init.c >>> b/drivers/scsi/lpfc/lpfc_init.c >>> index 148b98d..9000ad0 100644 >>> --- a/drivers/scsi/lpfc/lpfc_init.c >>> +++ b/drivers/scsi/lpfc/lpfc_init.c >>> @@ -3970,7 +3970,7 @@ lpfc_enable_pci_dev(struct lpfc_hba *phba) >>> ? ? ? ?pci_save_state(pdev); >>> >>> ? ? ? ?/* PCIe EEH recovery on powerpc platforms needs fundamental reset >>> */ >>> - ? ? ? if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) >>> + ? ? ? if (pci_is_pcie(pdev)) >>> ? ? ? ? ? ? ? ?pdev->needs_freset = 1; >>> >>> ? ? ? ?return 0; >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at ?http://vger.kernel.org/majordomo-info.html >> >