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<[email protected]>
>> ---
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]> 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<[email protected]>
>>> ---
>>> ? 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 [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
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 <[email protected]> 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 <[email protected]> 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<[email protected]>
>>>> ---
>>>> ? 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 [email protected]
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>
>>
>
I've been made aware of PPC + PCI-E embedded systems boards.
Adrian
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
On Sat, Jul 2, 2011 at 11:49 AM, Larry Finger <[email protected]> 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
>
>