[Skiboot] [PATCH 7/7] capp/phb4: Prevent HMI from getting triggered when disabling CAPP

[Vaibhav Jain]

While disabling CAPP an HMI gets triggered as soon as ETU is put in
reset mode. This is caused as before we can disabled CAPP, it detects
PHB link going down and triggers an HMI requesting Opal to perform
CAPP recovery. This has an un-intended side effect of spamming the
Opal logs with malfunction alert messages and may also confuse the
user.

To prevent this we mask the CAPP FIR error 'PHB Link Down' Bit(31)
when we are disabling CAPP just before we put ETU in reset in
phb4_creset(). Also now since bringing down the PHB link now wont
trigger an HMI and CAPP recovery, hence we manually set the
PHB4_CAPP_RECOVERY flag on the phb to force recovery during creset.

Signed-off-by: Vaibhav Jain <vaibhav at linux.ibm.com>
---
 hw/phb4.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/hw/phb4.c b/hw/phb4.c
index 2e0ed191..821cf94f 100644
--- a/hw/phb4.c
+++ b/hw/phb4.c
@@ -3265,6 +3265,15 @@ static int64_t phb4_creset(struct pci_slot *slot)
 		/* Clear error inject register, preventing recursive errors */
 		xscom_write(p->chip_id, p->pe_xscom + 0x2, 0x0);
 
+		/* Prevent HMI when PHB gets fenced as we are disabling CAPP */
+		if (p->flags & PHB4_CAPP_DISABLE) {
+			/* Since no HMI, So set the recovery flag manually. */
+			p->flags |= PHB4_CAPP_RECOVERY;
+			xscom_write_mask(p->chip_id, CAPP_FIR_MASK +
+					 PHB4_CAPP_REG_OFFSET(p),
+					 PPC_BIT(31), PPC_BIT(31));
+		}
+
 		/* Force fence on the PHB to work around a non-existent PE */
 		if (!phb4_fenced(p))
 			xscom_write(p->chip_id, p->pe_stk_xscom + 0x2,
-- 
2.17.1