commit f8e750dd9ae52480f44f00b32d96af1fae0e3a09
author Andrew Geissler <geissonator@yahoo.com> Fri Jan 14 14:56:13 2022 -0600
committer Andrew Geissler <geissonator@yahoo.com> Tue Jan 18 21:56:02 2022 +0000
tree 41919f047dce9a7ed525c07af095d96800d061ef
parent 4619de5b778980685cf8b3abb27d8709dde086bd

openpower-pels: only fail on hw callouts

After further discussion with the IBM service and manufacturing team, it
was determined that firmware should only be automatically going to
Quiesce and preventing the system boot in QuiesceOnError mode when the
PEL has a hardware callout present (vs. any type of callout).

Tested:
- New unit test case
- Verified that an unrecoverable PEL with only a symbolic FRU and a
  maintenance procedure callout did not trigger the Quiesce logic
- Verified that a BMC log with a HW callout still triggers the Quiesce
  logic
- Verified a boot in simulation with Quiesce enabled

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8912d59fd69b699c7da5a44da887cce4e987f6d2

extensions/openpower-pels/pel.cpp

diff --git a/extensions/openpower-pels/pel.cpp b/extensions/openpower-pels/pel.cpp
index a6f0af3..de70b53 100644
--- a/extensions/openpower-pels/pel.cpp
+++ b/extensions/openpower-pels/pel.cpp
@@ -21,6 +21,7 @@
 #include "extended_user_data.hpp"
 #include "extended_user_header.hpp"
 #include "failing_mtms.hpp"
+#include "fru_identity.hpp"
 #include "json_utils.hpp"
 #include "log_id.hpp"
 #include "pel_rules.hpp"
@@ -506,7 +507,7 @@
     return callouts;
 }
 
-bool PEL::isCalloutPresent() const
+bool PEL::isHwCalloutPresent() const
 {
     auto pSRC = primarySRC();
     if (!pSRC)
@@ -522,7 +523,8 @@
             if (((*i).fruIdentity()))
             {
                 auto& fruId = (*i).fruIdentity();
-                if ((*fruId).failingComponentType() != 0)
+                if ((*fruId).failingComponentType() ==
+                    src::FRUIdentity::hardwareFRU)
                 {
                     calloutPresent = true;
                     break;