diff mbox series

[v3,8/8] capp/phb4: Prevent HMI from getting triggered when disabling CAPP

Message ID 20190108095902.24718-9-vaibhav@linux.ibm.com
State Superseded
Headers show
Series Enable fast-reboot support for CAPI-2 | expand

Checks

Context Check Description
snowpatch_ozlabs/apply_patch success master/apply_patch Successfully applied
snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot success Test snowpatch/job/snowpatch-skiboot on branch master

Commit Message

Vaibhav Jain Jan. 8, 2019, 9:59 a.m. UTC 
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.

Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Change-log

v3:	Fetch the pointer to 'struct capp' from struct phb4 instead of
	struct phb.

v2:	Use the member 'struct capp->capp_xscom_offset' to find the
	xscom register offset instead of 'PHB4_CAPP_REG_OFFSET'.
---
 hw/phb4.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Christophe Lombard Jan. 9, 2019, 1:04 p.m. UTC | #1 
Le 08/01/2019 à 10:59, Vaibhav Jain a écrit :
> 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.
> 
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Change-log
> 
> v3:	Fetch the pointer to 'struct capp' from struct phb4 instead of
> 	struct phb.
> 
> v2:	Use the member 'struct capp->capp_xscom_offset' to find the
> 	xscom register offset instead of 'PHB4_CAPP_REG_OFFSET'.
> ---

Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Frederic Barrat Jan. 10, 2019, 1:49 p.m. UTC | #2 
Le 08/01/2019 à 10:59, Vaibhav Jain a écrit :
> 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.
> 
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---

Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>

> Change-log
> 
> v3:	Fetch the pointer to 'struct capp' from struct phb4 instead of
> 	struct phb.
> 
> v2:	Use the member 'struct capp->capp_xscom_offset' to find the
> 	xscom register offset instead of 'PHB4_CAPP_REG_OFFSET'.
> ---
>   hw/phb4.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/hw/phb4.c b/hw/phb4.c
> index 6b330793..73b2c40d 100644
> --- a/hw/phb4.c
> +++ b/hw/phb4.c
> @@ -3284,6 +3284,7 @@ static void disable_capi_mode(struct phb4 *p)
>   static int64_t phb4_creset(struct pci_slot *slot)
>   {
>   	struct phb4 *p = phb_to_phb4(slot->phb);
> +	struct capp *capp = p->capp;
>   	uint64_t pbcq_status, reg;
>   
>   	/* Don't even try fixing a broken PHB */
> @@ -3299,6 +3300,16 @@ 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 &&
> +		    capp && capp->phb == slot->phb) {
> +			/* Since no HMI, So set the recovery flag manually. */
> +			p->flags |= PHB4_CAPP_RECOVERY;
> +			xscom_write_mask(p->chip_id, capp->capp_xscom_offset +
> +					 CAPP_FIR_MASK,
> +					 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,
>
diff mbox series

Patch

diff --git a/hw/phb4.c b/hw/phb4.c
index 6b330793..73b2c40d 100644
--- a/hw/phb4.c
+++ b/hw/phb4.c
@@ -3284,6 +3284,7 @@  static void disable_capi_mode(struct phb4 *p)
 static int64_t phb4_creset(struct pci_slot *slot)
 {
 	struct phb4 *p = phb_to_phb4(slot->phb);
+	struct capp *capp = p->capp;
 	uint64_t pbcq_status, reg;
 
 	/* Don't even try fixing a broken PHB */
@@ -3299,6 +3300,16 @@  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 &&
+		    capp && capp->phb == slot->phb) {
+			/* Since no HMI, So set the recovery flag manually. */
+			p->flags |= PHB4_CAPP_RECOVERY;
+			xscom_write_mask(p->chip_id, capp->capp_xscom_offset +
+					 CAPP_FIR_MASK,
+					 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,