| author | Piyali Goswami <piyali_g@ti.com> | |
| Sat, 2 Jan 2021 03:40:22 +0000 (09:10 +0530) | ||
| committer | Sujith Shivalingappa <sujith.s@ti.com> | |
| Mon, 18 Jan 2021 03:51:06 +0000 (21:51 -0600) | ||
| commit | ce32b89d31d1e5eaebb10c74d665def46da40534 | |
| tree | 68a3d215734702abecdcf953b69647c127de4928 | tree | snapshot (tar.xz tar.gz zip) |
| parent | 6579033b4b3ba498759b88cff837320dfd8160e5 | commit | diff |
PDK-9013: Fixes for Sciserver logic
Sciserver_UserProcessMsg has 2 flows:
1. Non-secure host --> Sciserver_UserProcessMsg (MCU1_0)
RM Process / PM Process
[RM forward to DMSC]
2. Secure Host --> DMSC --> Sciserver_UserProcessMsg (MCU1_0)
RM Process/ PM Process
Earlier logic was performing the following steps:
1. Check message type - based on that set RM, PM or forward flag.
2. If RM flag and forward flag is set the Process RM is called and the Forward message is called.
3. The effect is the local RM is called 2 times
4. If the local RM fails, we still end up calling the API 2 times.
5. If there is a fail in the Forward response function, the response is not sent back to the non-secure host.
So the logic has to be corrected to have only local RM processing when getting forwarded from a secure host and have non-secure processing call the Sciclient_service function which identifies the forward or non-forward message calls.
The earlier logic also has another issue where the value of return is checked for the setting of the ACK and NACK flag after the override finished for the ret value based on the fact that the ACK and NACK flag is already set in the response. So the net effect is the ACK / NACK flag is falsely set to ACK based on the ret value giving an incorrect response to the user.
The current logic does the following:
1. Checks if the message is from DMSC (forwarded) or not. Based on this it calls the full message processing or only the local to MCU1_0 RM message processing.
2. The Sciserver and the local RM message processing sets the ACK/NACK flag and the API does not overwrite this after the processing is complete.
Signed-off-by: Piyali Goswami <piyali_g@ti.com>
Sciserver_UserProcessMsg has 2 flows:
1. Non-secure host --> Sciserver_UserProcessMsg (MCU1_0)
RM Process / PM Process
[RM forward to DMSC]
2. Secure Host --> DMSC --> Sciserver_UserProcessMsg (MCU1_0)
RM Process/ PM Process
Earlier logic was performing the following steps:
1. Check message type - based on that set RM, PM or forward flag.
2. If RM flag and forward flag is set the Process RM is called and the Forward message is called.
3. The effect is the local RM is called 2 times
4. If the local RM fails, we still end up calling the API 2 times.
5. If there is a fail in the Forward response function, the response is not sent back to the non-secure host.
So the logic has to be corrected to have only local RM processing when getting forwarded from a secure host and have non-secure processing call the Sciclient_service function which identifies the forward or non-forward message calls.
The earlier logic also has another issue where the value of return is checked for the setting of the ACK and NACK flag after the override finished for the ret value based on the fact that the ACK and NACK flag is already set in the response. So the net effect is the ACK / NACK flag is falsely set to ACK based on the ret value giving an incorrect response to the user.
The current logic does the following:
1. Checks if the message is from DMSC (forwarded) or not. Based on this it calls the full message processing or only the local to MCU1_0 RM message processing.
2. The Sciserver and the local RM message processing sets the ACK/NACK flag and the API does not overwrite this after the processing is complete.
Signed-off-by: Piyali Goswami <piyali_g@ti.com>