Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[James Smart]

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<jdmason@kudzu.us>
>> ---
>>    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
>

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[Jon Mason]

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 <james.smart@emulex.com> 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<jdmason@kudzu.us>
>>> ---
>>>   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
>>
>

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[Larry Finger]

On 07/01/2011 10:08 AM, Jon Mason wrote:
> 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).

Are there PPC systems that support PCI-E cards? I looked for one earlier and did 
not find any. In particular, I wanted a machine to test the Realtek drivers for 
correct big-endian operation. I settled on a Powerbook G4 so that I could test 
the USB drivers.

Larry

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[Jon Mason]

On Sat, Jul 2, 2011 at 11:49 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 07/01/2011 10:08 AM, Jon Mason wrote:
>>
>> 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).
>
> Are there PPC systems that support PCI-E cards? I looked for one earlier and
> did not find any. In particular, I wanted a machine to test the Realtek
> drivers for correct big-endian operation. I settled on a Powerbook G4 so
> that I could test the USB drivers.

High-end IBM PPC systems have PCI-E, but are most likely too expensive
for an individual user.  If you are okay with 32bit PPC, you can use
qemu to emulate PPC (see qemu-system-ppc).  I believe you can do USB
pass-though on the emulated system.

Thanks,
Jon

> Larry
>
>

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[Adrian Chadd]

I've been made aware of PPC + PCI-E embedded systems boards.



Adrian

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[Jon Mason]

Per Richard Lary's testing, this is not an issue with the latest kernel.
http://www.spinics.net/lists/linux-pci/msg11350.html

Thanks,
Jon

On Fri, Jul 1, 2011 at 10:08 AM, Jon Mason <jdmason@kudzu.us> wrote:
> 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 <james.smart@emulex.com> 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<jdmason@kudzu.us>
>>>> ---
>>>>   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
>>>
>>
>

Re: Warning: iwlegacy/iwlwifi/rtlwifi : removal of PCI_CAP_ID_EXP

[James Smart]

FYI:   after discussion of this error on linux-pci and linuxppc-dev, the error 
was corrected in a patch checked into 2.6.33-rc6/3.0-rc6 
(http://marc.info/?l=linux-pci&m=130992047232053&w=2)

-- james s




On 7/1/2011 10: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<jdmason@kudzu.us>
>>> ---
>>>     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
>>
>