tree 8e6ce9832ed5ccb8c6c3897a7cd347fb0c5c6147
parent f37e4dc8092d2b979f4f77c3ce32237ceb7ad7f2
author Thu Nguyen <thu@os.amperecomputing.com> 1692748039 +0700
committer Thu Nguyen <thu@os.amperecomputing.com> 1692751310 +0700

transport: Match specified metadata in pldm_transport_send_recv_msg()

The mctp-demux broadcasts the PLDM RX response messages to all of mctp
socket instances. That means the GetSensorReading response from one
instance (pldmd) can be received by the other instance (pldmtool)
which is waiting for the response of GetPDR request message. When the
gap time between the two requests of pldmtool is long enough the
number of GetSensorReading response messages can be more than 32. That
means the instance ID of new GetPDR command in pldmtool can equal with
the used and free one in GetSensorReading. So the
`pldm_transport_send_recv_msg()` will match the response of
GetSensorReading with the response of GetPDR. So only comparing the
instance ID in `pldm_transport_send_recv_msg` is not enough.

Section "Requirements for requesters" in DSP0240 version 1.1.0, "A
PLDM terminus that issues PLDM requests should be prepared to handle
the order of responses that may not match the order in which the
requests were sent (that is, it should not automatically assume that a
response that it receives is in the order in which the request was
sent). It should check to see that the PLDM Type, PLDM Command Code,
and Instance ID values in the response match up with a corresponding
outstanding command before acting on any parameters returned in the
response."

Add the PLDM type and command code on matching the response of
`pldm_transport_send_recv_msg()`.

Signed-off-by: Thu Nguyen <thu@os.amperecomputing.com>
Change-Id: I7284bd4ecd8be3786fa078af1eb3f06046e4baa3