| /openbmc/phosphor-logging/test/openpower-pels/ |
| H A D | data_interface_test.cpp | 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| H A D | meson.build | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| H A D | src_test.cpp | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| H A D | pel_test.cpp | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| /openbmc/phosphor-logging/extensions/openpower-pels/ |
| H A D | data_interface.hpp | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| H A D | src.cpp | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|
| H A D | data_interface.cpp | diff 0d92b528f8393c55a5339f83ce855b0b13ad230d Wed Jun 16 14:28:17 CDT 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 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
|