[Skiboot] [PATCH] phb3: Continue CAPP setup even if PHB is already in CAPP mode

[Daniel Axtens]

This fixes a critical bug in CAPI support.

CAPI requires that all faults are escalated into a fence, not a
freeze. This is done by setting bits in a number of MMIO
registers. phb3_set_capi_mode() calls phb3_init_capp_errors() to do
this. However, if the PHB is already in CAPP mode - for example in the
recovery case - phb3_set_capi_mode() will bail out early, and those
registers will not be set.

This is quite easy to verify. PCI config space access errors, for
example, normally cause a freeze. On a CAPI-mode PHB, they should
cause a fence. Say we have a CAPI card on PHB 0, and we inject a
PCI config space error:

echo 0x8000000000000000 > /sys/kernel/debug/powerpc/PCI0000/err_injct_inboundA;
lspci;

The first time we inject this, the PHB will fence and recover, but
won't reset the registers. Therefore, the second time we inject it,
we will incorrectly freeze, not fence.

Worse, the recovery for the resultant EEH freeze event interacts
poorly with the CAPP, triggering an EEH recovery of the PHB. The
combination of the two attempted recoveries will get the PHB into
an inoperable state.

It's quite likely that there other side effects of bailing out
early. For example, the timebase sync probably fails to recover.
Rather than auditing all the possibilities, I verified that
repeating the entire setup procedure still works when the PHB is
already in CAPP mode. It does work, so just do the entire setup
every time instead of bailing out early.

Signed-off-by: Daniel Axtens <dja at axtens.net>
---
 hw/phb3.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/phb3.c b/hw/phb3.c
index cdc20e8b0ed4..ba584c914f46 100644
--- a/hw/phb3.c
+++ b/hw/phb3.c
@@ -3268,7 +3268,6 @@ static int64_t phb3_set_capi_mode(struct phb *phb, uint64_t mode,
 	xscom_read(p->chip_id, 0x9013c03, &reg);
 	if (reg & PPC_BIT(0)) {
 		PHBDBG(p, "CAPP: Already in CAPP mode\n");
-		return OPAL_SUCCESS;
 	}
 
 	/* poll cqstat */
-- 
2.1.4