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

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

PEL: Change method of asserting a fault LED

There was a recent change in direction on how PELs should request that
fault LEDs be turned on. Previously, the code would talk to the LED
group objects

PEL: Change method of asserting a fault LED

There was a recent change in direction on how PELs should request that
fault LEDs be turned on. Previously, the code would talk to the LED
group objects directly. The new direction is to set the Functional
property on the OperationalStatus interface on the inventory objects in
question to false, and the LED manager code will watch that to know when
to turn on the LEDs.

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

show more ...

PEL: Set platform SAI LED group

There is now an LED group to set when the platform SAI LED needs to be
asserted when handling the service indicators for PEL callouts.

Signed-off-by: Matt Spinler <s

PEL: Set platform SAI LED group

There is now an LED group to set when the platform SAI LED needs to be
asserted when handling the service indicators for PEL callouts.

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

show more ...

PEL: LightPath: Assert LED groups

Fill in the functions to get the LED group D-Bus paths corresponding to
the called out location codes, and then set the Asserted property on
that path to turn on th

PEL: LightPath: Assert LED groups

Fill in the functions to get the LED group D-Bus paths corresponding to
the called out location codes, and then set the Asserted property on
that path to turn on the LEDs.

If there are any problems looking up any of the LED groups, then do not
turn on any LEDs at all, even if others were OK. In this case, the
system attention indicator will be turned on instead.

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

show more ...

PEL: LightPath: Choose callout location codes

LightPath uses the following rules to pick the location codes to turn on
LEDs for:

* If the PEL wasn't created by the BMC or Hostboot, and doesn't have

PEL: LightPath: Choose callout location codes

LightPath uses the following rules to pick the location codes to turn on
LEDs for:

* If the PEL wasn't created by the BMC or Hostboot, and doesn't have the
Service Action action flag set, then don't even check it and don't
turn on the System Attention Indicator.

* Choose all location codes in the first group of callouts, where a
group can be:
* a single medium priority callout
* one or more high priority callouts
* one or more medium group A priority callouts

* All callouts in that group must be hardware callouts, meaning the FRU
identity section's failing component type flag must either be hardware
callout or symbolic FRU callout with trusted location code. If there
is a callout in the group that doesn't meet this requirement, then
nothing in that group can be used.

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

show more ...