clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I21d2ca8065f24fd73509229c517f5caf48934b60
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

PEL: Support for CheckstopFlag msg reg field

Similiar to the DeconfigFlag field that was recently added, this one
indicates the PEL is for a hardware checkstop and results in a bit in
SRC hex word 5

PEL: Support for CheckstopFlag msg reg field

Similiar to the DeconfigFlag field that was recently added, this one
indicates the PEL is for a hardware checkstop and results in a bit in
SRC hex word 5 being set.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib05de7471ad3e32f48e7f20a5c611abc119fe82a

show more ...

PEL: Support new DeconfigFlag msg reg field

Add a new field to the PEL message registry to indicate that some
hardware associated with a callout was deconfigured.

"DeconfigFlag": true

This results

PEL: Support new DeconfigFlag msg reg field

Add a new field to the PEL message registry to indicate that some
hardware associated with a callout was deconfigured.

"DeconfigFlag": true

This results in bit 6 in the SRC's hex word 5 being set. It is looked
at by the code that creates the periodic PELs when there is a system
running with deconfigured hardware.

Note: For something to be considered deconfigured, it doesn't
necessarily mean that firmware chose to not configure it. It could also
mean that it is broken or missing, at least in the case of power
supplies or fans.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3e657cb52416fc50000e299bf2d583db7b67caf8

show more ...

PEL: Read the journal info from the registry

Add support to the Registry class to read the JournalCapture information
out of the registry entry for an error if it is there. This will then
be used b

PEL: Read the journal info from the registry

Add support to the Registry class to read the JournalCapture information
out of the registry entry for an error if it is there. This will then
be used by the PEL class when creating a PEL.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I529e4fb352c6eb33ad73b2a04ac4467710865139

show more ...

clang-format: update with latest

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I329396457b83bb2eb8740629b4ac1fbe9106bced

Revert "peltool: Add Notes from message registry file"

There's some worry that customers may see the Notes text and it isn't at
the level they would understand. Will err on the side of caution and

Revert "peltool: Add Notes from message registry file"

There's some worry that customers may see the Notes text and it isn't at
the level they would understand. Will err on the side of caution and
remove it.

This reverts commit 5a3d8f4b8c87d7cbe3762d40a289ad07467b9316.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I87bfea66f6d6f2cf6fc522db0e114fb17efd6aa3

show more ...

peltool: Add Notes from message registry file

Add the Notes section found in the message registry file to the json
output (if it's present and not empty).

Example:

"Error Details": {
"Message"

peltool: Add Notes from message registry file

Add the Notes section found in the message registry file to the json
output (if it's present and not empty).

Example:

"Error Details": {
"Message": "Unknown (Original event not in message registry)",
"Notes": [
"This is used when the actual error name isn't",
"found in the registry."
]
}

Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: I69773547c06f6361055c2f0decd07967d0012946

show more ...

PEL: Remove PowerFault from message entries, registries, and code

The PowerFault flag is deprecated and should be removed in both the
registry and code references. Its functionality is superseded by

PEL: Remove PowerFault from message entries, registries, and code

The PowerFault flag is deprecated and should be removed in both the
registry and code references. Its functionality is superseded by the
critical_system severity level.

Signed-off-by: Mike Capps <mikepcapps@gmail.com>
Change-Id: I1bc1898d9589e0678b5a37b87289c6588859f2ee

show more ...

PEL: Support 'PossibleSubsystems' in msg registry

Add a 'PossibleSubsystems' field to the message registry schema where
someone can list which subsystems they might pass into the PEL_SUBSYSTEM
Addit

PEL: Support 'PossibleSubsystems' in msg registry

Add a 'PossibleSubsystems' field to the message registry schema where
someone can list which subsystems they might pass into the PEL_SUBSYSTEM
AdditionalData property field when creating a PEL.

The PossibleSubsystems value will be used by a off-BMC script that
generates field documentation for SRCs, so it knows what all SRC ASCII
string values are possible for that entry since the subsystem is part of
them. For example, if that field was ['processor', 'memory'], then that
means the possible SRCs are BD10AAAA and BD20AAAA for reason code
'AAAA'.

The Subsystem and PossibleSubsystems fields are mutually exclusive in
the message registry, so code changes had to be made to support the
subsystem field now being optional.

There is now a chance that even though the subsystem is supposed to be
passed in using PEL_SUBSYSTEM, it isn't. In that case, the 'Other'
subsystem will be used, since it seems fairly generic.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic8087fc46b2a192459b7287186f8972610e84730

show more ...

peltool: Print the Words6To9 'Description' field

Include the 'Description' field from the Words6To9 registry entry when printing
SRC error details.

Changed from this:

"Error Details": {
"Messa

peltool: Print the Words6To9 'Description' field

Include the 'Description' field from the Words6To9 registry entry when printing
SRC error details.

Changed from this:

"Error Details": {
"Message": "There was a failure when reading a sensor device",
"CALLOUT_ERRNO": "0x5"
}

to this:

"Error Details": {
"Message": "There was a failure when reading a sensor device",
"CALLOUT_ERRNO": [
"0x5",
"errno of the failure"
]
}

Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: Icc107b0516062eb891f14f3ff3f3cffd316c6d77

show more ...

PEL: Dynamic location code for registry callout

The PEL callout type 'symbolic FRU with trusted location code'
previously had both the symoblic FRU name and the location code
specified in the PEL me

PEL: Dynamic location code for registry callout

The PEL callout type 'symbolic FRU with trusted location code'
previously had both the symoblic FRU name and the location code
specified in the PEL message registry. However, there are cases where
the location code is not known until runtime so it cannot be specified
in the registry.

To solve this, create a boolean 'UseInventoryLocCode` key that can be
used in the registry callout entry to specify that the location code to
use for the callout should come from the FRU passed in using the
CALLOUT_INVENTORY_PATH entry in the AdditionalData event log property.
In this case, that FRU will not be added as a normal FRU callout as it
would normally be otherwise. The registry that uses this must be the
first one in the callout list.

For example:
{
"Priority": "high",
"SymbolicFRUTrusted": "air_mover",
"UseInventoryLocCode": true
},

along with CALLOUT_INVENTORY_PATH=<processor 0 path>

would result in a symbolic FRU callout with the trusted location code
being the processor 0 location code.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iaf65c523803662313f2ad5e197262b9f4e722332

show more ...

PEL: Read the compatible system names property

The chassis object in the inventory has (or rather at the time of this
writing: will have) a Names property that contains a list of the
compatible syst

PEL: Read the compatible system names property

The chassis object in the inventory has (or rather at the time of this
writing: will have) a Names property that contains a list of the
compatible system types for the current system. An example is:
["company-systemA-4G", "company-systemA", "company"].

Add this to the DataInterface class, and remove the previous
'getSystemType' API that was there but was still stubbed out.

Also change all the calls from getSystemType() to the new call
getSystemNames(), and check against all entries in that array to see if
the desired name applies to the current system.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I86aa0c15c564153fea612f407c161dfe9041fce6

show more ...

PEL: Msg registry sev now based on sys type

The PEL severity field in the UserHeader section can now be defined in
the message registry to be based on system type.

When the UserHeader object is bei

PEL: Msg registry sev now based on sys type

The PEL severity field in the UserHeader section can now be defined in
the message registry to be based on system type.

When the UserHeader object is being created from the message registry,
it will now query the system type and use that to find the correct
severity value.

The Registry class was updated to handle the new JSON format, which
is an array of system type/severity value objects.

The original severity format of a simple string is still valid.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0fe0ada7193c57adc42e82afdc30e687eea63eb9

show more ...

PEL: Find message registry callouts to use

Add Registry::getCallouts() to find, based on the system type and
AdditionalData property, the callouts that apply for the callout JSON
passed in. This wi

PEL: Find message registry callouts to use

Add Registry::getCallouts() to find, based on the system type and
AdditionalData property, the callouts that apply for the callout JSON
passed in. This will be used to choose the callouts to add to a PEL
based on the system and current failure informaton.

These files describe the actual JSON format:
* extensions/openpower-pels/registry/README.md
* extensions/openpower-pels/registry/schema/schema.json

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5901e459981b10f6c338d3ef827d9128338dca50

show more ...

PEL: Save registry callout JSON for later

When finding an entry in the PEL message registry, save the callout JSON
section, if there is one, in the returned Entry object. This also adds
a construct

PEL: Save registry callout JSON for later

When finding an entry in the PEL message registry, save the callout JSON
section, if there is one, in the returned Entry object. This also adds
a constructor argument that lets one choose to do this or not, because
it isn't needed when used in peltool.

That JSON will be parsed at a later point.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I757509ced952ce8f07f12c28ab203e5eedf4fd32

show more ...

PEL: Print SRC section into JSON

For BMC created errors, look up the reason code in
the message registry for error description and also
meaning of data stored in hexwords 6-9 (if any).

Added regist

PEL: Print SRC section into JSON

For BMC created errors, look up the reason code in
the message registry for error description and also
meaning of data stored in hexwords 6-9 (if any).

Added registry message field in peltool list output.

"Primary SRC": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "0x1000",
"SRC Version": "0x02",
"SRC Format": "0x55",
"Power Control Net Fault": "False",
"Error Details": {
"Message": "PS 0x64 had a PGOOD Fault",
"PS_NUM": "0x64"
},
"Valid Word Count": "0x09",
"Reference Code": "BD8D1001",
"Hex Word 2": "00000055",
"Hex Word 3": "00000010",
"Hex Word 4": "00000000",
"Hex Word 5": "00000000",
"Hex Word 6": "00000064",
"Hex Word 7": "00000000",
"Hex Word 8": "00000000",
"Hex Word 9": "00000000"
}

"Primary SRC": {
"Section Version": "1",
"Sub-section type": "0",
"Created by": "0x4552",
"SRC Version": "0x02",
"SRC Format": "0x2008000",
"Power Control Net Fault": "False",
"Valid Word Count": "0x04",
"Reference Code": "B2001020",
"Hex Word 2": "02008000",
"Hex Word 3": "00000000",
"Hex Word 4": "00000012",
"Callout Section": {
"Callout Count": "1",
"Callouts": [{
"FRU Type": "Symbolic FRU",
"Priority": "Medium Priority",
"Part Number": "NEXTLVL"
}]
}
}

Testing: Manually run peltool and verified out. All unit tests passed.
Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: I124627ba785413ebda02305b7d9f95431922e714

show more ...

PEL: Make action flags optional in the registry

A future commit will fill in the field if it isn't
present.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67371433162ce2198a362796d274

PEL: Make action flags optional in the registry

A future commit will fill in the field if it isn't
present.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I67371433162ce2198a362796d274695a1bd6a6dc

show more ...

PEL: Read SRC fields out of the registry

The SRC (System Reference code) is a section in the PEL and several of
its fields are sourced from the message registry.

Signed-off-by: Matt Spinler <spinle

PEL: Read SRC fields out of the registry

The SRC (System Reference code) is a section in the PEL and several of
its fields are sourced from the message registry.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I4ca7d18a8225f2667b762015c6fd74bfb59d70ff

show more ...

PEL: Find an entry in the message registry JSON

The message registry is a JSON file that holds data required to create a
PEL out of an OpenBMC event log. It includes fields like 'subsystem',
'event

PEL: Find an entry in the message registry JSON

The message registry is a JSON file that holds data required to create a
PEL out of an OpenBMC event log. It includes fields like 'subsystem',
'event type', 'action flags', 'SRC reason code', etc.

Many fields in the message registry are optional, and a very minimal
entry make look like:

{
"Name": "xyz.openbmc_project.Power.Error.Fault",
"Subsystem": "power_supply",
"ActionFlags": ["service_action", "report"],

"SRC":
{
"ReasonCode": "0x2030"
}
}

This commit adds support to look up a message registry entry based on an
OpenBMC event log's 'Message' property (i.e.
xyz.openbmc_project.Power.Error.Fault) and then fill in a structure with
the fields found. Future commits will fill in the SRC related fields,
as well as actually create the PEL.

The message registry file can be found on the BMC at:
/usr/share/phosphor-logging/pels/message_registry.json.

For testing, users can put their own message_registry.json in
/etc/phosphor-logging, and that will take precedence.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie4195ed7e58ab6a231271f6b295e63b1d0a4cd78

show more ...