aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorRichard Genoud <[email protected]>2024-06-21 17:00:55 +0200
committerMathieu Poirier <[email protected]>2024-07-01 10:37:26 -0600
commita8631f6d6344d976096b1efafdb2fbb3111bd790 (patch)
treed9aacd4dbd2b761b7c16c3f04c09f25282d75632 /tools/perf/scripts/python
parent67ca3f98070ffdf308b91e08a477fcb1e9684ae8 (diff)
remoteproc: k3-r5: Fix IPC-only mode detection
ret variable was used to test reset status, get from reset_control_status() call. But this variable was overwritten by ti_sci_proc_get_status() a few lines bellow. And as ti_sci_proc_get_status() returns 0 or a negative value (in this latter case, followed by a return), the expression !ret was always true, Clearly, this was not what was intended: In the comment above it's said that "requires both local and module resets to be deasserted"; if reset_control_status() returns 0 it means that the reset line is deasserted. So, it's pretty clear that the return value of reset_control_status() was intended to be used instead of ti_sci_proc_get_status() return value. This could lead in an incorrect IPC-only mode detection if reset line is asserted (so reset_control_status() return > 0) and c_state != 0 and halted == 0. In this case, the old code would have detected an IPC-only mode instead of a mismatched mode. Fixes: 1168af40b1ad ("remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs") Signed-off-by: Richard Genoud <[email protected]> Reviewed-by: Hari Nagalla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions