[PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[Jon Mason]

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;
-- 
1.7.5.4

Re: [PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[James Smart]

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;

Re: [PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[James Smart]

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;

Warning: qla4xxx/qla2xxx/lpfc : 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;

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
>

Warning: mthca/qib : 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-zqedIHPRSYI@public.gmane.org>
>> ---
>>    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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Warning: mthca/qib : removal of PCI_CAP_ID_EXP

[Mike Marciniszyn]

The patch was ok here, but we only support x86_64.

Mike

> -----Original Message-----
> From: James Smart [mailto:james.smart-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org]
> Sent: Friday, July 01, 2011 10:49 AM
> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: James Smart; Jon Mason; Richard Lary; Mike Marciniszyn;
> eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org; jlburr-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org
> Subject: Warning: mthca/qib : removal of PCI_CAP_ID_EXP
>
> 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-zqedIHPRSYI@public.gmane.org>
> >> ---
> >>    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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >


This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[Jon Mason]

On Thu, Jun 30, 2011 at 3:41 PM, James Smart <james.smart@emulex.com> 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.

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

>
> -- 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: mthca/qib : 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
the description below 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).  I'll e-mail
the PPC mailing list to verify the issue.

Thanks,
Jon

On Fri, Jul 1, 2011 at 10:01 AM, Mike Marciniszyn
<mike.marciniszyn-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org> wrote:
> The patch was ok here, but we only support x86_64.
>
> Mike
>
>> -----Original Message-----
>> From: James Smart [mailto:james.smart-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org]
>> Sent: Friday, July 01, 2011 10:49 AM
>> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: James Smart; Jon Mason; Richard Lary; Mike Marciniszyn;
>> eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org; jlburr-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org
>> Subject: Warning: mthca/qib : removal of PCI_CAP_ID_EXP
>>
>> 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-zqedIHPRSYI@public.gmane.org>
>> >> ---
>> >>    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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>
>
> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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: qla4xxx/qla2xxx/lpfc : 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
the description below 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).  I'll e-mail
the PPC mailing list to verify the issue.

Thanks,
Jon

On Fri, Jul 1, 2011 at 9:48 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: myri10ge/sky2/vxge/r8169/niu/bnx2/bnx2x/igb/e100e/cxgb3/mlx4/tg3/vxge : removal of PCI_CAP_ID_EXP

[Jon Mason]

On Fri, Jul 1, 2011 at 10:28 AM, Jon Mason <jdmason@kudzu.us> wrote:
> 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.
>
> 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).
>
> I have e-mailed the PPC and PCI mailing lists to verify the issue.

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


>
> Thanks,
> Jon
>
>
>>
>> -- 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
>>>
>>
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

Re: Warning: qla4xxx/qla2xxx/lpfc : 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:10 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
> the description below 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).  I'll e-mail
> the PPC mailing list to verify the issue.
>
> Thanks,
> Jon
>
> On Fri, Jul 1, 2011 at 9:48 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

[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: mthca/qib : 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:07 AM, Jon Mason <jdmason-zqedIHPRSYI@public.gmane.org> 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
> the description below 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).  I'll e-mail
> the PPC mailing list to verify the issue.
>
> Thanks,
> Jon
>
> On Fri, Jul 1, 2011 at 10:01 AM, Mike Marciniszyn
> <mike.marciniszyn-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org> wrote:
>> The patch was ok here, but we only support x86_64.
>>
>> Mike
>>
>>> -----Original Message-----
>>> From: James Smart [mailto:james.smart-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org]
>>> Sent: Friday, July 01, 2011 10:49 AM
>>> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: James Smart; Jon Mason; Richard Lary; Mike Marciniszyn;
>>> eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org; jlburr-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org
>>> Subject: Warning: mthca/qib : removal of PCI_CAP_ID_EXP
>>>
>>> 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-zqedIHPRSYI@public.gmane.org>
>>> >> ---
>>> >>    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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> >
>>
>>
>> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Warning: qla4xxx/qla2xxx/lpfc : 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:48 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;
>
>

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
>>
>

Re: Warning: mthca/qib : 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-zqedIHPRSYI@public.gmane.org>
>>> ---
>>>     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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP

[James Smart]

Acked-by: James Smart <james.smart@emulex.com>


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;