diff mbox

[1/5] powerpc/eeh: Don't unfreeze PHB PE after reset

Message ID 1444187529-32217-1-git-send-email-gwshan@linux.vnet.ibm.com (mailing list archive)
State Superseded
Headers show

Commit Message

Gavin Shan Oct. 7, 2015, 3:12 a.m. UTC
On PowerNV platform, the PE is kept in frozen state until the PE
reset is completed to avoid recursive EEH error caused by MMIO
access during the period of EEH reset. The PE's frozen state is
cleared after BARs of PCI device included in the PE are restored
and enabled. However, we needn't clear the frozen state for PHB PE
explicitly at this point as there is no real PE for PHB PE. As the
PHB PE is always binding with PE#0, we actually clear PE#0, which
is wrong. It doesn't incur any problem though.

This checks if the PE is PHB PE and doesn't clear the frozen state
if it is.

Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/eeh_driver.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

Comments

Gavin Shan Oct. 7, 2015, 11:20 p.m. UTC | #1
On Wed, Oct 07, 2015 at 02:12:05PM +1100, Gavin Shan wrote:
>On PowerNV platform, the PE is kept in frozen state until the PE
>reset is completed to avoid recursive EEH error caused by MMIO
>access during the period of EEH reset. The PE's frozen state is
>cleared after BARs of PCI device included in the PE are restored
>and enabled. However, we needn't clear the frozen state for PHB PE
>explicitly at this point as there is no real PE for PHB PE. As the
>PHB PE is always binding with PE#0, we actually clear PE#0, which
>is wrong. It doesn't incur any problem though.
>
>This checks if the PE is PHB PE and doesn't clear the frozen state
>if it is.
>
>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>

Michael, please ignore this series for now. One or two patches are
still missed. Also, this series needs respin.

Thanks,
Gavin

>---
> arch/powerpc/kernel/eeh_driver.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
>diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
>index 89eb4bc..3a626ed 100644
>--- a/arch/powerpc/kernel/eeh_driver.c
>+++ b/arch/powerpc/kernel/eeh_driver.c
>@@ -587,10 +587,16 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus)
> 	eeh_ops->configure_bridge(pe);
> 	eeh_pe_restore_bars(pe);
>
>-	/* Clear frozen state */
>-	rc = eeh_clear_pe_frozen_state(pe, false);
>-	if (rc)
>-		return rc;
>+	/*
>+	 * If it's PHB PE, the frozen state on all available PEs should have
>+	 * been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
>+	 * child PEs because they might be in frozen state.
>+	 */
>+	if (!(pe->type & EEH_PE_PHB)) {
>+		rc = eeh_clear_pe_frozen_state(pe, false);
>+		if (rc)
>+			return rc;
>+	}
>
> 	/* Give the system 5 seconds to finish running the user-space
> 	 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
>-- 
>2.1.0
>
Gavin Shan Oct. 8, 2015, 4:05 a.m. UTC | #2
On Thu, Oct 08, 2015 at 10:20:14AM +1100, Gavin Shan wrote:
>On Wed, Oct 07, 2015 at 02:12:05PM +1100, Gavin Shan wrote:
>>On PowerNV platform, the PE is kept in frozen state until the PE
>>reset is completed to avoid recursive EEH error caused by MMIO
>>access during the period of EEH reset. The PE's frozen state is
>>cleared after BARs of PCI device included in the PE are restored
>>and enabled. However, we needn't clear the frozen state for PHB PE
>>explicitly at this point as there is no real PE for PHB PE. As the
>>PHB PE is always binding with PE#0, we actually clear PE#0, which
>>is wrong. It doesn't incur any problem though.
>>
>>This checks if the PE is PHB PE and doesn't clear the frozen state
>>if it is.
>>
>>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
>Michael, please ignore this series for now. One or two patches are
>still missed. Also, this series needs respin.
>

v2 was just sent out. Please look at v2 instead of this one.

Thanks,
Gavin

>>---
>> arch/powerpc/kernel/eeh_driver.c | 14 ++++++++++----
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
>>index 89eb4bc..3a626ed 100644
>>--- a/arch/powerpc/kernel/eeh_driver.c
>>+++ b/arch/powerpc/kernel/eeh_driver.c
>>@@ -587,10 +587,16 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus)
>> 	eeh_ops->configure_bridge(pe);
>> 	eeh_pe_restore_bars(pe);
>>
>>-	/* Clear frozen state */
>>-	rc = eeh_clear_pe_frozen_state(pe, false);
>>-	if (rc)
>>-		return rc;
>>+	/*
>>+	 * If it's PHB PE, the frozen state on all available PEs should have
>>+	 * been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
>>+	 * child PEs because they might be in frozen state.
>>+	 */
>>+	if (!(pe->type & EEH_PE_PHB)) {
>>+		rc = eeh_clear_pe_frozen_state(pe, false);
>>+		if (rc)
>>+			return rc;
>>+	}
>>
>> 	/* Give the system 5 seconds to finish running the user-space
>> 	 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
>>-- 
>>2.1.0
>>
diff mbox

Patch

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 89eb4bc..3a626ed 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -587,10 +587,16 @@  static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus)
 	eeh_ops->configure_bridge(pe);
 	eeh_pe_restore_bars(pe);
 
-	/* Clear frozen state */
-	rc = eeh_clear_pe_frozen_state(pe, false);
-	if (rc)
-		return rc;
+	/*
+	 * If it's PHB PE, the frozen state on all available PEs should have
+	 * been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
+	 * child PEs because they might be in frozen state.
+	 */
+	if (!(pe->type & EEH_PE_PHB)) {
+		rc = eeh_clear_pe_frozen_state(pe, false);
+		if (rc)
+			return rc;
+	}
 
 	/* Give the system 5 seconds to finish running the user-space
 	 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,