diff options
author | Richard Genoud <richard.genoud@bootlin.com> | 2024-06-21 17:00:55 +0200 |
---|---|---|
committer | Mathieu Poirier <mathieu.poirier@linaro.org> | 2024-07-01 10:37:26 -0600 |
commit | a8631f6d6344d976096b1efafdb2fbb3111bd790 (patch) | |
tree | d9aacd4dbd2b761b7c16c3f04c09f25282d75632 /scripts/gdb/linux/mm.py | |
parent | 67ca3f98070ffdf308b91e08a477fcb1e9684ae8 (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 <richard.genoud@bootlin.com>
Reviewed-by: Hari Nagalla <hnagalla@ti.com>
Link: https://lore.kernel.org/r/20240621150058.319524-2-richard.genoud@bootlin.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Diffstat (limited to 'scripts/gdb/linux/mm.py')
0 files changed, 0 insertions, 0 deletions