History log of /openbmc/phosphor-logging/extensions/openpower-pels/data_interface.hpp (Results 1 – 25 of 50)
Revision Date Author Comments
# 25291157 01-Feb-2025 Patrick Williams <patrick@stwcx.xyz>

clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

Change-Id: Iac96affe709a51dd865117d006cb033cf5c624b1
Signed-off-by: Patrick Williams <p

clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

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

show more ...


# ff35be3e 15-Oct-2024 Deepa Karthikeyan <deepakala.karthikeyan@ibm.com>

openpower-pels: Create guard using libguard

Replace CreateWithEntityPath D-Bus method with guard library calls for
creating guard entries, as CreateWithEntityPath is not an approved dbus
method.

Te

openpower-pels: Create guard using libguard

Replace CreateWithEntityPath D-Bus method with guard library calls for
creating guard entries, as CreateWithEntityPath is not an approved dbus
method.

Tested and the guard record is created with the corresponding PEL id

```
before injecting the error
root@p10bmc:~# guard -l
No unresolved records to display

After injecting error, the guard is created using the PEL ID
root@p10bmc:~# guard -l
ID | ERROR | Type | Path
0x00000001 | 0x5000592b | unrecoverable | physical:sys-0/node-0/proc-0/eq-1/fc-0/core-0
root@p10bmc:~# peltool -l
{
"0x5000592B": {
"SRC": "BD13E510",
"Message": "Error Signature: 0x20DA0020 0x00000001 0x4D740407",
"PLID": "0x5000592B",
"CreatorID": "BMC",
"Subsystem": "Processor Unit (CPU)",
"Commit Time": "10/17/2024 09:54:22",
"Sev": "Unrecoverable Error",
"CompID": "bmc hw diags"
}
}
```

Change-Id: I7531bce403206beaa119aea0a621e6b47d28ffd0
Signed-off-by: deepakala-k <deepakala.karthikeyan@ibm.com>

show more ...


# 083c7049 14-Oct-2024 Matt Spinler <spinler@us.ibm.com>

PEL: Remove dump status bits from PELs

Stop filling in the bits in the PEL that say there are un-offloaded
dumps. These require calls to the dump daemon that can be slow and even
time out if the du

PEL: Remove dump status bits from PELs

Stop filling in the bits in the PEL that say there are un-offloaded
dumps. These require calls to the dump daemon that can be slow and even
time out if the dump daemon is busy.

These aren't parsed out in the peltool output anyway, and there are
other ways to determine if there are dumps - someone could just look at
the dump D-Bus directly.

This isn't a direct revert of the commit that introduced it because of
all the merge conflicts trying to do a revert entailed.

Tested:
Can still create PELs.

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

show more ...


# d763db35 03-Sep-2024 harsh-agarwal1 <harsh.agarwal@ibm.com>

PEL: Prevent deletion if it's associated with HWIsolation

- This ensures that PELs linked to HWIsolation records are protected
from accidental deletion.
- Shows error message of "Call failed: The se

PEL: Prevent deletion if it's associated with HWIsolation

- This ensures that PELs linked to HWIsolation records are protected
from accidental deletion.
- Shows error message of "Call failed: The service is temporarily
unavailable.", when attempting to delete such a PEL individually.
- If trying to Delete all, will skip such PELs without showing any
message.

Tested:
Sample output:
```bash
$ busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/
logging xyz.openbmc_project.Collection.DeleteAll DeleteAll

$ busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/
logging/entry/2 xyz.openbmc_project.Object.Delete Delete
Call failed: The service is temporarily unavailable.

```
Change-Id: I2d28de91bbb0fbc2a991e3d5e5631814d41fe044
Signed-off-by: Harsh Agarwal <Harsh.Agarwal@ibm.com>

show more ...


# 0b758fb0 06-Sep-2024 Arya K Padman <aryakpadman@gmail.com>

PEL: DRAM: Fixing the missed comma in lg2 trace

Root Cause: In commit afba316, two traces in the lg2 logging missed a
comma, leading to a compilation error.

Solution: The lg2 traces have been corre

PEL: DRAM: Fixing the missed comma in lg2 trace

Root Cause: In commit afba316, two traces in the lg2 logging missed a
comma, leading to a compilation error.

Solution: The lg2 traces have been corrected by adding the missing
comma. Additionally, the systemd signal subscription and
unsubscription logic has been moved outside of the PEL_ENABLE_PHAL
flag, as it is not dependent on PHAL.

Change-Id: Ib8b17af95be356c6649c7804e4e46704498f3f3d
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...


# ced8ed77 02-Sep-2024 Arya K Padman <aryakpadman@gmail.com>

PEL: DRAM: Remove the Debug Section for PHAL Errors

In commit 8ae618, when the system attempts to call out FRUs, PEL is
designed to include DRAM manufacturer details if the FRU being
identified is a

PEL: DRAM: Remove the Debug Section for PHAL Errors

In commit 8ae618, when the system attempts to call out FRUs, PEL is
designed to include DRAM manufacturer details if the FRU being
identified is a DIMM. The FRU type is determined using the PHAL API
"getFRUType", and if this fails, the corresponding PHAL error message
is added to the PEL debug section to aid in debugging.

However, there are cases where some FRUs, such as Planar, Fan, Power
Supply, etc., are not represented in the PHAL device tree. The PHAL
device tree primarily serves CEC (Central Electronic Complex)
hardware, which is crucial for booting the host processor. For these
unmodeled FRUs, PHAL returns 'Location code not found,' which is then
recorded in the PEL debug section.

Since these failures are expected, the PHAL error messages should be
removed from the PEL debug section to prevent confusion, as errors for
non-modeled FRUs in the PHAL device tree are expected.

The downside is that this removal could reduce debuggability for real
errors, such as a valid location code not being found or the need for
updates to the PHAL predefined FRU list. The expectation is that the
PHAL API "getFRUType" should have sufficient trace information for
debugging such issues. The phosphor-logging is not designed to capture
traces for PHAL error scenarios because of the limitations with the
PHAL device tree mentioned above.

Signed-off-by: Arya K Padman <aryakpadman@gmail.com>
Change-Id: I9a0011252667173f9e5f6aecbab2e7cd76174afa

show more ...


# afba316c 30-Aug-2024 Arya K Padman <aryakpadman@gmail.com>

PEL: Init PHAL once the PNOR partition symlink is setup

As part of commit 8ae618, PHAL initialization was moved to pelstartup
to avoid multiple initialization calls. However, this change caused an
i

PEL: Init PHAL once the PNOR partition symlink is setup

As part of commit 8ae618, PHAL initialization was moved to pelstartup
to avoid multiple initialization calls. However, this change caused an
issue where the phosphor-logging service was pointing to the default
PHAL device tree, which lacks necessary attributes.

Root cause:
At the time the phosphor-logging service starts, the PNOR partition
symlink (which should point to the correct PHAL device tree) is not
yet created. This absence causes phosphor-logging service map to the
default device tree. The underlying issue is that the
openpower-update-bios-attr-table service, responsible for creating all
symlinks, starts after phosphor-logging due to a dependency on
phosphor-logging from a dependent service of
openpower-update-bios-attr-table service..

Proposed solution:
The phosphor-logging service will now subscribe to the 'JobRemoved'
DBUS signal from systemd service after the successful execution of
openpower--update-bios-attr-table service. Upon receiving this signal,
phosphor-logging will init PHAL, ensuring that PHAL initialization
occurs only after all symlinks have been set up.

Tested :

Before fix, journal traces has the error from dtb file open as below:
```
p10b systemd[1]: Starting OpenPower Software Update Manager...
p10b systemd[1]: Starting Phosphor Log Manager...
p10b systemd[1]: Started OpenPower Software Update Manager.
p10b systemd[1]: Started Phosphor Log Manager.
p10b phosphor-log-manager[409]: Unable to open dtb file
'/var/lib/phosphor-software-manager/pnor/rw/DEVTREE'
p10b systemd[1]: Starting Update BIOS attr table with host
firmware well-known names...
```

After fix, system is starting able to start the services without dtb
file open error.
```
p10b systemd[1]: Starting Phosphor Log Manager...
p10b phosphor-log-manager[408]: The send PELs to host setting changed
to False
p10b systemd[1]: Started Phosphor Log Manager.
p10b systemd[1]: Starting Set POWER host firmware well-known names...
p10b systemd[1]: openpower-process-host-firmware.service: Deactivated
successfully.
p10b systemd[1]: Finished Set POWER host firmware well-known names.
p10b systemd[1]: Starting Update BIOS attr table with host firmware
well-known names...
p10b systemd[1]: openpower-update-bios-attr-table.service: Deactivated
successfully.
p10b systemd[1]: Finished Update BIOS attr table with host firmware
well-known names.
```

Change-Id: I96b06581ebbc9afd6f8020f3540ed71bf06e5c19
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...


# d8ae618a 19-Jul-2024 Arya K Padman <aryakpadman@gmail.com>

PEL: Add the DRAM manufacturer info of DIMM callout in UD section

Add the called out DIMMs DRAM manufacturer info to the user data
section of the PEL to assist the service engineers in identifying t

PEL: Add the DRAM manufacturer info of DIMM callout in UD section

Add the called out DIMMs DRAM manufacturer info to the user data
section of the PEL to assist the service engineers in identifying the
manufacturer of the faulty DRAMs packaged within the DIMM module
directly from the logs, aiding in quick resolution.

The changes also moves the pdbg target and libekb initialization to
the PEL startup which avoids the need of multiple initialization as
the existing design.

When a PEL calls out a DIMM FRU, the DRAM manufacturer ID and the
expanded location code of those DIMMs are added to the SysInfo user
data section of the generated PEL in JSON format under the key 'DIMMs
Additional Info'.

In case of any errors occur during the collection or processing of
the manufacturer data, the error messages will be logged in the 'PEL
Internal Debug Data' section as a JSON array under the key 'DIMMs Info
Fetch Error' as a separate user data section.

Tested :

Below is a portion of PEL(callout section and User Data section are
shown) which callout the DIMM P0-C32.

```
"Hex Word 9": "00000000",
"Callout Section": {
"Callout Count": "1",
"Callouts": [{
"FRU Type": "Normal Hardware FRU",
"Priority": "Mandatory, replace all with this
type as a unit",
"Location Code": "UXXX.YYY.WWW004A-P0-C32",
"Part Number": "7777777",
"CCIN": "1234",
"Serial Number": "YYYYYY"
}]
}
```
"User Data": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "bmc error logging",
"BMCLoad": "0.65 0.69 0.64",
"BMCState": "Ready",
"BMCUptime": "0y 0d 0h 17m 43s",
"BootState": "Unspecified",
"ChassisState": "Off",
"DIMMs Additional Info": [
{
"DRAM Manufacturer ID": [
"0x88",
"0xAA"
]
"Location Code": "UXXX.YYY.WWW004A-P0-C32",
}
],
"FW Version ID": "fw1060.20-4-1060.2432.20240729a (NL1060_068)",
"HostState": "Off",
"System IM": "50001001"
}
```

Change-Id: I2ff81c66e63b99e8e84378ec78f586fb9b6322d7
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...


# 075c7923 16-Aug-2024 Patrick Williams <patrick@stwcx.xyz>

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 ...


# a167a7d9 30-Jun-2023 Matt Spinler <spinler@us.ibm.com>

PEL: Use lg2 in DataInterface files

Modernize it a bit and it makes it easier to see debug traces which can
be done by just running the daemon from the command line.

Signed-off-by: Matt Spinler <sp

PEL: Use lg2 in DataInterface files

Modernize it a bit and it makes it easier to see debug traces which can
be done by just running the daemon from the command line.

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

show more ...


# 5b423651 04-May-2023 Matt Spinler <spinler@us.ibm.com>

PEL: Watch for fan/PS hotplugs

Code is going to need to know when a fan or power supply (the only
hotpluggable redundant FRUs) are added or replaced so that it can clear
a flag in PELs that have tha

PEL: Watch for fan/PS hotplugs

Code is going to need to know when a fan or power supply (the only
hotpluggable redundant FRUs) are added or replaced so that it can clear
a flag in PELs that have that HW as a callout. This is so other code
that is doing degraded mode notifications will not do any notifications
for PELs calling out HW that has been replaced.

To enable this functionality, add support to the DataInterface class to
tell subscribers via a function callback when a fan or power supply
becomes present, as indicated by the Present property.

Code will watch the Present property of fan and power supplies to change
via the PropertiesChanged signal, as well as watch for InterfacesAdded
to catch when they show up on D-Bus in the first place.

It won't start any of these watches until the BMC gets to ready state so
that the inventory has a chance to be populated first.

On the first boot when the inventory was previously empty there will be
a round of inventory InterfacesAdded signals that will wake up the
daemon when PLDM receives the processor core presence information from
hostboot, but it just checks and sees it's the wrong interface and
returns, and I'm not sure how it can be avoided.

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

show more ...


# bad056be 25-Jan-2023 Matt Spinler <spinler@us.ibm.com>

PEL: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may ha

PEL: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may have been returned.

Mostly that was fine, except when a processor on a DCM was called out.
That would lead to only one processor on the DCM being set to not
functional by service_indicators.cpp, so on the web UI the actual CPU
called out may not have been marked as unhealthy (health status critical
in Redfish).

This commit changes getInventoryFromLocCode() to return all the paths
that GetFRUsByExpandedLocationCode() returns, and then makes the
corresponding changes in service_indicators.cpp to be able to handle
multiple inventory paths per location code when setting them to not
functional and creating a critical association.

The other code that was calling this function can just use the first
path returned, since in those cases it's just needed to get the VPD
information for the PEL, and all the paths would return the same info
anyway since they had the same location code.

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

show more ...


# 875b6c7b 20-Oct-2021 Vijay Lobo <vijaylobo@gmail.com>

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to SRC hex word 4 when creating a PEL.

This is how the field is defined in the PEL spec, and is to help with
debug so that one can know which part of the boot was occurring when
the PEL was created. Note that at this point most progress codes are
sent down from one of the host firmware subsystems and not created by
the BMC.

The field is only inserted into the SRC if those characters are present
and represent a valid 4 byte number, such as "C7004000". This is then
represented as 0xC7004000 in the SRC word. Otherwise, the word is left
at a value of zero.

For example:
...
"Valid Word Count": "0x09",
"Reference Code": "BD8D1001",
"Hex Word 2": "00080455",
"Hex Word 3": "2E2D0010",
"Hex Word 4": "C7004000", <---Progress code
"Hex Word 5": "00000000",
"Hex Word 6": "00000005",
"Hex Word 7": "00000000",
"Hex Word 8": "00000000",
"Hex Word 9": "00000000"
...

Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iba41e88626c0e081e5759b994e3630ef8b12daf4

show more ...


# 2544b419 04-Oct-2022 Patrick Williams <patrick@stwcx.xyz>

clang-format: update with latest

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


# 45e83521 22-Jul-2022 Patrick Williams <patrick@stwcx.xyz>

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t

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

show more ...


# 9ac0d9b8 14-Jul-2022 George Liu <liuxiwei@inspur.com>

PEL: Add BMC uptime to PELs in UserData section

A UserData section has been added to each PEL with additional debug
information, now there is a need to add the output of the uptime
command to UserDa

PEL: Add BMC uptime to PELs in UserData section

A UserData section has been added to each PEL with additional debug
information, now there is a need to add the output of the uptime
command to UserData and display it, but for Hostboot doesn't care
about this property, so skip adding it here it.

Tested: unit test passed
"User Data 0": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "0x2000",
...
"Uptime": "3y 332d 21h 33m 9s",
"Load": "1.47 0.94 0.61",
},

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I3d4c78bb1650da9a91804fc83de60597992ffc8a

show more ...


# 027bf285 24-Jan-2022 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Skip purging PEL if it has associated hw isolation entry

When PELs reaches to certain limits, either in total size or
total number of them, the code starts removing older pels
based on certain

PEL: Skip purging PEL if it has associated hw isolation entry

When PELs reaches to certain limits, either in total size or
total number of them, the code starts removing older pels
based on certain criteria. During this process make sure
no pel is removed that has an associated hardware isolation
entry record or error_log event record.

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: Ia7c9af6911bcf2ac8f8ec046d4c7a7a12d9b2bbd

show more ...


# 3e274432 14-Sep-2021 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Write terminating SRC to the progress SRC

Check for incoming pels for severity type 0x51 - Critical error,
System termination. If found, fetch the SRC and add this SRC to
progress SRC interface

PEL: Write terminating SRC to the progress SRC

Check for incoming pels for severity type 0x51 - Critical error,
System termination. If found, fetch the SRC and add this SRC to
progress SRC interface on dbus. In addition set the terminate bit
in BMC created pels only.

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: I26194a26743263183dcb61e097c745c4705fa006

show more ...


# ecaa2fce 05-Nov-2021 Jayanth Othayoth <ojayanth@in.ibm.com>

PEL: Add guard record entry create function

Added D-Bus wrapper function to create guard record
entry D-Bus object.

hardware isolation API's used no no-reply mode to avoid
cyclic dependency with lo

PEL: Add guard record entry create function

Added D-Bus wrapper function to create guard record
entry D-Bus object.

hardware isolation API's used no no-reply mode to avoid
cyclic dependency with log manager. PEL log already have
the details of guard records properties. For any failure
during record creation is hardware isolation application
is ignored by log manager. User will get details on this
failure by looking hardware isolation log information.

Tested: verified D-Bus create method.

Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com>
Change-Id: I8c7703dc28aaf7b39793e3bd1dfe4fac374d9ad5

show more ...


# 66491c61 06-Oct-2021 Patrick Williams <patrick@stwcx.xyz>

catch exceptions as const

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


# 2c36fddc 21-Sep-2021 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Store system boot state in user data section

For every incoming pel data interface watches the dbus property
that includes the latest boot progress/state value. This value would be
captured and

PEL: Store system boot state in user data section

For every incoming pel data interface watches the dbus property
that includes the latest boot progress/state value. This value would be
captured and stored in user data section of pel.

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: Ie48e7ee9fdd965af672f4bd563f8c9fc3bfacc43

show more ...


# 9d43a727 24-Aug-2021 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Update bmc & platform dump status in SRC section

With every PEL creation, the status of bmc and platform dumps -
Hardware and Hypervisor would be checked and status bits in SRC
section updated

PEL: Update bmc & platform dump status in SRC section

With every PEL creation, the status of bmc and platform dumps -
Hardware and Hypervisor would be checked and status bits in SRC
section updated accordingly.

Change-Id: I3ec7626611cf330f2ce235a97ee3046c0d32b6ab
Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>

show more ...


# 76198a2e 15-Jul-2021 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Set critical association to object paths

Create critical association to inventory d-bus objects.
This is being done for the items in callouts that need
their service indicators turned on in its

PEL: Set critical association to object paths

Create critical association to inventory d-bus objects.
This is being done for the items in callouts that need
their service indicators turned on in its code, and
that the other association endpoint is the chasis so
it can be used for health rollup.

The associations property on the
xyz.openbmc_project.Association.Definitions interface
will have following entry added to called out object path:
["health_rollup", "critical",
"/xyz/openbmc_project/inventory/system/chassis"]

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: I50dfe4807ac9c19f54c49dfa2b9ec7119aaffb96

show more ...


# 0d92b528 16-Jun-2021 Matt Spinler <spinler@us.ibm.com>

PEL: Handle location codes for connectors

There are cases where PELs need to callout physical system connectors,
such as a USB or other cable connector. This would be done by
specifying the connect

PEL: Handle location codes for connectors

There are cases where PELs need to callout physical system connectors,
such as a USB or other cable connector. This would be done by
specifying the connector's location code in either the message registry
JSON or device callout JSON. The problem is that the connector may not
be modeled by the inventory, and even if it was, there would need to be
a way to get the serial number, etc for the FRU that connector is on to
use in the callout

Instead of forcing all connectors to be modeled in the inventory along
with a copy of the SN/FN/CC from the parent FRU just to do a callout,
this commit will just pop off the connector segment of the location
code, a '-Tx', before trying to expand it or getting its related
inventory item. That way, it will be operating on the parent FRU which
would be in the inventory with its SN/FN/CC. In the case of the
location code expansion, the connector segment will then just be
re-appended afterwards.

This commit also makes a change to the device path callouts code to
expand the location code of the callout from the device path JSON
instead of trying to look it up later, which would have lost the
connector portion.

Note that when a cable itself wants to be called out, there usually
would need be a symbolic FRU specified saying which cable it is, along
with the connector location codes. In that case, the SN/FN/CC of the
parent FRU would not show up in the PEL.

Change-Id: I8e0eb58dfe630858f75e64b11ac13432bff4d2d1

show more ...


# 3b8ed7f2 18-May-2021 Sumit Kumar <sumit_kumar@in.ibm.com>

PEL: Support MfgSeverity & MfgAction flags PEL reg fields

This is specifically for manufacturing mode.
Look for mfgSeverity and mfgAction flags being set in incoming PELs and
if it is then check for

PEL: Support MfgSeverity & MfgAction flags PEL reg fields

This is specifically for manufacturing mode.
Look for mfgSeverity and mfgAction flags being set in incoming PELs and
if it is then check for dbus property for QuiesceOnHwError and if it is
found then override the severity value with mfg value.

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: Icd590b0e2732df8aa9c2935078528dda8fd4f996

show more ...


12